Email Address Internationalization (eai)

Last Modified: 2006-08-15

Additional information is available at tools.ietf.org/wg/eai

Chair(s):

  • Harald Alvestrand <harald@alvestrand.no>

  • XiaoDong Lee <lee@cnnic.cn>

    Applications Area Director(s):

  • Ted Hardie <hardie@qualcomm.com>
  • Lisa Dusseault <lisa@osafoundation.org>

    Applications Area Advisor:

  • Ted Hardie <hardie@qualcomm.com>

    Mailing Lists:

    General Discussion: ima@ietf.org
    To Subscribe: https://www1.ietf.org/mailman/listinfo/ima
    Archive: http://www1.ietf.org/mail-archive/web/ima/index.html

    Description of Working Group:

    Since early in the effort to internationalize domain names, which
    resulted in the standards associated with IDNA, it has been
    understood that internationalization of email address local parts is
    required. At the same time, email address internationalization poses
    a series of special problems. Constraints on the interpretation of
    local-parts by any system other than the final delivery one make
    address encoding nearly impossible. The need to use addresses in both
    the email envelope and in header fields, and to do so in ways that are
    at least compatible, suggests that this is not a simple and isolated
    problem.

    This working group will address one basic approach to email
    internationalization. That approach is based on the use of an SMTP
    extension to enable both the use of UTF-8 in envelope address local-
    parts and optionally in domain-parts and the use of UTF-8 in mail
    headers -- both in address contexts and wherever encoded-words are
    permitted today. Its initial target will be a set of experimental
    RFCs that specify the details of this approach and provide the basis
    for generating and testing interoperable implementations. Its work
    will include examining whether "downgrading" -- transforming an
    internationalized message to one that is compatible with unextended
    SMTP clients and servers and unextended MUAs -- is feasible and
    appropriate and, if it is, specifying a way to do so. If it is not,
    the WG will evaluate whether the effort is worth taking forward.
    Other approaches may be considered by the formation of other
    working groups.

    Key parts of this effort include extended analyses and, if necessary,
    proof of concept in three areas in addition to smooth operation when
    all systems and components along a message path have been upgraded to
    support the new facilities. They are

    o Examination of scenarios for the appearance of these facilities to
    users, including ways in which alternate addresses may be
    specified if those are needed for downgrading.
    o Examination of different locations at which downgrading might be
    required and accomplished, differentiating between requirements
    and capabilities at the point of origin (at or before the
    submission server), those that exist while the message is in
    transit, and those that apply after SMTP "final delivery" or in
    the logical vicinity or an IMAP or POP server.
    o Examination of the "mailing list question", i.e., how a mixture of
    traditional and internationalized addresses on a mailing list will
    impact message flows, error reports, and delivery notifications in
    all plausible combinations of servers and addresses, including
    internationalizated and traditional reverse paths.

    Once the Experimental RFCs are completed and implemented, the
    experience gathered will be evaluated. If the approach is found to
    have been successful (using criteria the WG will establish as an
    early work item), the WG will be rechartered to update the documents
    for processing onto the standards track.

    1.6. Deliverables

    The following deliverables are foreseen in this charter. The WG
    chairs may structure the deliverables into specific documents
    or document sets as needed. Adding or removing documents
    outside of these deliverables will require a charter update.

    o Overview and architecture (Info)
    o Interworking scenarios, including the "mailing list question"
    (Info)
    o SMTP extensions specification (Exp)
    o Header format specification (Exp)
    o Downgrading specification in SMTP (Exp)
    o Downgrading specification in POP servers (Exp)
    o Downgrading specification in IMAP servers (Exp)
    o Results and evaluation of experiment (Info)

    Going forward, it is possible that the SMTP downgrading specification
    will go for Informational due to the difficulty of fully specifying
    all necessary behavior.

    Additional possible documents suggested:
    Advice for MUA implementors (Info)

    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
    Jun 2006  Overview/architecture draft to IESG
    Jun 2006  Interworking scenarios to IESG
    Done  Downgrading in POP first draft
    Sep 2006  SMTP Extensions to IESG
    Sep 2006  Header format to IESG
    Sep 2006  Downgrading in SMTP to IESG
    Sep 2006  Downgrading in POP to IESG
    Sep 2006  Downgrading in IMAP to IESG
    Dec 2006  Results and evaluation first draft
    Mar 2007  Results and evaluation to IESG
    Mar 2007  Group recharter for standards track

    Internet-Drafts:

    SMTP extension for internationalized email address (34028 bytes)
    UTF-8 Mail: Scenarios (17340 bytes)
    Overview and Framework for Internationalized Email (52801 bytes)
    Downgrading mechanism for Email Address Internationalization (EAI) (28544 bytes)
    Internationalized Email Headers (28915 bytes)
    Mailing Lists and Internationalized Email Addresses (18714 bytes)
    POP3 Support for UTF-8 (30413 bytes)

    No Request For Comments

    IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.

    Return to working group directory.

    Return to IETF home page.