Email Address Internationalization (eai) ---------------------------------------- Charter Last Modified: 2010-06-08 Current Status: Active Working Group Chair(s): John Klensin Joseph Yee Applications Area Director(s): Alexey Melnikov Peter Saint-Andre Applications Area Advisor: Alexey Melnikov Secretary(ies): Jiankang Yao 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: Done Overview/architecture draft first Done Interworking scenarios first draft Done SMTP Extensions first draft Done Header format first draft Done Downgrading in IMAP first draft Done Downgrading in SMTP first draft Done Downgrading in POP first draft Done Overview/architecture draft to IESG Done SMTP Extensions to IESG Done Header format to IESG Done Downgrading in SMTP to IESG Done Downgrading in POP to IESG Done Downgrading in IMAP to IESG Done Discussion of Recharter for standards track at IETF 77 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 Internet-Drafts: Posted Revised I-D Title ------ ------- -------------------------------------------- Jun 2006 Jun 2010 Mailing Lists and Internationalized Email Addresses Jun 2010 Sep 2010 Overview and Framework for Internationalized Email Jun 2010 Sep 2010 SMTP Extension for Internationalized Email Address Jul 2010 Aug 2010 Internationalized Email Headers Sep 2010 Sep 2010 POP3 Support for UTF-8 Request For Comments: RFC Stat Published Title ------- -- ----------- ------------------------------------ RFC4952 I Jul 2007 Overview and Framework for Internationalized Email RFC5335 E Sep 2008 Internationalized Email Headers RFC5336 E Sep 2008 SMTP Extension for Internationalized Email Addresses RFC5337 E Sep 2008 Internationalized Delivery Status and Disposition Notifications RFC5504 E Mar 2009 Downgrading Mechanism for Email Address Internationalization RFC5721 E Feb 2010 POP3 Support for UTF-8 RFC5738 E Mar 2010 IMAP Support for UTF-8 RFC5825 E Apr 2010 Displaying Downgraded Messages for Email Address Internationalization