draft-ietf-eai-frmwrk-4952bis-09.txt   draft-ietf-eai-frmwrk-4952bis-10.txt 
Email Address Internationalization J. Klensin Email Address Internationalization J. Klensin
(EAI) (EAI)
Internet-Draft Y. Ko Internet-Draft Y. Ko
Obsoletes: 4952, 5504, 5825 ICU Obsoletes: 4952, 5504, 5825 ICU
(if approved) September 23, 2010 (if approved) September 27, 2010
Intended status: Informational Intended status: Informational
Expires: March 27, 2011 Expires: March 31, 2011
Overview and Framework for Internationalized Email Overview and Framework for Internationalized Email
draft-ietf-eai-frmwrk-4952bis-09 draft-ietf-eai-frmwrk-4952bis-10
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 27, 2011. This Internet-Draft will expire on March 31, 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 11 skipping to change at page 3, line 11
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 . . . . 15
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 . . . . . 17
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 . . . . . . . . . . . . 18
12. Key Changes From the Experimental Protocols and Framework . . 18 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 . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . 28
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) . . . . 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
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 13, line 40 skipping to change at page 13, line 40
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 this section is
provided as general guidance rather than normative requirements. provided as general guidance rather than normative requirements.
It is likely that the most common cases in which a message that Messages that requires these extensions will sometimes be transferred
requires these extensions is sent to a system that does not will to a system that does not support these extensions; it is likely that
involve the combination of ASCII-only forward-pointing addresses with the most common cases will involve the combination of ASCII-only
a non-ASCII backward-pointing one. Until the extensions described forward-pointing addresses with a non-ASCII backward-pointing one.
here have been universally implemented in the Internet email Until the extensions described here have been universally implemented
environment, senders who prefer to use non-ASCII addresses (or raw in the Internet email environment, senders who prefer to use non-
UTF-8 characters in header fields) even when their intended ASCII addresses (or raw UTF-8 characters in header fields) even when
recipients use and expect all-ASCII ones will need to be especially their intended recipients use and expect all-ASCII ones will need to
careful about the error conditions that can arise, especially if they be especially careful about the error conditions that can arise,
are working in an environment in which non-delivery messages (or especially if they are working in an environment in which non-
other indications from submission servers) are routinely dropped or delivery messages (or other indications from submission servers) are
ignored. routinely dropped or ignored.
Perhaps obviously, the most convenient time to find an ASCII address Perhaps obviously, the most convenient time to find an ASCII address
corresponding to an internationalized address is at the originating corresponding to an internationalized address is at the originating
MUA or closely-associated systems. This can occur either before the MUA or closely-associated systems. This can occur either before the
message is sent or after the internationalized form of the message is message is sent or after the internationalized form of the message is
rejected. It is also the most convenient time to convert a message rejected. It is also the most convenient time to convert a message
from the internationalized form into conventional ASCII form or to from the internationalized form into conventional ASCII form or to
generate a non-delivery message to the sender if either is necessary. generate a non-delivery message to the sender if either is necessary.
At that point, the user has a full range of choices available, At that point, the user has a full range of choices available,
including changing backward-pointing addresses, contacting the including changing backward-pointing addresses, contacting the
skipping to change at page 15, line 49 skipping to change at page 15, line 49
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. These quoting of embedded characters in mailbox local parts. These
formations are permitted by the protocols and servers are expected to deliberately-unusual constructions are permitted by the protocols and
support them. Although they can provide value in special cases, servers are expected to support them. Although they can provide
taking advantage of them is almost always bad practice unless the value in special cases, taking advantage of them is almost always bad
intent is to create some form of security by obscurity. practice unless the 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
skipping to change at page 16, line 31 skipping to change at page 16, line 32
For the particular case of mailbox names that contain non-ASCII For the particular case of mailbox names that contain non-ASCII
characters in the local part, domain part, or both, special attention characters in the local part, domain part, or both, special attention
MUST be paid to Unicode normalization [Unicode-UAX15], in part MUST be paid to Unicode normalization [Unicode-UAX15], in part
because Unicode strings may be normalized by other processes because Unicode strings may be normalized by other processes
independent of what a mail protocol specifies (this is exactly independent of what a mail protocol specifies (this is exactly
analogous to what may happen with quoting and dequoting in analogous to what may happen with quoting and dequoting in
traditional addresses). Consequently, the following principles are traditional addresses). Consequently, the following principles are
offered as advice to those who are selecting names for mailboxes: 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 at least Normalization Form NFC. Except in circumstances in
circumstances, NFKC. which NFKC would map characters together that the parties
responsible for the destination mail server would prefer to be
kept distinguishable, supporting the NFKC-conformant form would
yield even more predictable behavior for the typical user.
o It may be wise to support other forms of the same local-part o It will usually be wise to support other forms of the same local-
string, either as aliases or by normalization of strings reaching part string, either as aliases or by normalization of strings
the delivery server, in the event that the sender does not send reaching the delivery server: the sender should not be depended
the strings in normalized form. upon to send the strings in normalized form.
o Stated differently and in more specific terms, the rules of the o Stated differently and in more specific terms, the rules of the
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. that they may not work reliably on a global basis. Servers
should not depend on clients to send normalized forms but
should be aware that procedures on client machines outside the
control of the MUA may cause normalized strings to be sent
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 [Unicode52]) are prohibited, the first in RFC 5321 and the
second by an obvious extension from it [RFC5198]. second 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, but creating dependencies on them in mailbox names handle them without severe errors (even if such strings are not
that are chosen is usually a bad practice and may lead to accepted in addresses to be delivered on that server), but
interoperability problems. creating dependencies on them in mailbox names that are chosen
is usually a bad practice and may lead to interoperability
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
skipping to change at page 18, line 50 skipping to change at page 19, line 12
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, which included the specifications supported in-transit downgrading. That mechanisms
definition of syntax and functions to support passing alternate, all- included the definition of syntax and functions to support passing
ASCII, addresses with the non-ASCII ones as well as special headers alternate, all-ASCII, addresses with the non-ASCII ones as well as
to indicate the downgraded status of messages. Those features were special headers to indicate the downgraded status of messages. Those
eliminated after experimentation indicated that they were more features were eliminated after experimentation indicated that they
complex and less necessary than had been assumed earlier. Those were more complex and less necessary than had been assumed earlier.
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
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 16 skipping to change at page 21, line 22
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
collection, and from RFC errata on RFC 4952 itself. collection, and from RFC errata on RFC 4952 itself.
Special thanks are due to Ernie Dainow for careful reviews and Special thanks are due to Ernie Dainow for careful reviews and
suggested text in this version. suggested text in this version and to several IESG members for a
careful review and specific suggestions.
16. References 16. References
16.1. Normative References 16.1. Normative References
[ASCII] American National Standards Institute [ASCII] American National Standards Institute
(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.
skipping to change at page 29, line 28 skipping to change at page 29, line 38
This version incorporates responses to a last set of public comments This version incorporates responses to a last set of public comments
and changes made in response to IESG discussion and comments as part and changes made in response to IESG discussion and comments as part
of the balloting process. of the balloting process.
o Many small editorial changes made at IESG request. o Many small editorial changes made at IESG request.
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
This version contains additional small editorial changes resulting
from IESG comments and review of -09 changes. Some more significant
clarifications appear in Section 10.1
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. 17 change blocks. 
42 lines changed or deleted 60 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/