FYI. This is significant in two ways: 1. The downgrade mechanism from the previous e-mail address internationalization architecture is dropped.
2. We'll start to see utf-8 in addresses and headers across at least POP, IMAP, and ESMTP. Regards, -- Thomas Roessler <[email protected]> (@roessler) Begin forwarded message: > From: IESG Secretary <[email protected]> > Date: 25 May 2010 19:00:01 GMT+02:00 > To: [email protected] > Cc: [email protected], [email protected] > Subject: WG Review: Recharter of Email Address Internationalization (eai) > Reply-To: [email protected] > > 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 ([email protected]) by Tuesday, June 1, > 2010. > > Email Address Internationalization (eai) > ------------------------------------- > Last updated: 2010-05-21 > > Current Status: Active > > Chairs: > John Klensin <[email protected]> > Joseph Yee <[email protected]> > > Secretary: > Jiankang Yao <[email protected]> > > Applications Area Directors: > Alexey Melnikov <[email protected]> > Peter Saint-Andre <[email protected]> > > Applications Area Advisor: > Alexey Melnikov <[email protected]> > > Mailing Lists: > General Discussion: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/ietf-announce >
