<<< Date Index >>>     <<< Thread Index >>>

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
>