draft-ietf-eai-frmwrk-4952bis-10.txt   draft-ietf-eai-frmwrk-4952bis-11.txt 
Email Address Internationalization J. Klensin Email Address Internationalization J. Klensin
(EAI) (EAI) Y. Ko
Internet-Draft Y. Ko Internet-Draft October 25, 2011
Obsoletes: 4952, 5504, 5825 ICU Obsoletes: 4952, 5504, 5825
(if approved) September 27, 2010 (if approved)
Intended status: Informational Intended status: Standards Track
Expires: March 31, 2011 Expires: April 27, 2012
Overview and Framework for Internationalized Email Overview and Framework for Internationalized Email
draft-ietf-eai-frmwrk-4952bis-10 draft-ietf-eai-frmwrk-4952bis-11
Abstract Abstract
Full use of electronic mail throughout the world requires that Full use of electronic mail throughout the world requires that
(subject to other constraints) people be able to use close variations (subject to other constraints) people be able to use close variations
on their own names (written correctly in their own languages and on their own names (written correctly in their own languages and
scripts) as mailbox names in email addresses. This document scripts) as mailbox names in email addresses. This document
introduces a series of specifications that define mechanisms and introduces a series of specifications that define mechanisms and
protocol extensions needed to fully support internationalized email protocol extensions needed to fully support internationalized email
addresses. These changes include an SMTP extension and extension of addresses. These changes include an SMTP extension and extension of
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 31, 2011. This Internet-Draft will expire on April 27, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Role of This Specification . . . . . . . . . . . . . . . . . . 4 2. Role of This Specification . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 6 4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 6
4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 7 4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 7
4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Conventional Message and Internationalized Message . . . . 8 4.6. Conventional Message and Internationalized Message . . . . 8
4.7. Undeliverable Messages, Notification, and Delivery 4.7. Undeliverable Messages, Notification, and Delivery
Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 8 Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Overview of the Approach and Document Plan . . . . . . . . . . 9 5. Overview of the Approach and Document Plan . . . . . . . . . . 9
6. Review of Experimental Results . . . . . . . . . . . . . . . . 9 6. Review of Experimental Results . . . . . . . . . . . . . . . . 10
7. Overview of Protocol Extensions and Changes . . . . . . . . . 10 7. Overview of Protocol Extensions and Changes . . . . . . . . . 10
7.1. SMTP Extension for Internationalized Email Address . . . . 10 7.1. SMTP Extension for Internationalized Email Address . . . . 10
7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11 7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11
7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12 7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12
8. Downgrading before and after SMTP Transactions . . . . . . . . 12 8. Downgrading before and after SMTP Transactions . . . . . . . . 12
8.1. Downgrading before or during Message Submission . . . . . 13 8.1. Downgrading before or during Message Submission . . . . . 13
8.2. Downgrading or Other Processing After Final SMTP 8.2. Downgrading or Other Processing After Final SMTP
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 15 9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 15
10. User Interface and Configuration Issues . . . . . . . . . . . 15 10. User Interface and Configuration Issues . . . . . . . . . . . 15
10.1. Choices of Mailbox Names and Unicode Normalization . . . . 15 10.1. Choices of Mailbox Names and Unicode Normalization . . . . 16
11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 17 11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 17 11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 17
11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 17 11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 17
11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 17 11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 18
11.4. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18 11.4. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18
11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 18 11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 19
12. Key Changes From the Experimental Protocols and Framework . . 19 12. Key Changes From the Experimental Protocols and Framework . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
16.1. Normative References . . . . . . . . . . . . . . . . . . . 21 16.1. Normative References . . . . . . . . . . . . . . . . . . . 21
16.2. Informative References . . . . . . . . . . . . . . . . . . 22 16.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 26 A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 26
A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 27 A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 27
A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 28 A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 28
A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 28 A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 28
A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 28 A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 29
A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 29 A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 29
A.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 29 A.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 29
A.8. Changes between -07 and -08 (after IETF Last Call) . . . . 29 A.8. Changes between -07 and -08 (after IETF Last Call) . . . . 29
A.9. Changes between -08 and -09 . . . . . . . . . . . . . . . 29 A.9. Changes between -08 and -09 . . . . . . . . . . . . . . . 29
A.10. Changes between -09 and -10 . . . . . . . . . . . . . . . 29 A.10. Changes between -09 and -10 . . . . . . . . . . . . . . . 29
A.11. Changes between -10 and -11 . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Note in Draft and to RFC Editor: The keyword represented in this Note in Draft and to RFC Editor: The keyword represented in this
document by "UTF8SMTPbis" (and in the XML source by &EAISMTPkeyword;) document by "UTF8SMTPbis" (and in the XML source by &EAISMTPkeyword;)
is a placeholder. The actual keyword will be assigned when the is a placeholder. The actual keyword will be assigned when the
standards track SMTP extension in this series [RFC5336bis-SMTP] is standards track SMTP extension in this series [RFC5336bis-SMTP] is
approved for publication and should be substituted here. This approved for publication and should be substituted here. This
paragraph should be treated as normative reference to that SMTP paragraph should be treated as normative reference to that SMTP
extension draft, creating a reference hold until it is approved by extension draft, creating a reference hold until it is approved by
skipping to change at page 4, line 35 skipping to change at page 4, line 35
message header fields to accommodate non-ASCII data. However, it message header fields to accommodate non-ASCII data. However, it
does not permit the use of email addresses that include non-ASCII does not permit the use of email addresses that include non-ASCII
characters. Without the extensions defined here, or some equivalent characters. Without the extensions defined here, or some equivalent
set, the only way to incorporate non-ASCII characters in any part of set, the only way to incorporate non-ASCII characters in any part of
email addresses is to use RFC 2047 coding to embed them in what RFC email addresses is to use RFC 2047 coding to embed them in what RFC
5322 [RFC5322] calls the "display name" (known as a "name phrase" or 5322 [RFC5322] calls the "display name" (known as a "name phrase" or
by other terms elsewhere) of the relevant header fields. Information by other terms elsewhere) of the relevant header fields. Information
coded into the display name is invisible in the message envelope and, coded into the display name is invisible in the message envelope and,
for many purposes, is not part of the address at all. for many purposes, is not part of the address at all.
This document is an update of RFC 4952 [RFC4952]; it reflects This document is a replacement for RFC 4952 [RFC4952]; it reflects
additional issues, shared terminology, and some architectural changes additional issues, shared terminology, and some architectural changes
identified since that document was published. identified since that document was published. It obsoletes that
document and RFCs 5504 [RFC5504] and 5825 [RFC5825], which are no
longer needed due to the changes discussed in Section 12. The RFC
Editor is requested to move all three of those documents to Historic.
The pronouns "he" and "she" are used interchangeably to indicate a The pronouns "he" and "she" are used interchangeably to indicate a
human of indeterminate gender. human of indeterminate gender.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. Although this document is Informational, those [RFC2119]. Although this document is Informational, those
requirements are consistent with requirements specified in the requirements are consistent with requirements specified in the
Standards Track documents in this set as described in Section 5. Standards Track documents in this set as described in Section 5.
skipping to change at page 5, line 24 skipping to change at page 5, line 29
Taken together, these specifications provide the details for a way to Taken together, these specifications provide the details for a way to
implement and support internationalized email. The document itself implement and support internationalized email. The document itself
describes how the various elements of email internationalization fit describes how the various elements of email internationalization fit
together and the relationships among the primary specifications together and the relationships among the primary specifications
associated with message transport, header formats, and handling. associated with message transport, header formats, and handling.
This document, and others that comprise the collection described This document, and others that comprise the collection described
above, assume a reasonable familiarity with the basic Internet above, assume a reasonable familiarity with the basic Internet
electronic mail specifications and terminology [RFC5321][RFC5322] and electronic mail specifications and terminology [RFC5321][RFC5322] and
the MIME [RFC2045] and 8BITMIME [RFC1652] ones as well. While not the MIME [RFC2045] and 8BITMIME [RFC6152] ones as well. While not
strictly required to implement this specification, a general strictly required to implement this specification, a general
familiarity with the terminology and functions of IDNA familiarity with the terminology and functions of IDNA
[RFC5890][RFC5891] [RFC5892][RFC5893] [RFC5894] are also assumed. [RFC5890][RFC5891] [RFC5892][RFC5893] [RFC5894] are also assumed.
3. Problem Statement 3. Problem Statement
Internationalizing Domain Names in Applications (IDNA) [RFC5890] Internationalizing Domain Names in Applications (IDNA) [RFC5890]
permits internationalized domain names, but deployment has not yet permits internationalized domain names, but deployment has not yet
reached most users. One of the reasons for this is that we do not reached most users. One of the reasons for this is that we do not
yet have fully internationalized naming schemes. Domain names are yet have fully internationalized naming schemes. Domain names are
skipping to change at page 6, line 18 skipping to change at page 6, line 21
decode a special coding and respond by displaying local characters. decode a special coding and respond by displaying local characters.
To be perceived as usable, the addresses must be internationalized To be perceived as usable, the addresses must be internationalized
and handled consistently in all of the contexts in which they occur. and handled consistently in all of the contexts in which they occur.
This requirement has far-reaching implications: collections of This requirement has far-reaching implications: collections of
patches and workarounds are not adequate. Even if they were patches and workarounds are not adequate. Even if they were
adequate, a workaround-based approach may result in an assortment of adequate, a workaround-based approach may result in an assortment of
implementations with different sets of patches and workarounds having implementations with different sets of patches and workarounds having
been applied with consequent user confusion about what is actually been applied with consequent user confusion about what is actually
usable and supported. Instead, we need to build a fully usable and supported. Instead, we need to build a fully
internationalized email environment, focusing on permitting efficient internationalized email environment, focusing on permitting efficient
communication among those who share a language or other community. communication among those who share a language and writing system.
That, in turn, implies changes to the mail header environment to That, in turn, implies changes to the mail header environment to
permit the full range of Unicode characters where that makes sense, permit those header fields that are appropriately internationalized
an SMTP Extension to permit UTF-8 [RFC3629] [RFC5198] mail addressing to utilize the full range of Unicode characters, an SMTP Extension to
and delivery of those extended header fields, support for permit UTF-8 [RFC3629] [RFC5198] mail addressing and delivery of
internationalization of delivery and service notifications [RFC3461] those extended header fields, support for internationalization of
[RFC3464], and (finally) a requirement for support of the 8BITMIME delivery and service notifications [RFC3461] [RFC3464], and (finally)
SMTP Extension [RFC1652] so that all of these can be transported a requirement for support of the 8BITMIME SMTP Extension [RFC6152] so
through the mail system without having to overcome the limitation that all of these can be transported through the mail system without
that header fields do not have content-transfer-encodings. having to overcome the limitation that header fields do not have
content-transfer-encodings.
4. Terminology 4. Terminology
This document assumes a reasonable understanding of the protocols and This document assumes a reasonable understanding of the protocols and
terminology of the core email standards as documented in [RFC5321] terminology of the core email standards as documented in [RFC5321]
and [RFC5322]. and [RFC5322].
4.1. Mail User and Mail Transfer Agents 4.1. Mail User and Mail Transfer Agents
Much of the description in this document depends on the abstractions Much of the description in this document depends on the abstractions
skipping to change at page 8, line 27 skipping to change at page 8, line 32
agent (typically not a human being) at that single address then agent (typically not a human being) at that single address then
causes the message to be redistributed to the target recipients. causes the message to be redistributed to the target recipients.
This agent sets the envelope return address of the redistributed This agent sets the envelope return address of the redistributed
message to a different address from that of the original single message to a different address from that of the original single
recipient message. Using a different envelope return address recipient message. Using a different envelope return address
(reverse-path) causes error (and other automatically generated) (reverse-path) causes error (and other automatically generated)
messages to go to an error handling address. messages to go to an error handling address.
Special provisions for managing mailing lists that might contain non- Special provisions for managing mailing lists that might contain non-
ASCII addresses are discussed in a document that is specific to that ASCII addresses are discussed in a document that is specific to that
topic [EAI-Mailinglist] [RFCNNNNbis-MailingList]. topic [RFC5983] [RFC5983bis-MailingList].
4.6. Conventional Message and Internationalized Message 4.6. Conventional Message and Internationalized Message
o A conventional message is one that does not use any extension o A conventional message is one that does not use any extension
defined in the SMTP extension document [RFC5336] or in the defined in the SMTP extension document [RFC5336] or in the
UTF8header specification [RFC5335], and is strictly conformant to UTF8header specification [RFC5335], and is strictly conformant to
RFC 5322 [RFC5322]. RFC 5322 [RFC5322].
o An internationalized message is a message utilizing one or more of o An internationalized message is a message utilizing one or more of
the extensions defined in this set of specifications, so that it the extensions defined in this set of specifications, so that it
skipping to change at page 9, line 41 skipping to change at page 9, line 46
information in email message headers to be expressed directly by information in email message headers to be expressed directly by
Unicode characters encoded in UTF-8 when the SMTP extension Unicode characters encoded in UTF-8 when the SMTP extension
described above is used. This document, possibly with one or more described above is used. This document, possibly with one or more
supplemental ones, will also need to address the interactions with supplemental ones, will also need to address the interactions with
MIME, including relationships between UTF8SMTPbis and internal MIME, including relationships between UTF8SMTPbis and internal
MIME headers and content types. MIME headers and content types.
o Extensions to delivery status and notification handling to adapt o Extensions to delivery status and notification handling to adapt
to internationalized addresses [RFC5337bis-DSN]. to internationalized addresses [RFC5337bis-DSN].
o Extensions to the IMAP protocol [RFC3501] to support o Forthcoming documents will specify extensions to the IMAP protocol
internationalized message headers [RFC5738bis-IMAP]. [RFC3501] to support internationalized message headers
[RFC5738bis-IMAP], Parallel extensions to the POP protocol
o Parallel extensions to the POP protocol [RFC5721] [RFC5721] [RFC5721bis-POP3], and some common properties of the two
[RFC5721bis-POP3]. [POPIMAP-downgrade].
6. Review of Experimental Results 6. Review of Experimental Results
The key difference between this set of protocols and the experimental The key difference between this set of protocols and the experimental
set that preceded them [RFC5335] [RFC5336] [RFC5337] [RFC5504] set that preceded them [RFC5335] [RFC5336] [RFC5337] [RFC5504]
[RFC5721] [RFC5738] [RFC5825] is that the earlier group provided a [RFC5721] [RFC5738] [RFC5825] is that the earlier group provided a
mechanism for in-transit downgrading of messages (described in detail mechanism for in-transit downgrading of messages (described in detail
in RFC 5504). That mechanism permitted, and essentially required, in RFC 5504). That mechanism permitted, and essentially required,
that each non-ASCII address be accompanied by an all-ASCII that each non-ASCII address be accompanied by an all-ASCII
equivalent. That, in turn, raised security concerns associated with equivalent. That, in turn, raised security concerns associated with
pairing of addresses that could not be authenticated. It also pairing of addresses that could not be authenticated. It also
introduced the first incompatible change to Internet mail addressing introduced the first incompatible change to Internet mail addressing
in many years, raising concerns about interoperability issues if the in many years, raising concerns about interoperability issues if the
new address forms "leaked" into legacy email implementations. The WG new address forms "leaked" into legacy email implementations. The WG
concluded that the advantages of in-transit downgrading, were it concluded that the advantages of in-transit downgrading, were it
feasible operationally, would be significant enough to overcome those feasible operationally, would be significant enough to overcome those
concerns. concerns.
Operationally that turned out to not be the case, with That turned out not to be the case, with interoperability problems
interoperability problems among initial implementations. Prior to among initial implementations. Prior to starting on the work that
starting on the work that led to this set of specifications, the WG led to this set of specifications, the WG concluded that the
concluded that the combination of requirements and long-term combination of requirements and long-term implications of that
implications of that earlier model were too complex to be earlier model were too complex to be satisfactory and that work
satisfactory and that work should move ahead without it. should move ahead without it.
The other significant change to the protocols themselves is that the
UTF8SMTPbis keyword is now required as an SMTP client announcement if
the extension is needed; in the experimental version, only the server
announcement that an extended envelope and/or content were permitted
was necessary.
7. Overview of Protocol Extensions and Changes 7. Overview of Protocol Extensions and Changes
7.1. SMTP Extension for Internationalized Email Address 7.1. SMTP Extension for Internationalized Email Address
An SMTP extension, "UTF8SMTPbis" is specified as follows: An SMTP extension, "UTF8SMTPbis" is specified as follows:
o Permits the use of UTF-8 strings in email addresses, both local o Permits the use of UTF-8 strings in email addresses, both local
parts and domain names. parts and domain names.
o Permits the selective use of UTF-8 strings in email message o Permits the selective use of UTF-8 strings in email message
headers (see Section 7.2). headers (see Section 7.2).
o Requires that the server advertise the 8BITMIME extension o Requires that the server advertise the 8BITMIME extension
[RFC1652] and that the client support 8-bit transmission so that [RFC6152] and that the client support 8-bit transmission so that
header information can be transmitted without using a special header information can be transmitted without using a special
content-transfer-encoding. content-transfer-encoding.
Some general principles affect the development decisions underlying Some general principles affect the development decisions underlying
this work. this work.
1. Email addresses enter subsystems (such as a user interface) that 1. Email addresses enter subsystems (such as a user interface) that
may perform charset conversions or other encoding changes. When may perform charset conversions or other encoding changes. When
the local part of the address includes characters outside the the local part of the address includes characters outside the
ASCII character repertoire, use of ASCII-compatible encoding ASCII character repertoire, use of ASCII-compatible encoding
skipping to change at page 11, line 15 skipping to change at page 11, line 24
2. An SMTP relay MUST 2. An SMTP relay MUST
* Either recognize the format explicitly, agreeing to do so via * Either recognize the format explicitly, agreeing to do so via
an ESMTP option, or an ESMTP option, or
* Reject the message or, if necessary, return a non-delivery * Reject the message or, if necessary, return a non-delivery
notification message, so that the sender can make another notification message, so that the sender can make another
plan. plan.
3. If the message cannot be forwarded because the next-hop system 3. If the message cannot be forwarded because the next-hop system
cannot accept the extension it MUST be rejected or a non-delivery cannot accept the extension, it MUST be rejected or a non-
message MUST be generated and sent. delivery message MUST be generated and sent.
4. In the interest of interoperability, charsets other than UTF-8 4. In the interest of interoperability, charsets other than UTF-8
are prohibited in mail addresses and message headers being are prohibited in mail addresses and message headers being
transmitted over the Internet. There is no practical way to transmitted over the Internet. There is no practical way to
identify multiple charsets properly with an extension similar to identify multiple charsets properly with an extension similar to
this without introducing great complexity. this without introducing great complexity.
Conformance to the group of standards specified here for email Conformance to the group of standards specified here for email
transport and delivery requires implementation of the SMTP Extension transport and delivery requires implementation of the SMTP Extension
specification and the UTF-8 Header specification. If the system specification and the UTF-8 Header specification. If the system
skipping to change at page 12, line 12 skipping to change at page 12, line 22
When email local parts are internationalized, they SHOULD be When email local parts are internationalized, they SHOULD be
accompanied by arrangements for the message headers to be in the accompanied by arrangements for the message headers to be in the
fully internationalized form. That form SHOULD use UTF-8 rather than fully internationalized form. That form SHOULD use UTF-8 rather than
ASCII as the base character set for the contents of header fields ASCII as the base character set for the contents of header fields
(protocol elements such as the header field names themselves are (protocol elements such as the header field names themselves are
unchanged and remain entirely in ASCII). For transition purposes and unchanged and remain entirely in ASCII). For transition purposes and
compatibility with legacy systems, this can done by extending the compatibility with legacy systems, this can done by extending the
traditional MIME encoding models for non-ASCII characters in headers traditional MIME encoding models for non-ASCII characters in headers
[RFC2045] [RFC2231], but even these should be based on UTF-8, rather [RFC2045] [RFC2231], but even these should be based on UTF-8, rather
than other encodings, if at all possible [IAB-idn-encoding]. than other encodings, if at all possible [RFC6055]. However, the
However, the target is fully internationalized message headers, as target is fully internationalized message headers, as discussed in
discussed in [RFC5335bis-Hdrs] and not an extended and painful [RFC5335bis-Hdrs] and not an extended and painful transition.
transition.
7.3. SMTP Service Extension for DSNs 7.3. SMTP Service Extension for DSNs
The existing Draft Standard Delivery status notifications (DSNs) The existing Draft Standard Delivery status notifications (DSNs)
specification [RFC3461] is limited to ASCII text in the machine specification [RFC3461] is limited to ASCII text in the machine
readable portions of the protocol. "International Delivery and readable portions of the protocol. "International Delivery and
Disposition Notifications" [RFC5337bis-DSN] adds a new address type Disposition Notifications" [RFC5337bis-DSN] adds a new address type
for international email addresses so an original recipient address for international email addresses so an original recipient address
with non-ASCII characters can be correctly preserved even after with non-ASCII characters can be correctly preserved even after
downgrading. If an SMTP server advertises both the UTF8SMTPbis and downgrading. If an SMTP server advertises both the UTF8SMTPbis and
skipping to change at page 13, line 37 skipping to change at page 13, line 46
the subsections below. the subsections below.
8.1. Downgrading before or during Message Submission 8.1. Downgrading before or during Message Submission
The IETF has traditionally avoided specifying the precise behavior of The IETF has traditionally avoided specifying the precise behavior of
MUAs to provide maximum flexibility in the associated user MUAs to provide maximum flexibility in the associated user
interfaces. The SMTP standard [RFC5321], Section 6.4, gives wide interfaces. The SMTP standard [RFC5321], Section 6.4, gives wide
latitude to MUAs and Submission servers as to what might be supplied latitude to MUAs and Submission servers as to what might be supplied
by the user as long as the result conforms with "on the wire" by the user as long as the result conforms with "on the wire"
standards once it is injected into the public Internet. In that standards once it is injected into the public Internet. In that
tradition, the discussion in the remainder of this section is tradition, the discussion in the remainder of Section 8 is provided
provided as general guidance rather than normative requirements. as general guidance rather than normative requirements.
Messages that requires these extensions will sometimes be transferred Messages that require these extensions will sometimes be transferred
to a system that does not support these extensions; it is likely that to a system that does not support these extensions; it is likely that
the most common cases will involve the combination of ASCII-only the most common cases will involve the combination of ASCII-only
forward-pointing addresses with a non-ASCII backward-pointing one. forward-pointing addresses with a non-ASCII backward-pointing one.
Until the extensions described here have been universally implemented Until the extensions described here have been universally implemented
in the Internet email environment, senders who prefer to use non- in the Internet email environment, senders who prefer to use non-
ASCII addresses (or raw UTF-8 characters in header fields) even when ASCII addresses (or raw UTF-8 characters in header fields) even when
their intended recipients use and expect all-ASCII ones will need to their intended recipients use and expect all-ASCII ones will need to
be especially careful about the error conditions that can arise, be especially careful about the error conditions that can arise,
especially if they are working in an environment in which non- especially if they are working in an environment in which non-
delivery messages (or other indications from submission servers) are delivery messages (or other indications from submission servers) are
skipping to change at page 15, line 39 skipping to change at page 15, line 48
Internationalization of addresses and message headers, especially in Internationalization of addresses and message headers, especially in
combination with variations on character coding that are inherent to combination with variations on character coding that are inherent to
Unicode, may make careful choices of addresses and careful Unicode, may make careful choices of addresses and careful
configuration of servers and DNS records even more important than configuration of servers and DNS records even more important than
they are for traditional Internet email. It is likely that, as they are for traditional Internet email. It is likely that, as
experience develops with the use of these protocols, it will be experience develops with the use of these protocols, it will be
desirable to produce one or more additional documents that offer desirable to produce one or more additional documents that offer
guidance for configuration and interfaces. A document that discusses guidance for configuration and interfaces. A document that discusses
issues with mail user agents (MUAs), especially with regard to issues with mail user agents (MUAs), especially with regard to
downgrading [EAI-MUA-issues], is expected to be developed in the EAI downgrading, is expected to be developed in the EAI Working Group.
Working Group. The subsections below address some other issues. The subsections below address some other issues.
10.1. Choices of Mailbox Names and Unicode Normalization 10.1. Choices of Mailbox Names and Unicode Normalization
It has long been the case that the email syntax permits choices about It has long been the case that the email syntax permits choices about
mailbox names that are unwise in practice if one actually intends the mailbox names that are unwise in practice if one actually intends the
mailboxes to be accessible to a broad range of senders. The most- mailboxes to be accessible to a broad range of senders. The most-
often-cited examples involve the use of case-sensitivity and tricky often-cited examples involve the use of case-sensitivity and tricky
quoting of embedded characters in mailbox local parts. These quoting of embedded characters in mailbox local parts. These
deliberately-unusual constructions are permitted by the protocols and deliberately-unusual constructions are permitted by the protocols and
servers are expected to support them. Although they can provide servers are expected to support them. Although they can provide
skipping to change at page 17, line 6 skipping to change at page 17, line 17
protocol for local-part strings essentially provide that: protocol for local-part strings essentially provide that:
* Unnormalized strings are valid, but sufficiently bad practice * Unnormalized strings are valid, but sufficiently bad practice
that they may not work reliably on a global basis. Servers that they may not work reliably on a global basis. Servers
should not depend on clients to send normalized forms but should not depend on clients to send normalized forms but
should be aware that procedures on client machines outside the should be aware that procedures on client machines outside the
control of the MUA may cause normalized strings to be sent control of the MUA may cause normalized strings to be sent
regardless of user intent. regardless of user intent.
* C0 (and presumably C1) controls (see The Unicode Standard * C0 (and presumably C1) controls (see The Unicode Standard
[Unicode52]) are prohibited, the first in RFC 5321 and the [Unicode]) are prohibited, the first in RFC 5321 and the second
second by an obvious extension from it [RFC5198]. by an obvious extension from it [RFC5198].
* Other kinds of punctuation, spaces, etc., are risky practice. * Other kinds of punctuation, spaces, etc., are risky practice.
Perhaps they will work, and SMTP receiver code is required to Perhaps they will work, and SMTP receiver code is required to
handle them without severe errors (even if such strings are not handle them without severe errors (even if such strings are not
accepted in addresses to be delivered on that server), but accepted in addresses to be delivered on that server), but
creating dependencies on them in mailbox names that are chosen creating dependencies on them in mailbox names that are chosen
is usually a bad practice and may lead to interoperability is usually a bad practice and may lead to interoperability
problems. problems.
11. Additional Issues 11. Additional Issues
This section identifies issues that are not covered, or not covered This section identifies issues that are not covered, or not covered
comprehensively, as part of this set of specifications, but that will comprehensively, as part of this set of specifications, but that will
require ongoing review as part of deployment of email address and require ongoing review as part of deployment of email address and
header internationalization. header internationalization.
11.1. Impact on URIs and IRIs 11.1. Impact on URIs and IRIs
The mailto: schema [RFC2368], and the discussion of it in the The mailto: schema [RFC6068], and the discussion of it in the
Internationalized Resource Identifier (IRI) specification [RFC3987] Internationalized Resource Identifier (IRI) specification [RFC3987]
may need to be modified when this work is completed and standardized. may need to be modified when this work is completed and standardized.
11.2. Use of Email Addresses as Identifiers 11.2. Use of Email Addresses as Identifiers
There are a number of places in contemporary Internet usage in which There are a number of places in contemporary Internet usage in which
email addresses are used as identifiers for individuals, including as email addresses are used as identifiers for individuals, including as
identifiers to Web servers supporting some electronic commerce sites identifiers to Web servers supporting some electronic commerce sites
and in some X.509 certificates [RFC5280]. These documents do not and in some X.509 certificates [RFC5280]. These documents do not
address those uses, but it is reasonable to expect that some address those uses, but it is reasonable to expect that some
skipping to change at page 18, line 9 skipping to change at page 18, line 22
that use the "encoded word" mechanism [RFC2047] to accommodate non- that use the "encoded word" mechanism [RFC2047] to accommodate non-
ASCII characters in some header fields. While extensions to both ASCII characters in some header fields. While extensions to both
POP3 [RFC1939] and IMAP [RFC3501] have been defined that include POP3 [RFC1939] and IMAP [RFC3501] have been defined that include
automatic upgrading of messages that carry non-ASCII information in automatic upgrading of messages that carry non-ASCII information in
encoded form -- including RFC 2047 decoding -- of messages by the encoded form -- including RFC 2047 decoding -- of messages by the
POP3 [RFC5721bis-POP3] or IMAP [RFC5738bis-IMAP] server, there are POP3 [RFC5721bis-POP3] or IMAP [RFC5738bis-IMAP] server, there are
message structures and MIME content-types for which that cannot be message structures and MIME content-types for which that cannot be
done or where the change would have unacceptable side effects. done or where the change would have unacceptable side effects.
For example, message parts that are cryptographically signed, using For example, message parts that are cryptographically signed, using
e.g., S/MIME [RFC3851] or Pretty Good Privacy (PGP) [RFC3156], cannot e.g., S/MIME [RFC5751] or Pretty Good Privacy (PGP) [RFC3156], cannot
be upgraded from the RFC 2047 form to normal UTF-8 characters without be upgraded from the RFC 2047 form to normal UTF-8 characters without
breaking the signature. Similarly, message parts that are encrypted breaking the signature. Similarly, message parts that are encrypted
may contain, when decrypted, header fields that use the RFC 2047 may contain, when decrypted, header fields that use the RFC 2047
encoding; such messages cannot be 'fully' upgraded without access to encoding; such messages cannot be 'fully' upgraded without access to
cryptographic keys. cryptographic keys.
Similar issues may arise if messages are signed and then subsequently Similar issues may arise if messages are signed and then subsequently
downgraded, e.g., as discussed in Section 8.1, and then an attempt is downgraded, e.g., as discussed in Section 8.1, and then an attempt is
made to upgrade them to the original form and then verify the made to upgrade them to the original form and then verify the
signatures. Even the very subtle changes that may result from signatures. Even the very subtle changes that may result from
skipping to change at page 19, line 12 skipping to change at page 19, line 24
the extensions specified in this series of documents and special the extensions specified in this series of documents and special
measures may be needed to properly detect and process them. measures may be needed to properly detect and process them.
12. Key Changes From the Experimental Protocols and Framework 12. Key Changes From the Experimental Protocols and Framework
The original framework for internationalized email addresses and The original framework for internationalized email addresses and
headers was described in RFC 4952 and a subsequent set of headers was described in RFC 4952 and a subsequent set of
experimental protocol documents. Those relationships are described experimental protocol documents. Those relationships are described
in Section 3. The key architectural difference between the in Section 3. The key architectural difference between the
experimental specifications and this newer set is that the earlier experimental specifications and this newer set is that the earlier
specifications supported in-transit downgrading. That mechanisms specifications supported in-transit downgrading. Those mechanisms
included the definition of syntax and functions to support passing included the definition of syntax and functions to support passing
alternate, all-ASCII, addresses with the non-ASCII ones as well as alternate, all-ASCII, addresses with the non-ASCII ones as well as
special headers to indicate the downgraded status of messages. Those special headers to indicate the downgraded status of messages. Those
features were eliminated after experimentation indicated that they features were eliminated after experimentation indicated that they
were more complex and less necessary than had been assumed earlier. were more complex and less necessary than had been assumed earlier.
Those issues are described in more detail in Section 6 and Section 9. Those issues are described in more detail in Section 6 and Section 9.
13. IANA Considerations 13. IANA Considerations
This overview description and framework document does not contemplate This overview description and framework document does not contemplate
skipping to change at page 19, line 36 skipping to change at page 19, line 48
14. Security Considerations 14. Security Considerations
Any expansion of permitted characters and encoding forms in email Any expansion of permitted characters and encoding forms in email
addresses raises some risks. There have been discussions on so addresses raises some risks. There have been discussions on so
called "IDN-spoofing" or "IDN homograph attacks". These attacks called "IDN-spoofing" or "IDN homograph attacks". These attacks
allow an attacker (or "phisher") to spoof the domain or URLs of allow an attacker (or "phisher") to spoof the domain or URLs of
businesses. The same kind of attack is also possible on the local businesses. The same kind of attack is also possible on the local
part of internationalized email addresses. It should be noted that part of internationalized email addresses. It should be noted that
the proposed fix involving forcing all displayed elements into the proposed fix involving forcing all displayed elements into
normalized lower-case works for domain names in URLs, but not email normalized lower-case works for domain names in URLs, but not for
local parts since those are case sensitive. email local parts since those are case sensitive.
Since email addresses are often transcribed from business cards and Since email addresses are often transcribed from business cards and
notes on paper, they are subject to problems arising from confusable notes on paper, they are subject to problems arising from confusable
characters (see [RFC4690]). These problems are somewhat reduced if characters (see [RFC4690]). These problems are somewhat reduced if
the domain associated with the mailbox is unambiguous and supports a the domain associated with the mailbox is unambiguous and supports a
relatively small number of mailboxes whose names follow local system relatively small number of mailboxes whose names follow local system
conventions. They are increased with very large mail systems in conventions. They are increased with very large mail systems in
which users can freely select their own addresses. which users can freely select their own addresses.
The internationalization of email addresses and message headers must The internationalization of email addresses and message headers must
not leave the Internet less secure than it is without the required not leave the Internet less secure than it is without the required
extensions. The requirements and mechanisms documented in this set extensions. The requirements and mechanisms documented in this set
of specifications do not, in general, raise any new security issues. of specifications do not, in general, raise any new security issues.
They do require a review of issues associated with confusable They do require a review of issues associated with confusable
characters -- a topic that is being explored thoroughly elsewhere characters -- a topic that is being explored thoroughly elsewhere
(see, e.g., RFC 4690 [RFC4690]) -- and, potentially, some issues with (see, e.g., RFC 4690 [RFC4690]) -- and, potentially, some issues with
UTF-8 normalization, discussed in RFC 3629 [RFC3629], and other UTF-8 normalization, discussed in RFC 3629 [RFC3629], and other
transformations. Normalization and other issues associated with transformations. Normalization and other issues associated with
transformations and standard forms are also part of the subject of transformations and standard forms are also part of the subject of
work described elsewhere [RFC5198] [RFC5893] [IAB-idn-encoding]. work described elsewhere [RFC5198] [RFC5893] [RFC6055].
Some issues specifically related to internationalized addresses and Some issues specifically related to internationalized addresses and
message headers are discussed in more detail in the other documents message headers are discussed in more detail in the other documents
in this set. However, in particular, caution should be taken that in this set. However, in particular, caution should be taken that
any "downgrading" mechanism, or use of downgraded addresses, does not any "downgrading" mechanism, or use of downgraded addresses, does not
inappropriately assume authenticated bindings between the inappropriately assume authenticated bindings between the
internationalized and ASCII addresses. This potential problem can be internationalized and ASCII addresses. This potential problem can be
mitigated somewhat by enforcing the expectation that most or all such mitigated somewhat by enforcing the expectation that most or all such
transformations will be performed prior to final delivery by systems transformations will be performed prior to final delivery by systems
that are presumed to be under the administrative control of the that are presumed to be under the administrative control of the
skipping to change at page 21, line 40 skipping to change at page 22, line 5
(formerly United States of America (formerly United States of America
Standards Institute), "USA Code for Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, Information Interchange", ANSI X3.4-1968,
1968. 1968.
ANSI X3.4-1968 has been replaced by newer ANSI X3.4-1968 has been replaced by newer
versions with slight modifications, but the versions with slight modifications, but the
1968 version remains definitive for the 1968 version remains definitive for the
Internet. Internet.
[RFC1652] Klensin, J., Freed, N., Rose, M.,
Stefferud, E., and D. Crocker, "SMTP
Service Extension for 8bit-MIMEtransport",
RFC 1652, July 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997. RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation [RFC3629] Yergeau, F., "UTF-8, a transformation
format of ISO 10646", STD 63, RFC 3629, format of ISO 10646", STD 63, RFC 3629,
November 2003. November 2003.
[RFC5321] Klensin, J., "Simple Mail Transfer [RFC5321] Klensin, J., "Simple Mail Transfer
Protocol", RFC 5321, October 2008. Protocol", RFC 5321, October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message [RFC5322] Resnick, P., Ed., "Internet Message
Format", RFC 5322, October 2008. Format", RFC 5322, October 2008.
[RFC5335bis-Hdrs] Yang, A. and S. Steele, "Internationalized [RFC5335bis-Hdrs] Yang, A., Steele, S., and N. Freed,
Email Headers", July 2010, <https:// "Internationalized Email Headers",
September 2011, <https://
datatracker.ietf.org/doc/ datatracker.ietf.org/doc/
draft-ietf-eai-rfc5335bis/>. draft-ietf-eai-rfc5335bis/>.
[RFC5336bis-SMTP] Yao, J. and W. Mao, "SMTP Extension for [RFC5336bis-SMTP] Yao, J. and W. Mao, "SMTP Extension for
Internationalized Email Address", Internationalized Email Address",
August 2010, <https://datatracker.ietf.org/ August 2011, <https://datatracker.ietf.org/
doc/draft-ietf-eai-rfc5336bis/>. doc/draft-ietf-eai-rfc5336bis/>.
[RFC5337bis-DSN] Not yet posted?, "Internationalized [RFC5337bis-DSN] Hansen, T., Newman, C., and A. Melnikov,
Delivery Status and Disposition "Internationalized Delivery Status and
Notifications", Unwritten waiting for I-D, Disposition Notifications", October 2011, <
2010. https://datatracker.ietf.org/doc/
draft-ietf-eai-rfc5337bis-dsn/>.
[RFC5721bis-POP3] Not yet posted?, "POP3 Support for UTF-8",
Unwritten waiting for I-D, 2010.
[RFC5738bis-IMAP] Not yet posted?, "IMAP Support for UTF-8",
Unwritten waiting for I-D, 2010.
[RFC5890] Klensin, J., "Internationalized Domain [RFC5890] Klensin, J., "Internationalized Domain
Names for Applications (IDNA): Definitions Names for Applications (IDNA): Definitions
and Document Framework", RFC 5890, and Document Framework", RFC 5890,
August 2010. August 2010.
[RFCNNNNbis-MailingList] Not yet posted?, "Mailing Lists and [RFC6152] Klensin, J., Freed, N., Rose, M., and D.
Internationalized Email Addresses", First Crocker, "SMTP Service Extension for 8-bit
Version still not in RFC Editor queue https MIME Transport", STD 71, RFC 6152,
://datatracker.ietf.org/doc/ March 2011.
draft-ietf-eai-mailinglist/,
Unwritten waiting for I-D, 2010.
16.2. Informative References 16.2. Informative References
[EAI-MUA-issues] EAI WG, "Still-unnamed proposed document on [POPIMAP-downgrade] Fujiwara, K., "Post-delivery Message
MUA issues", Not assigned or agreed to yet, Downgrading for Internationalized Email
2011. Messages", Work in Progress, July 2011, <ht
tps://datatracker.ietf.org/doc/
Note to IESG and RFC Editor: While there is draft-ietf-eai-popimap-downgrade/>.
provision for a document on this subject in
the WG Charter, there is, as yet, no plan
for producing it or even for adding it to
the WG's task list with benchmarks. If the
present document is approved for
publication before the is at least a title
and author(s) for an I-D, the citation and
reference should simply be dropped.
[EAI-Mailinglist] Gellens, R., "Mailing Lists and
Internationalized Email Addresses",
June 2010, <https://datatracker.ietf.org/
doc/draft-ietf-eai-mailinglist/>.
[IAB-idn-encoding] Thaler, D., Klensin, J., and S. Cheshire,
"IAB Thoughts on Encodings for
Internationalized Domain Names", 2010, <htt
ps://datatracker.ietf.org/doc/
draft-iab-idn-encoding/>.
[RFC0821] Postel, J., "Simple Mail Transfer [RFC0821] Postel, J., "Simple Mail Transfer
Protocol", STD 10, RFC 821, August 1982. Protocol", STD 10, RFC 821, August 1982.
[RFC1123] Braden, R., "Requirements for Internet [RFC1123] Braden, R., "Requirements for Internet
Hosts - Application and Support", STD 3, Hosts - Application and Support", STD 3,
RFC 1123, October 1989. RFC 1123, October 1989.
[RFC1939] Myers, J. and M. Rose, "Post Office [RFC1939] Myers, J. and M. Rose, "Post Office
Protocol - Version 3", STD 53, RFC 1939, Protocol - Version 3", STD 53, RFC 1939,
skipping to change at page 24, line 5 skipping to change at page 23, line 35
[RFC2047] Moore, K., "MIME (Multipurpose Internet [RFC2047] Moore, K., "MIME (Multipurpose Internet
Mail Extensions) Part Three: Message Header Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII Text", RFC 2047, Extensions for Non-ASCII Text", RFC 2047,
November 1996. November 1996.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter [RFC2231] Freed, N. and K. Moore, "MIME Parameter
Value and Encoded Word Extensions: Characte Value and Encoded Word Extensions: Characte
r Sets, Languages, and Continuations", r Sets, Languages, and Continuations",
RFC 2231, November 1997. RFC 2231, November 1997.
[RFC2368] Hoffman, P., Masinter, L., and J. Zawinski,
"The mailto URL scheme", RFC 2368,
July 1998.
[RFC2821] Klensin, J., "Simple Mail Transfer [RFC2821] Klensin, J., "Simple Mail Transfer
Protocol", RFC 2821, April 2001. Protocol", RFC 2821, April 2001.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and [RFC3156] Elkins, M., Del Torto, D., Levien, R., and
T. Roessler, "MIME Security with OpenPGP", T. Roessler, "MIME Security with OpenPGP",
RFC 3156, August 2001. RFC 3156, August 2001.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol [RFC3461] Moore, K., "Simple Mail Transfer Protocol
(SMTP) Service Extension for Delivery (SMTP) Service Extension for Delivery
Status Notifications (DSNs)", RFC 3461, Status Notifications (DSNs)", RFC 3461,
skipping to change at page 24, line 34 skipping to change at page 24, line 11
[RFC3492] Costello, A., "Punycode: A Bootstring [RFC3492] Costello, A., "Punycode: A Bootstring
encoding of Unicode for Internationalized encoding of Unicode for Internationalized
Domain Names in Applications (IDNA)", Domain Names in Applications (IDNA)",
RFC 3492, March 2003. RFC 3492, March 2003.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS
PROTOCOL - VERSION 4rev1", RFC 3501, PROTOCOL - VERSION 4rev1", RFC 3501,
March 2003. March 2003.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.1
Message Specification", RFC 3851,
July 2004.
[RFC3987] Duerst, M. and M. Suignard, [RFC3987] Duerst, M. and M. Suignard,
"Internationalized Resource Identifiers "Internationalized Resource Identifiers
(IRIs)", RFC 3987, January 2005. (IRIs)", RFC 3987, January 2005.
[RFC4155] Hall, E., "The application/mbox Media [RFC4155] Hall, E., "The application/mbox Media
Type", RFC 4155, September 2005. Type", RFC 4155, September 2005.
[RFC4409] Gellens, R. and J. Klensin, "Message [RFC4409] Gellens, R. and J. Klensin, "Message
Submission for Mail", RFC 4409, April 2006. Submission for Mail", RFC 4409, April 2006.
skipping to change at page 25, line 43 skipping to change at page 25, line 16
September 2008. September 2008.
[RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading
Mechanism for Email Address Mechanism for Email Address
Internationalization", RFC 5504, Internationalization", RFC 5504,
March 2009. March 2009.
[RFC5721] Gellens, R. and C. Newman, "POP3 Support [RFC5721] Gellens, R. and C. Newman, "POP3 Support
for UTF-8", RFC 5721, February 2010. for UTF-8", RFC 5721, February 2010.
[RFC5721bis-POP3] Gellens, R., Yao, J., and K. Fujiwara,
"POP3 Support for UTF-8", Work in Progress,
July 2011, <https://datatracker.ietf.org/
doc/draft-ietf-eai-rfc5721bis>.
[RFC5738] Resnick, P. and C. Newman, "IMAP Support [RFC5738] Resnick, P. and C. Newman, "IMAP Support
for UTF-8", RFC 5738, March 2010. for UTF-8", RFC 5738, March 2010.
[RFC5738bis-IMAP] Resnick, P., Newman, C., and S. Shen, "IMAP
Support for UTF-8", Work in Progress,
July 2011, <https://datatracker.ietf.org/
doc/draft-ietf-eai-5738bis/>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/
Multipurpose Internet Mail Extensions
(S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5825] Fujiwara, K. and B. Leiba, "Displaying [RFC5825] Fujiwara, K. and B. Leiba, "Displaying
Downgraded Messages for Email Address Downgraded Messages for Email Address
Internationalization", RFC 5825, Internationalization", RFC 5825,
April 2010. April 2010.
[RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P.,
and D. Crocker, "DomainKeys Identified Mail and D. Crocker, "DomainKeys Identified Mail
(DKIM) Development, Deployment, and (DKIM) Development, Deployment, and
Operations", RFC 5863, May 2010. Operations", RFC 5863, May 2010.
skipping to change at page 26, line 26 skipping to change at page 26, line 15
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left
Scripts for Internationalized Domain Names Scripts for Internationalized Domain Names
for Applications (IDNA)", RFC 5893, for Applications (IDNA)", RFC 5893,
August 2010. August 2010.
[RFC5894] Klensin, J., "Internationalized Domain [RFC5894] Klensin, J., "Internationalized Domain
Names for Applications (IDNA): Background, Names for Applications (IDNA): Background,
Explanation, and Rationale", RFC 5894, Explanation, and Rationale", RFC 5894,
August 2010. August 2010.
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard [RFC5983] Gellens, R., "Mailing Lists and
Annex #15: Unicode Normalization Forms", Internationalized Email Addresses",
March 2008, RFC 5983, October 2010.
<http://www.unicode.org/reports/tr15/>.
[Unicode52] The Unicode Consortium. The Unicode [RFC5983bis-MailingList] "Mailing Lists and Internationalized Email
Addresses", Unwritten waiting for I-D,
2011.
[RFC6055] Thaler, D., Klensin, J., and S. Cheshire,
"IAB Thoughts on Encodings for
Internationalized Domain Names", RFC 6055,
February 2011.
[RFC6068] Duerst, M., Masinter, L., and J. Zawinski,
"The 'mailto' URI Scheme", RFC 6068,
October 2010.
[Unicode] The Unicode Consortium. The Unicode
Standard, Version 5.2.0, defined by:, "The Standard, Version 5.2.0, defined by:, "The
Unicode Standard, Version 5.2.0", (Mountain Unicode Standard, Version 5.2.0", (Mountain
View, CA: The Unicode Consortium, View, CA: The Unicode Consortium,
2009. ISBN 978-1-936213-00-9)., <http:// 2009. ISBN 978-1-936213-00-9)., <http://
www.unicode.org/versions/Unicode5.2.0/>. www.unicode.org/versions/Unicode5.2.0/>.
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard
Annex #15: Unicode Normalization Forms",
March 2008,
<http://www.unicode.org/reports/tr15/>.
Appendix A. Change Log Appendix A. Change Log
[[RFC Editor: Please remove this section prior to publication.]] [[RFC Editor: Please remove this section prior to publication.]]
A.1. Changes between -00 and -01 A.1. Changes between -00 and -01
o Because there has been no feedback on the mailing list, updated o Because there has been no feedback on the mailing list, updated
the various questions to refer to this version as well. the various questions to refer to this version as well.
o Reflected RFC Editor erratum #1507 by correcting terminology for o Reflected RFC Editor erratum #1507 by correcting terminology for
skipping to change at page 30, line 5 skipping to change at page 29, line 48
o Several other small editorial corrections, removal of uncited o Several other small editorial corrections, removal of uncited
reference to LMTP, added a few citations for clarity. reference to LMTP, added a few citations for clarity.
A.10. Changes between -09 and -10 A.10. Changes between -09 and -10
This version contains additional small editorial changes resulting This version contains additional small editorial changes resulting
from IESG comments and review of -09 changes. Some more significant from IESG comments and review of -09 changes. Some more significant
clarifications appear in Section 10.1 clarifications appear in Section 10.1
A.11. Changes between -10 and -11
While -10 was approved for publication by the IESG (after IETF Last
Call) in September 2010, the document then went into a reference hold
in the RFC Editor queue. Issued identified during and after Last
Call for the other three core EAI documents (5335bis, 5336bis, and
5337bis) required reopening this document and making some minor
additional changes.
o Reworded the descriptions of the POP, IMAP, and mailing list
documents and moved them to Informative. Notes in the XML of
earier versions of this draft indicate that they were listed as
Normative merely as a temporary convenience. Examination and
reclassification of them apparently slipped through the cracks.
o Reclassified the document to standards track to eliminate
normative reference problems from other EAI documents.
o References, other than the two Unicode ones, have been updated for
the convenience of reviewers and the RFC Editor. A note has been
inserted into the XML requesting that the RFC Editor update the
Unicode references to be current at the time of publication.
o Explicitly notes status of documents obsoleted by this one and
moves them to Historic.
o Updated author contact information.
Authors' Addresses Authors' Addresses
John C KLENSIN John C KLENSIN
1770 Massachusetts Ave, #322 1770 Massachusetts Ave, #322
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
Phone: +1 617 491 5735 Phone: +1 617 491 5735
EMail: john-ietf@jck.com EMail: john-ietf@jck.com
YangWoo KO YangWoo KO
ICU 112-202 Malgeunachim APT. Nae-dong
119 Munjiro Seo-gu, Daejeon 302-981
Yuseong-gu, Daejeon 305-732
Republic of Korea Republic of Korea
EMail: yw@mrko.pe.kr EMail: yangwooko@gmail.com
 End of changes. 47 change blocks. 
124 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/