Fwd: WG Review: Recharter of Email Address Internationalization (eai)
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 <roessler@xxxxxxxxxxxxxxxxxx> (@roessler)
Begin forwarded message:
> From: IESG Secretary <iesg-secretary@xxxxxxxx>
> Date: 25 May 2010 19:00:01 GMT+02:00
> To: ietf-announce@xxxxxxxx
> Cc: john-ietf@xxxxxxx, ima@xxxxxxxx
> Subject: WG Review: Recharter of Email Address Internationalization (eai)
> Reply-To: iesg@xxxxxxxx
>
> 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@xxxxxxxx) by Tuesday, June 1,
> 2010.
>
> Email Address Internationalization (eai)
> -------------------------------------
> Last updated: 2010-05-21
>
> Current Status: Active
>
> Chairs:
> John Klensin <john-ietf@xxxxxxx>
> Joseph Yee <jyee@xxxxxxxxxxxxxxx>
>
> Secretary:
> Jiankang Yao <yaojk@xxxxxxxx>
>
> Applications Area Directors:
> Alexey Melnikov <alexey.melnikov@xxxxxxxxx>
> Peter Saint-Andre <stpeter@xxxxxxxxxx>
>
> Applications Area Advisor:
> Alexey Melnikov <alexey.melnikov@xxxxxxxxx>
>
> Mailing Lists:
> General Discussion: ima@xxxxxxxx
> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf-announce
>