A modified charter has been submitted for the Email Address Internationalization (eai) working group in the Applications Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 1, 2010. Email Address Internationalization (eai) ------------------------------------- Last updated: 2010-05-21 Current Status: Active Chairs: John Klensin <john-ietf@jck.com> Joseph Yee <jyee@ca.afilias.info> Secretary: Jiankang Yao <yaojk@cnnic.cn> Applications Area Directors: Alexey Melnikov <alexey.melnikov@isode.com> Peter Saint-Andre <stpeter@stpeter.im> Applications Area Advisor: Alexey Melnikov <alexey.melnikov@isode.com> Mailing Lists: General Discussion: ima@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ima Archive: http://www.ietf.org/mail-archive/web/ima Description of Working Group: The email address has two parts, local part and domain part. Email address internationalization must deal with both. This working group's previous experimental efforts investigated the use of UTF-8 as a general approach to email internationalization. That approach is based on the use of an SMTP extension to enable the use of UTF-8 in envelope address local-parts, optionally in address domain-parts, and in mail headers. The mail header contexts can include both addresses and wherever existing protocols (e.g., RFC 2231) permit the use of encoded-words. All WG deliverables specified under the original charter, particularly the experimental protocol specifications, have been completed. The core specifications have been implemented and interoperability tests performed. The WG is now being rechartered to permit advancing revised versions of those specifications and supporting documents into the standards track. As a result of implementation and testing experience, the WG has concluded to drop the model of in-transit downgrading that was a key part of the original effort. In-transit downgrading approaches simply do not work well enough and predictably enough to be worth the considerable additional complexity that accompanies them. In particular, dropping in-transit downgrading eliminates the need for the first significant change to the syntax of an email address since RFC 821 and 822 were published in 1982. Work will therefore reflect a "no fallback" approach. That approach provides a very minimal transition mechanism, but is consistent with the long-term view that email with invalid addresses or syntax should be rejected, rather than fixed up in transit between submission servers and delivery servers. Discoverable fallback addresses that could be applied before or during message submission or after SMTP "final delivery" may be investigated. The WG may also develop other materials to give advice to implementers or operators. Those efforts may lead to informational documents or best practices recommendations, but are considered independent of the core documents. Work on them will progress only under the condition that it not delay the primary standards track specifications. The WG believes that the lessons learned from implementation and testing and removal of in-transit downgrading as a goal eliminates all major areas of controversy about the core specifications and should permit very rapid progress. Such rapid progress is an explicit goal for the WG; issues resolved in the past will not be revisited unless those who wish to do so can demonstrate data, reasoning, or consequences that were not considered earlier. At the same time, any attempt to significantly extend an established and widely deployed set of protocols may uncover new consequences or side effects that need consideration and evaluation. If faced with a choice between spending time on such new considerations, the WG will favor getting things right over accelerating the schedule. Deliverables The following deliverables are foreseen in this charter. The WG chairs may (re)structure the deliverables into specific documents or document sets as needed. Adding or removing documents other than those listed below as "Required" or "Additional" will require a charter update. Required Documents (these are the "core specifications" referred to elsewhere) * Overview and Framework for Internationalized Email, replacing RFC 4952 (Informational or Proposed Standard at IESG discretion once complete) * UTF-8 SMTP extension specification, replacing RFC 5336 (Proposed Standard) * Header format specification, replacing RFC 5335 (Proposed Standard) * Internationalized DSN specification, replacing RFC 5337 (Proposed Standard) * UTF-8 POP specification, replacing RFC 5721 (Proposed Standard) * UTF-8 IMAP specification, replacing RFC 5738 (Proposed Standard) Additional possible documents suggested. While milestones are listed for most of these documents, they may be dropped by the WG with the consent of the Responsible AD. * Advice for MUA implementors (Informational or BCP) * Advice for EAI deployment (Informational or BCP) * Advice for non-ASCII and ASCII addresses for the same mailbox (Informational or BCP) * Mailinglist (Informational or Standards Track, replacing draft-eai-mailinglist) * Mailto (Proposed Standard, updating draft-duerst-mailto-bis to reflect internationalized addresses) * Protocol extensions for RFC 4409 Submission Servers or configuration advice for the MUA->Submission server interface. Goals and Milestones: Mar 2010 Discussion of Recharter for standards track at IETF 77 (completed) May 2010 New charter approval from IESG Jul 2010 EAI Framework to IESG Sep 2010 Headers to IESG Sep 2010 SMTP to IESG Sep 2010 DSN to IESG Nov 2010 IMAP & POP3 to IESG Dec 2010 Decision about possible changes or comments about Submission Servers. If the decision is to generate a document, the decision will include a schedule. Jan 2011 Advice for non-ASCII & ASCII addresses to IESG Jan 2011 Advice for MUA implementors to IESG Jan 2011 Advice for EAI deployment to IESG Apr 2011 Mailinglist to IESG Apr 2011 Mailto (Proposed Standard) to IESG _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
