IETF - Working Group Charters

Email Address Internationalization (eai)

Last Modified: 2009-04-03

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

Chair(s):

Applications Area Director(s):

Applications Area Advisor:

Alexey Melnikov <alexey.melnikov@isode.com>

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:

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 specificatio
n 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:

IMAP Support for UTF-8 (30426 bytes)
Mailing Lists and Internationalized Email Addresses (25327 bytes)
POP3 Support for UTF-8 (25305 bytes)
An update to the mailto URI scheme for Email Address Internationalization (11762 bytes)
Displaying Downgraded Messages for Email Address Internationalization (21782 bytes)
Internationalized Delivery Status and Disposition Notifications (38534 bytes)

Request For Comments:

Overview and Framework for Internationalized Email (RFC 4952) (48409 bytes) updated by RFC 5336
Internationalized Email Headers (RFC 5335) (27945 bytes) updates RFC 2045,RFC 2822
SMTP Extension for Internationalized Email Addresses (RFC 5336) (48110 bytes) updates RFC 2821,RFC 2822,RFC 4952
Internationalized Delivery Status and Disposition Notifications (RFC 5337) (36324 bytes) updates RFC 3461,RFC 3464,RFC 3798
Downgrading Mechanism for Email Address Internationalization (RFC 5504) (48894 bytes)