draft-ietf-eai-frmwrk-4952bis-07.txt   draft-ietf-eai-frmwrk-4952bis-08.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: RFCs 4952, 5504, 5825 ICU
(if approved) August 31, 2010 (if approved) September 17, 2010
Intended status: Informational Intended status: Informational
Expires: March 4, 2011 Expires: March 21, 2011
Overview and Framework for Internationalized Email Overview and Framework for Internationalized Email
draft-ietf-eai-frmwrk-4952bis-07 draft-ietf-eai-frmwrk-4952bis-08
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 4, 2011. This Internet-Draft will expire on March 21, 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 3, line 7
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Role of This Specification . . . . . . . . . . . . . . . . . . 4 2. Role of This Specification . . . . . . . . . . . . . . . . . . 5
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 6
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 6 4.1. Mail User and Mail Transfer Agents . . . . . . . . . . . . 7
4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 7 4.2. Address Character Sets . . . . . . . . . . . . . . . . . . 8
4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. User Types . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Conventional Message and Internationalized Message . . . . 8 4.6. Conventional Message and Internationalized Message . . . . 9
4.7. Undeliverable Messages, Notification, and Delivery 4.7. Undeliverable Messages, Notification, and Delivery
Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 8 Receipts . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Overview of the Approach and Document Plan . . . . . . . . . . 9 5. Overview of the Approach and Document Plan . . . . . . . . . . 10
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 . . . . . . . . . 11
7.1. SMTP Extension for Internationalized Email Address . . . . 10 7.1. SMTP Extension for Internationalized Email Address . . . . 11
7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 11 7.2. Transmission of Email Header Fields in UTF-8 Encoding . . 12
7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 12 7.3. SMTP Service Extension for DSNs . . . . . . . . . . . . . 13
8. Downgrading before and after SMTP Transactions . . . . . . . . 12 8. Downgrading before and after SMTP Transactions . . . . . . . . 13
8.1. Downgrading before or during Message Submission . . . . . 13 8.1. Downgrading before or during Message Submission . . . . . 14
8.2. Downgrading or Other Processing After Final SMTP 8.2. Downgrading or Other Processing After Final SMTP
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 14 Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 14 9. Downgrading in Transit . . . . . . . . . . . . . . . . . . . . 16
10. User Interface and Configuration Issues . . . . . . . . . . . 15 10. User Interface and Configuration Issues . . . . . . . . . . . 16
10.1. Choices of Mailbox Names and Unicode Normalization . . . . 15 10.1. Choices of Mailbox Names and Unicode Normalization . . . . 16
11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 16 11. Additional Issues . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 16 11.1. Impact on URIs and IRIs . . . . . . . . . . . . . . . . . 18
11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 17 11.2. Use of Email Addresses as Identifiers . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . 19
11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 18 11.5. Non-Standard Encapsulation Formats . . . . . . . . . . . . 19
12. Key Changes From the Experimental Protocols and Framework . . 18 12. Key Changes From the Experimental Protocols and Framework . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
14. Security Considerations . . . . . . . . . . . . . . . . . . . 19 14. Security Considerations . . . . . . . . . . . . . . . . . . . 20
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
16.1. Normative References . . . . . . . . . . . . . . . . . . . 21 16.1. Normative References . . . . . . . . . . . . . . . . . . . 22
16.2. Informative References . . . . . . . . . . . . . . . . . . 22 16.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27
A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 26 A.1. Changes between -00 and -01 . . . . . . . . . . . . . . . 27
A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 26 A.2. Changes between -01 and -02 . . . . . . . . . . . . . . . 27
A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 28 A.3. Changes between -02 and -03 . . . . . . . . . . . . . . . 29
A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 28 A.4. Changes between -03 and -04 . . . . . . . . . . . . . . . 29
A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 28 A.5. Changes between -04 and -05 . . . . . . . . . . . . . . . 29
A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 28 A.6. Changes between -05 and -06 . . . . . . . . . . . . . . . 29
A.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 28 A.7. Changes between -06 and -07 . . . . . . . . . . . . . . . 29
A.8. Changes between -07 and -08 (after IETF Last Call) . . . . 30
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 12, line 4 skipping to change at page 13, line 4
Similarly, if different codings are used for mail transport and Similarly, if different codings are used for mail transport and
message bodies, the user is particularly likely to be surprised, if message bodies, the user is particularly likely to be surprised, if
only as a consequence of the long-established "things leak" only as a consequence of the long-established "things leak"
principle. The only practical way to avoid these sources of principle. The only practical way to avoid these sources of
discomfort, in both the medium and the longer term, is to have the discomfort, in both the medium and the longer term, is to have the
encodings used in transport be as similar to the encodings used in encodings used in transport be as similar to the encodings used in
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 presumably use UTF-8 fully internationalized form. That form SHOULD use UTF-8 rather than
rather than ASCII as the base character set for the contents of ASCII as the base character set for the contents of header fields
header fields (protocol elements such as the header field names (protocol elements such as the header field names themselves are
themselves are unchanged and remain entirely in ASCII). For unchanged and remain entirely in ASCII). For transition purposes and
transition purposes and compatibility with legacy systems, this can compatibility with legacy systems, this can done by extending the
done by extending the traditional MIME encoding models for non-ASCII traditional MIME encoding models for non-ASCII characters in headers
characters in headers [RFC2045] [RFC2231]. However, the target is [RFC2045] [RFC2231], but even these should be based on UTF-8. rather
fully internationalized message headers, as discussed in than other encodings, if at all possible [IAB-idn-encoding].
[RFC5335bis-Hdrs] and not an extended and painful transition. However, the target is fully internationalized message headers, as
discussed in [RFC5335bis-Hdrs] and not an extended and painful
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 28 skipping to change at page 14, line 30
As discussed above, downgrading to an ASCII-only form may occur As discussed above, downgrading to an ASCII-only form may occur
before or during the initial message submission. It might also occur before or during the initial message submission. It might also occur
after the delivery to the final delivery MTA in order to accommodate after the delivery to the final delivery MTA in order to accommodate
messages stores or IMAP or POP servers or clients that have different messages stores or IMAP or POP servers or clients that have different
capabilities than the delivery MTA. These two cases are discussed in capabilities than the delivery MTA. These two cases are discussed in
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
MUAs to provide maximum flexibility in the associated user
interfaces. The SMTP standard [RFC5321], Section 6.4, gives wide
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"
standards once it is injected into the public Internet. In that
tradition, the discussion in the remainder of this section is
provided as general guidance rather than normative requirements.
It is likely that the most common cases in which a message that It is likely that the most common cases in which a message that
requires these extensions is sent to a system that does not will requires these extensions is sent to a system that does not will
involve the combination of ASCII-only forward-pointing addresses with involve the combination of ASCII-only forward-pointing addresses with
a non-ASCII backward-pointing one. Until the extensions described a non-ASCII backward-pointing one. Until the extensions described
here have been universally implemented in the Internet email here have been universally implemented in the Internet email
environment, senders who prefer to use non-ASCII addresses (or raw environment, senders who prefer to use non-ASCII addresses (or raw
UTF-8 characters in header fields) even when their intended UTF-8 characters in header fields) even when their intended
recipients use and expect all-ASCII ones will need to be especially recipients use and expect all-ASCII ones will need to be especially
careful about the error conditions that can arise, especially if they careful about the error conditions that can arise, especially if they
are working in an environment in which non-delivery messages (or are working in an environment in which non-delivery messages (or
skipping to change at page 16, line 4 skipping to change at page 17, line 16
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
The practice SHOULD be phased out as this extension becomes widely this character in ASCII mailbox names and it is even more problematic
deployed but backward-compatibility considerations may require that (for canonicalization and normalization reasons) in non-ASCII
it continue to be recognized. 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 EAI mailbox names, special attention MUST
be paid to Unicode normalization [Unicode-UAX15], in part because be paid to Unicode normalization [Unicode-UAX15], in part because
Unicode strings may be normalized by other processes independent of Unicode strings may be normalized by other processes independent of
what a mail protocol specifies (this is exactly analogous to what may what a mail protocol specifies (this is exactly analogous to what may
happen with quoting and dequoting in traditional addresses). happen with quoting and dequoting in traditional addresses).
Consequently, the following principles are offered as advice to those Consequently, the following principles are offered as advice to those
who are selecting names for mailboxes: 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,
skipping to change at page 29, line 5 skipping to change at page 30, line 8
requirements and closely-related issues.. requirements and closely-related issues..
A.7. Changes between -06 and -07 A.7. Changes between -06 and -07
o Added a new section (now Section 12) to explicitly discuss the o Added a new section (now Section 12) to explicitly discuss the
changes from the previous version. changes from the previous version.
o Removed the discussion of LMTP from Section 11; it is more o Removed the discussion of LMTP from Section 11; it is more
appropriately placed in the SMTP Extension document (5336bis). appropriately placed in the SMTP Extension document (5336bis).
A.8. Changes between -07 and -08 (after IETF Last Call)
o Modified Section 7.2 to make the last paragraph less tentative and
more clear.
o Modified Section 8.1 to add an introductory paragraph that
clarifies what the IETF does and does not specify about email
protocols.
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. 11 change blocks. 
61 lines changed or deleted 82 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/