* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Eai Status Pages

Email Address Internationalization (Concluded WG)
App Area: Barry Leiba | 2006-Mar-17 — 2013-Mar-19 

2012-09-24 charter

Email Address Internationalization (eai)


 Current Status: Active

     John C. Klensin <john-ietf@jck.com>
     Joseph Yee <jyee@afilias.info>

 Applications Area Directors:
     Barry Leiba <barryleiba@computer.org>
     Pete Resnick <presnick@qti.qualcomm.com>

 Applications Area Advisor:
     Pete Resnick <presnick@qti.qualcomm.com>

     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

    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.


    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

    * Internationalized DSN specification, replacing RFC 5337
     (Proposed Standard)

    * UTF-8 POP specification, replacing RFC 5721 (Proposed

    * UTF-8 IMAP specification, replacing RFC 5738 (Proposed

    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

    * 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 SMTP first draft
  Done     - Downgrading in IMAP 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

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/eai/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -