draft-ietf-eai-frmwrk-4952bis-08.txt   draft-ietf-eai-frmwrk-4952bis-09.txt 
Email Address Internationalization J. Klensin Email Address Internationalization J. Klensin
(EAI) (EAI)
Internet-Draft Y. Ko Internet-Draft Y. Ko
Obsoletes: RFCs 4952, 5504, 5825 ICU Obsoletes: 4952, 5504, 5825 ICU
(if approved) September 17, 2010 (if approved) September 23, 2010
Intended status: Informational Intended status: Informational
Expires: March 21, 2011 Expires: March 27, 2011
Overview and Framework for Internationalized Email Overview and Framework for Internationalized Email
draft-ietf-eai-frmwrk-4952bis-08 draft-ietf-eai-frmwrk-4952bis-09
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 21, 2011. This Internet-Draft will expire on March 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 7 skipping to change at page 2, line 29
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Role of This Specification . . . . . . . . . . . . . . . . . . 5 2. Role of This Specification . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 7 4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 6
4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 8 4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 7
4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Conventional Message and Internationalized Message . . . . 9 4.6. Conventional Message and Internationalized Message . . . . 8
4.7. Undeliverable Messages, Notification, and Delivery 4.7. Undeliverable Messages, Notification, and Delivery
Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 9 Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Overview of the Approach and Document Plan . . . . . . . . . . 10 5. Overview of the Approach and Document Plan . . . . . . . . . . 9
6. Review of Experimental Results . . . . . . . . . . . . . . . . 10 6. Review of Experimental Results . . . . . . . . . . . . . . . . 9
7. Overview of Protocol Extensions and Changes . . . . . . . . . 11 7. Overview of Protocol Extensions and Changes . . . . . . . . . 10
7.1. SMTP Extension for Internationalized Email Address . . . . 11 7.1. SMTP Extension for Internationalized Email Address . . . . 10
7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 12 7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11
7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 13 7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12
8. Downgrading before and after SMTP Transactions . . . . . . . . 13 8. Downgrading before and after SMTP Transactions . . . . . . . . 12
8.1. Downgrading before or during Message Submission . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . . . 15 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 16 9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 15
10. User Interface and Configuration Issues . . . . . . . . . . . 16 10. User Interface and Configuration Issues . . . . . . . . . . . 15
10.1. Choices of Mailbox Names and Unicode Normalization . . . . 16 10.1. Choices of Mailbox Names and Unicode Normalization . . . . 15
11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 18 11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 18 11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 17
11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 18 11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 17
11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 18 11.3. Encoded Words, Signed Messages, and Downgrading . . . . . 17
11.4. Other Uses of Local Parts . . . . . . . . . . . . . . . . 19 11.4. Other Uses of Local Parts . . . . . . . . . . . . . . . . 18
11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 19 11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 18
12. Key Changes From the Experimental Protocols and Framework . . 19 12. Key Changes From the Experimental Protocols and Framework . . 18
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14. Security Considerations . . . . . . . . . . . . . . . . . . . 20 14. Security Considerations . . . . . . . . . . . . . . . . . . . 19
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
16.1. Normative References . . . . . . . . . . . . . . . . . . . 22 16.1. Normative References . . . . . . . . . . . . . . . . . . . 21
16.2. Informative References . . . . . . . . . . . . . . . . . . 23 16.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26
A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 27 A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 26
A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 27 A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 26
A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 29 A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 28
A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 29 A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 28
A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 29 A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 28
A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 29 A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 28
A.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 29 A.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 28
A.8. Changes between -07 and -08 (after IETF Last Call) . . . . 30 A.8. Changes between -07 and -08 (after IETF Last Call) . . . . 29
A.9. Changes between -08 and -09 . . . . . . . . . . . . . . . 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 10, line 25 skipping to change at page 9, line 25
encoding of email message headers to permit non-ASCII characters to encoding of email message headers to permit non-ASCII characters to
be represented directly. Each important component of the work is be represented directly. Each important component of the work is
described in a separate document. The document set, whose members described in a separate document. The document set, whose members
are described below, also contains informational documents whose are described below, also contains informational documents whose
purpose is to provide implementation suggestions and guidance for the purpose is to provide implementation suggestions and guidance for the
protocols. protocols.
In addition to this document, the following documents make up this In addition to this document, the following documents make up this
specification and provide advice and context for it. specification and provide advice and context for it.
o SMTP extensions. This document [RFC5336bis-SMTP] provides an SMTP o SMTP extension. The SMTP extension document [RFC5336bis-SMTP]
extension (as provided for in RFC 5321) for internationalized provides an SMTP extension (as provided for in RFC 5321) for
addresses. internationalized addresses.
o Email message headers in UTF-8. This document [RFC5335bis-Hdrs] o Email message headers in UTF-8. The email message header document
essentially updates RFC 5322 to permit some information in email [RFC5335bis-Hdrs] essentially updates RFC 5322 to permit some
message headers to be expressed directly by Unicode characters information in email message headers to be expressed directly by
encoded in UTF-8 when the SMTP extension described above is used. Unicode characters encoded in UTF-8 when the SMTP extension
This document, possibly with one or more supplemental ones, will described above is used. This document, possibly with one or more
also need to address the interactions with MIME, including supplemental ones, will also need to address the interactions with
relationships between UTF8SMTPbis and internal MIME headers and MIME, including relationships between UTF8SMTPbis and internal
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 to support internationalized o Extensions to the IMAP protocol [RFC3501] to support
message headers [RFC5738bis-IMAP]. internationalized message headers [RFC5738bis-IMAP].
o Parallel extensions to the POP protocol [RFC5721] o Parallel extensions to the POP protocol [RFC5721]
[RFC5721bis-POP3]. [RFC5721bis-POP3].
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
skipping to change at page 11, line 45 skipping to change at page 10, line 45
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 [RFC1652] 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 left hand side of the address includes characters outside the the local part of the address includes characters outside the
US-ASCII character repertoire, use of ASCII-compatible encoding ASCII character repertoire, use of ASCII-compatible encoding
(ACE) [RFC3492] [RFC5890] on the right hand side is discouraged (ACE) [RFC3492] [RFC5890] in the domain part is discouraged to
to promote consistent processing of characters throughout the promote consistent processing of characters throughout the
address. address.
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.
skipping to change at page 12, line 27 skipping to change at page 11, line 27
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
implements IMAP or POP, it MUST conform to the i18n IMAP or POP implements IMAP or POP, it MUST conform to the i18n IMAP
specifications respectively. [RFC5738bis-IMAP] or POP [RFC5721bis-POP3] specifications
respectively.
7.2. Transmission of Email Header Fields in UTF-8 Encoding 7.2. Transmission of Email Header Fields in UTF-8 Encoding
There are many places in MUAs or in a user presentation in which There are many places in MUAs or in a user presentation in which
email addresses or domain names appear. Examples include the email addresses or domain names appear. Examples include the
conventional From, To, or Cc header fields; Message-ID and conventional From, To, or Cc header fields; Message-ID and
In-Reply-To header fields that normally contain domain names (but In-Reply-To header fields that normally contain domain names (but
that may be a special case); and in message bodies. Each of these that may be a special case); and in message bodies. Each of these
must be examined from an internationalization perspective. The user must be examined from an internationalization perspective. The user
will expect to see mailbox and domain names in local characters, and will expect to see mailbox and domain names in local characters, and
skipping to change at page 13, line 10 skipping to change at page 12, line 11
message headers and message bodies as possible. message headers and message bodies as possible.
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 [IAB-idn-encoding].
However, the target is fully internationalized message headers, as However, the target is fully internationalized message headers, as
discussed in [RFC5335bis-Hdrs] and not an extended and painful discussed in [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
skipping to change at page 16, line 48 skipping to change at page 15, line 48
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 [EAI-MUA-issues], is expected to be developed in the EAI
Working Group. The subsections below address some other issues. Working Group. 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. While these quoting of embedded characters in mailbox local parts. These
are permitted by the protocols and servers are expected to support formations are permitted by the protocols and servers are expected to
them and there are special cases where they can provide value, taking support them. Although they can provide value in special cases,
advantage of those features is almost always bad practice unless the taking advantage of them is almost always bad practice unless the
intent is to create some form of security by obscurity. intent is to create some form of security by obscurity.
In the absence of these extensions, SMTP clients and servers are In the absence of these extensions, SMTP clients and servers are
constrained to using only those addresses permitted by RFC 5321. The constrained to using only those addresses permitted by RFC 5321. The
local parts of those addresses MAY be made up of any ASCII characters local parts of those addresses MAY be made up of any ASCII characters
except the control characters that 5321 prohibits, although some of except the control characters that 5321 prohibits, although some of
them MUST be quoted as specified there. It is notable in an them MUST be quoted as specified there. It is notable in an
internationalization context that there is a long history on some internationalization context that there is a long history on some
systems of using overstruck ASCII characters (a character, a systems of using overstruck ASCII characters (a character, a
backspace, and another character) within a quoted string to backspace, and another character) within a quoted string to
approximate non-ASCII characters. This form of internationalization approximate non-ASCII characters. This form of internationalization
was permitted by RFC 821 [RFC0821] but is prohibited by RFC 5321 was permitted by RFC 821 [RFC0821] but is prohibited by RFC 5321
because it requires a backspace character (a prohibited C0 control). because it requires a backspace character (a prohibited C0 control).
Because RFC 5321 (and its predecessor, RFC 2821) prohibit the use of Because RFC 5321 (and its predecessor, RFC 2821) prohibit the use of
this character in ASCII mailbox names and it is even more problematic this character in ASCII mailbox names and it is even more problematic
(for canonicalization and normalization reasons) in non-ASCII (for canonicalization and normalization reasons) in non-ASCII
strings, backspace MUST NOT appear in UTF8SMTPbis mailbox names. strings, backspace MUST NOT appear in UTF8SMTPbis mailbox names.
For the particular case of EAI mailbox names, special attention MUST For the particular case of mailbox names that contain non-ASCII
be paid to Unicode normalization [Unicode-UAX15], in part because characters in the local part, domain part, or both, special attention
Unicode strings may be normalized by other processes independent of MUST be paid to Unicode normalization [Unicode-UAX15], in part
what a mail protocol specifies (this is exactly analogous to what may because Unicode strings may be normalized by other processes
happen with quoting and dequoting in traditional addresses). independent of what a mail protocol specifies (this is exactly
Consequently, the following principles are offered as advice to those analogous to what may happen with quoting and dequoting in
who are selecting names for mailboxes: traditional addresses). Consequently, the following principles are
offered as advice to those who are selecting names for mailboxes:
o In general, it is wise to support addresses in Normalized form, o In general, it is wise to support addresses in Normalized form,
using either Normalization Form NFC and, except in unusual using either Normalization Form NFC and, except in unusual
circumstances, NFKC. circumstances, NFKC.
o It may be wise to support other forms of the same local-part o It may be wise to support other forms of the same local-part
string, either as aliases or by normalization of strings reaching string, either as aliases or by normalization of strings reaching
the delivery server, in the event that the sender does not send the delivery server, in the event that the sender does not send
the strings in normalized form. the strings in normalized form.
skipping to change at page 18, line 14 skipping to change at page 17, line 15
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 discussed in the Internationalized The mailto: schema [RFC2368], and the discussion of it in the
Resource Identifier (IRI) specification [RFC3987] may need to be Internationalized Resource Identifier (IRI) specification [RFC3987]
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
difficulties will be encountered when internationalized addresses are difficulties will be encountered when internationalized addresses are
first used in those contexts, many of which cannot even handle the first used in those contexts, many of which cannot even handle the
skipping to change at page 19, line 38 skipping to change at page 18, line 39
delivery MTAs in determining the mailbox names they will accept and delivery MTAs in determining the mailbox names they will accept and
how they are interpreted. how they are interpreted.
11.5. Non-Standard Encapsulation Formats 11.5. Non-Standard Encapsulation Formats
Some applications use formats similar to the application/mbox format Some applications use formats similar to the application/mbox format
defined in [RFC4155] instead of the message/digest form described in defined in [RFC4155] instead of the message/digest form described in
RFC 2046, Section 5.1.5 [RFC2046] to transfer multiple messages as RFC 2046, Section 5.1.5 [RFC2046] to transfer multiple messages as
single units. Insofar as such applications assume that all stored single units. Insofar as such applications assume that all stored
messages use the message/rfc822 format described in RFC 2046, Section messages use the message/rfc822 format described in RFC 2046, Section
5.2.1 [RFC2046] with US-ASCII message headers, they are not ready for 5.2.1 [RFC2046] with ASCII message headers, they are not ready for
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 including providing specifications supported in-transit downgrading, which included the
syntax and functions to support passing alternate, all-ASCII, definition of syntax and functions to support passing alternate, all-
addresses with the non-ASCII ones and special headers to indicate the ASCII, addresses with the non-ASCII ones as well as special headers
downgraded status of messages. Those features were eliminated after to indicate the downgraded status of messages. Those features were
experimentation indicated that they were more complex and less eliminated after experimentation indicated that they were more
necessary than had been assumed earlier. Those issues are described complex and less necessary than had been assumed earlier. Those
in more detail in Section 6 and Section 9. 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
any IANA registrations or other actions. Some of the documents in any IANA registrations or other actions. Some of the documents in
the group have their own IANA considerations sections and the group have their own IANA considerations sections and
requirements. requirements.
14. Security Considerations 14. Security Considerations
skipping to change at page 21, line 5 skipping to change at page 20, line 7
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] [IAB-idn-encoding].
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. Expecting and most or all internationalized and ASCII addresses. This potential problem can be
such transformations prior to final delivery be done by systems that mitigated somewhat by enforcing the expectation that most or all such
are presumed to be under the administrative control of the sending transformations will be performed prior to final delivery by systems
user ameliorates the potential problem somewhat as compared to what that are presumed to be under the administrative control of the
it would be if the relationships were changed in transit. sending user (as opposed to being performed in transit by entities
that are not under the administrative control of the sending user).
The new UTF-8 header and message formats might also raise, or The new UTF-8 header and message formats might also raise, or
aggravate, another known issue. If the model creates new forms of an aggravate, another known issue. If the model creates new forms of an
'invalid' or 'malformed' message, then a new email attack is created: 'invalid' or 'malformed' message, then a new email attack is created:
in an effort to be robust, some or most agents will accept such in an effort to be robust, some or most agents will accept such
message and interpret them as if they were well-formed. If a filter message and interpret them as if they were well-formed. If a filter
interprets such a message differently than the MUA used by the interprets such a message differently than the MUA used by the
recipient, then it may be possible to create a message that appears recipient, then it may be possible to create a message that appears
acceptable under the filter's interpretation but that should be acceptable under the filter's interpretation but that should be
rejected under the interpretation given to it by that MUA. Such rejected under the interpretation given to it by that MUA. Such
skipping to change at page 21, line 41 skipping to change at page 20, line 44
dependent on digital signatures or similar integrity protection for dependent on digital signatures or similar integrity protection for
email message headers (see also the discussion in Section 11.3). email message headers (see also the discussion in Section 11.3).
Many conventional uses of PGP and S/MIME are not affected since they Many conventional uses of PGP and S/MIME are not affected since they
are used to sign body parts but not message headers. On the other are used to sign body parts but not message headers. On the other
hand, the developing work on domain keys identified mail (DKIM) hand, the developing work on domain keys identified mail (DKIM)
[RFC5863] will eventually need to consider this work and vice versa: [RFC5863] will eventually need to consider this work and vice versa:
while this specification does not address or solve the issues raised while this specification does not address or solve the issues raised
by DKIM and other signed header mechanisms, the issues will have to by DKIM and other signed header mechanisms, the issues will have to
be coordinated and resolved eventually if the two sets of protocols be coordinated and resolved eventually if the two sets of protocols
are to co-exist. In addition, to the degree to which email addresses are to co-exist. In addition, to the degree to which email addresses
appear in PKI (Public Key Infrastructure) certificates, standards appear in PKI (Public Key Infrastructure) certificates [RFC5280],
addressing such certificates will need to be upgraded to address standards addressing such certificates will need to be upgraded to
these internationalized addresses. Those upgrades will need to address these internationalized addresses. Those upgrades will need
address questions of spoofing by look-alikes of the addresses to address questions of spoofing by look-alikes of the addresses
themselves. themselves.
15. Acknowledgments 15. Acknowledgments
This document is an update to, and derived from, RFC 4952. This This document is an update to, and derived from, RFC 4952. This
document would have been impossible without the work and document would have been impossible without the work and
contributions acknowledged in it. The present document benefited contributions acknowledged in it. The present document benefited
significantly from discussions in the EAI WG and elsewhere after RFC significantly from discussions in the EAI WG and elsewhere after RFC
4952 was published, especially discussions about the experimental 4952 was published, especially discussions about the experimental
versions of other documents in the internationalized email versions of other documents in the internationalized email
skipping to change at page 24, line 22 skipping to change at page 23, line 27
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,
May 1996. May 1996.
[RFC2033] Myers, J., "Local Mail Transfer Protocol",
RFC 2033, October 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose [RFC2045] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part One: Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies", Format of Internet Message Bodies",
RFC 2045, November 1996. RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose [RFC2046] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part Two: Internet Mail Extensions (MIME) Part Two:
Media Types", RFC 2046, November 1996. Media Types", RFC 2046, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet [RFC2047] Moore, K., "MIME (Multipurpose Internet
skipping to change at page 30, line 17 skipping to change at page 29, line 17
A.8. Changes between -07 and -08 (after IETF Last Call) A.8. Changes between -07 and -08 (after IETF Last Call)
o Modified Section 7.2 to make the last paragraph less tentative and o Modified Section 7.2 to make the last paragraph less tentative and
more clear. more clear.
o Modified Section 8.1 to add an introductory paragraph that o Modified Section 8.1 to add an introductory paragraph that
clarifies what the IETF does and does not specify about email clarifies what the IETF does and does not specify about email
protocols. protocols.
A.9. Changes between -08 and -09
This version incorporates responses to a last set of public comments
and changes made in response to IESG discussion and comments as part
of the balloting process.
o Many small editorial changes made at IESG request.
o Several other small editorial corrections, removal of uncited
reference to LMTP, added a few citations for clarity.
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
 End of changes. 23 change blocks. 
103 lines changed or deleted 115 lines changed or added

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