Full use of electronic mail throughout the world requires that
(subject to other constraints) people be able to use close
variations on their own names (written correctly in their own
languages and scripts) as mailbox names in email addresses.
This document introduces a series of specifications that define
mechanisms and protocol extensions needed to fully support
internationalized email addresses. These changes include an
SMTP extension and extension of email header syntax to
accommodate UTF-8 data. The document set also includes
discussion of key assumptions and issues in deploying fully
internationalized email. This document is an update of RFC
4952; it reflects additional issues identified since that
document was published.
Working Group Summary
This document was originally targeted as Informational and
approved by the IESG. However, after the main protocol
documents went through IESG Evaluation, the WG decided
that this document required updates to accommodate the
IESG comments and needed to be put on the Standards
Track as well.
This document does not describe any protocols in detail; those
are in other WG documents. Ernie Daindow, Tony Hansen,
Shawn Steele, and Jiankang Yao reviewed the document
thoroughly and suggested text to improve it.
The general protocol collection described in this document
derives from prior Experimental protocols that were
implemented and tested. The results of those experiments,
focusing on what should be done differently as a result, are
discussed in this document. At least those who implemented
the Experimental protocols, and presumably some others, are
likely to implement the standards-track protocols as soon as
they are considered stable. There appears to be significant
worldwide demand for the facilities being specified by the
EAI WG and outlined in this document.
Joseph Yee is the Document Shepherd.
Pete Resnick is the Responsible Area Director.
The EAI Working Group would like this document released as a set
with the three documents previously announced (and referenced below).
We would greatly appreciate that they get consecutive RFC numbers in the
following (non-obvious) order:
The reason that 5336bis should have a lower number than 5335bis is
because the current ordering of 5335 (the international email format
document) and 5336 (the international email transport document) has
caused some amount of confusion because the base specifications are in
the other order: First is RFC 5321 (the email transport document) and
second is 5322 (the email format document). And if it works out, having
the RFC numbers end in 0, 1, 2, and 3 respectively might be salient to
Thanks for your consideration.