draft-ietf-eai-rfc5335bis-03.txt   draft-ietf-eai-rfc5335bis-04.txt 
Email Address Internationalization A. Yang Email Address Internationalization A. Yang
(EAI) TWNIC (EAI) TWNIC
Internet-Draft S. Steele Internet-Draft S. Steele
Obsoletes: 5335 (if approved) Microsoft Obsoletes: 5335 (if approved) Microsoft
Updates: 2045,5321,5322 October 22, 2010 Updates: 2045,5321,5322 December 03, 2010
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: April 25, 2011 Expires: June 6, 2011
Internationalized Email Headers Internationalized Email Headers
draft-ietf-eai-rfc5335bis-03 draft-ietf-eai-rfc5335bis-04
Abstract Abstract
Full internationalization of electronic mail requires not only the Full internationalization of electronic mail requires not only the
capabilities to transmit non-ASCII content, to encode selected capabilities to transmit non-ASCII content, to encode selected
information in specific header fields, and to use non-ASCII information in specific header fields, and to use non-ASCII
characters in envelope addresses. It also requires being able to characters in envelope addresses. It also requires being able to
express those addresses and the information based on them in mail express those addresses and the information based on them in mail
header fields. This document specifies a variant of Internet mail header fields. This document specifies a variant of Internet mail
that permits the use of Unicode encoded in UTF-8, rather than ASCII, that permits the use of Unicode encoded in UTF-8, rather than ASCII,
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 April 25, 2011. This Internet-Draft will expire on June 6, 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 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Role of This Specification . . . . . . . . . . . . . . . . 3 1.1. Role of This Specification . . . . . . . . . . . . . . . . 3
1.2. Relation to Other Standards . . . . . . . . . . . . . . . 3 1.2. Relation to Other Standards . . . . . . . . . . . . . . . 3
2. Background and History . . . . . . . . . . . . . . . . . . . . 3 2. Background and History . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Changes on Message Header Fields . . . . . . . . . . . . . . . 5 4. Changes on Message Header Fields . . . . . . . . . . . . . . . 5
4.1. UTF-8 Syntax and Normalization . . . . . . . . . . . . . . 5 4.1. UTF-8 Syntax and Normalization . . . . . . . . . . . . . . 5
4.2. Changes on MIME Headers . . . . . . . . . . . . . . . . . 6 4.2. Changes on MIME Headers . . . . . . . . . . . . . . . . . 5
4.3. Syntax Extensions to RFC 5322 . . . . . . . . . . . . . . 6 4.3. Syntax Extensions to RFC 5322 . . . . . . . . . . . . . . 6
4.4. Change on addr-spec Syntax . . . . . . . . . . . . . . . . 8 4.4. Change on addr-spec Syntax . . . . . . . . . . . . . . . . 8
4.5. Trace Field Syntax . . . . . . . . . . . . . . . . . . . . 9 4.5. Trace Field Syntax . . . . . . . . . . . . . . . . . . . . 9
4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9 4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Edit history . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. draft-ietf-eai-rfc5335bis-00 . . . . . . . . . . . . . . . 12 8.1. draft-ietf-eai-rfc5335bis-00 . . . . . . . . . . . . . . . 12
8.2. draft-ietf-eai-rfc5335bis-01 . . . . . . . . . . . . . . . 12 8.2. draft-ietf-eai-rfc5335bis-01 . . . . . . . . . . . . . . . 13
8.3. draft-ietf-eai-rfc5335bis-02 . . . . . . . . . . . . . . . 13 8.3. draft-ietf-eai-rfc5335bis-02 . . . . . . . . . . . . . . . 13
8.4. draft-ietf-eai-rfc5335bis-03 . . . . . . . . . . . . . . . 13 8.4. draft-ietf-eai-rfc5335bis-03 . . . . . . . . . . . . . . . 13
8.5. draft-ietf-eai-rfc5335bis-04 . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
1.1. Role of This Specification 1.1. Role of This Specification
Full internationalization of electronic mail requires several Full internationalization of electronic mail requires several
capabilities: capabilities:
skipping to change at page 3, line 34 skipping to change at page 3, line 34
use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the use of Unicode encoded in UTF-8 [RFC3629], rather than ASCII, as the
base form for Internet email header fields. This form is permitted base form for Internet email header fields. This form is permitted
in transmission, if authorized by the SMTP extension specified in in transmission, if authorized by the SMTP extension specified in
[I-D.ietf-eai-rfc5336bis] or by other transport mechanisms capable of [I-D.ietf-eai-rfc5336bis] or by other transport mechanisms capable of
processing it. processing it.
1.2. Relation to Other Standards 1.2. Relation to Other Standards
This document updates Section 6.4 of [RFC2045]. It removes the This document updates Section 6.4 of [RFC2045]. It removes the
blanket ban on applying a content-transfer-encoding to all subtypes blanket ban on applying a content-transfer-encoding to all subtypes
of message/, and instead specifies that a composite subtype MAY of message/ and instead specifies that a composite subtype MAY
specify whether or not a content-transfer-encoding can be used for specify whether or not a content-transfer-encoding can be used for
that subtype, with "cannot be used" as the default. that subtype, with "cannot be used" as the default.
This document also updates [RFC5322] and MIME ([RFC2045]). This document also updates Section 3.4 of [RFC5322]. It Extended
mailbox address syntax to permit UTF-8 character in Section 4.3.
Allowing use of a content-transfer-encoding on subtypes of messages Allowing use of a content-transfer-encoding on subtypes of messages
is not limited to transmissions that are authorized by the SMTP is not limited to transmissions that are authorized by the SMTP
extension specified in [I-D.ietf-eai-rfc5336bis]. message/global (see extension specified in [I-D.ietf-eai-rfc5336bis]. message/global (see
Section 4.6) permits use of a content-transfer-encoding. Section 4.6) permits use of a content-transfer-encoding.
2. Background and History 2. Background and History
Mailbox names often represent the names of human users. Many of Mailbox names often represent the names of human users. Many of
these users throughout the world have names that are not normally these users throughout the world have names that are not normally
expressed with just the ASCII repertoire of characters, and would expressed with just the ASCII repertoire of characters, and would
like to use more or less their real names in their mailbox names. like to use more or less their real names in their mailbox names.
These users are also likely to use non-ASCII text in their common These users are also likely to use non-ASCII text in their display
names and subjects of email messages, both received and sent. This names and subjects of email messages, both received and sent. This
protocol specifies UTF-8 as the encoding to represent email header protocol specifies UTF-8 as the encoding to represent email header
field bodies. field bodies.
The traditional format of email messages [RFC5322] allows only ASCII The traditional format of email messages [RFC5322] allows only ASCII
characters in the header fields of messages. This prevents users characters in the header fields of messages. This prevents users
from having email addresses that contain non-ASCII characters. It from having email addresses that contain non-ASCII characters. It
further forces non-ASCII text in common names, comments, and in free further forces non-ASCII text in display names, comments, and in free
text (such as in the "Subject:" field) to be encoded (as required by text (such as in the "Subject:" field) to be encoded (as required by
MIME format [RFC2047]). This specification describes a change to the MIME format [RFC2047]). This specification describes a change to the
email message format that is related to the SMTP message transport email message format that is related to the SMTP message transport
change described in the associated documents change described in the associated documents
[I-D.ietf-eai-frmwrk-4952bis] and [I-D.ietf-eai-rfc5336bis], and that [I-D.ietf-eai-frmwrk-4952bis] and [I-D.ietf-eai-rfc5336bis], and that
allows non-ASCII characters in most email header fields. These allows non-ASCII characters in most email header fields. These
changes affect SMTP clients, SMTP servers, mail user agents (MUAs), changes affect SMTP clients, SMTP servers, mail user agents (MUAs),
list expanders, gateways to other media, and all other processes that list expanders, gateways to other media, and all other processes that
parse or handle email messages. parse or handle email messages.
As specified in [I-D.ietf-eai-rfc5336bis], an SMTP protocol extension As specified in [I-D.ietf-eai-rfc5336bis], an SMTP protocol extension
"UTF8SMTPbis" is used to prevent the transmission of messages with "UTF8SMTPbis" is used to prevent the transmission of messages with
UTF-8 header fields to systems that cannot handle such messages. UTF-8 header fields to systems that cannot handle such messages.
[[Note in Draft: Keyword related to UTF8SMTP will be decided by WG
before publication.]]
Use of this SMTP extension helps prevent the introduction of such Use of this SMTP extension helps prevent the introduction of such
messages into message stores that might misinterpret, improperly messages into message stores that might misinterpret, improperly
display, or mangle such messages. It should be noted that using an display, or mangle such messages. It should be noted that using an
ESMTP extension does not prevent transferring email messages with ESMTP extension does not prevent transferring email messages with
UTF-8 header fields to other systems that use the email format for UTF-8 header fields to other systems that use the email format for
messages and that may not be upgraded, such as unextended POP and messages and that may not be upgraded, such as unextended POP and
IMAP servers. Changes to these protocols to handle UTF-8 header IMAP servers. Changes to these protocols to handle UTF-8 header
fields are addressed in [RFC5721bis] and [RFC5738bis]. [[Note in fields are addressed in [I-D.ietf-eai-rfc5721bis] and
Draft: RFC5721bis and RFC5738bis did not yet posted.]] [I-D.ietf-eai-5378bis].
The objective for this protocol is to allow UTF-8 in email header The objective for this protocol is to allow UTF-8 in email header
fields. fields.
3. Terminology 3. Terminology
A plain ASCII string is also a valid UTF-8 string; see [RFC3629]. In A plain ASCII string is full compatible with [RFC5321] and [RFC5322].
this document, ordinary ASCII characters are UTF-8 characters if they In this document, non-ASCII strings are UTF-8 strings if they are in
are in headers which contain <utf8-xtra-char>s. header which contain at least one <UTF8-non-ascii>.
Unless otherwise noted, all terms used here are defined in [RFC5321], Unless otherwise noted, all terms used here are defined in [RFC5321],
[RFC5322], [I-D.ietf-eai-frmwrk-4952bis], or [RFC5322], [I-D.ietf-eai-frmwrk-4952bis], or
[I-D.ietf-eai-rfc5336bis]. [I-D.ietf-eai-rfc5336bis].
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
4. Changes on Message Header Fields 4. Changes on Message Header Fields
skipping to change at page 5, line 29 skipping to change at page 5, line 28
is defined to substitute those definitions in [RFC5322]. is defined to substitute those definitions in [RFC5322].
The syntax rules not covered in this section remain as defined in The syntax rules not covered in this section remain as defined in
[RFC5322]. [RFC5322].
4.1. UTF-8 Syntax and Normalization 4.1. UTF-8 Syntax and Normalization
UTF-8 characters can be defined in terms of octets using the UTF-8 characters can be defined in terms of octets using the
following ABNF [RFC5234], taken from [RFC3629]: following ABNF [RFC5234], taken from [RFC3629]:
UTF8-xtra-char= UTF8-2 / UTF8-3 / UTF8-4 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = %xC2-DF UTF8-tail
UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2(UTF8-tail) /
%xED %x80-9F UTF8-tail / %xEE-EF 2(UTF8-tail)
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) / UTF8-2 = <See Section 4 of RFC3629>
%xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BF UTF8-3 = <See Section 4 of RFC3629>
These are normatively defined in [RFC3629], but kept in this document UTF8-4 = <See Section 4 of RFC3629>
for reasons of convenience.
See [RFC5198] for a discussion of normalization; the use of See [RFC5198] for a discussion of normalization; the use of
normalization form NFC is RECOMMENDED. Actually, if one is going to normalization form [NFC] is RECOMMENDED. Actually, if one is going
do internationalization properly, one of the most often-cited goals to do internationalization properly, one of the most often-cited
is to permit people to spell their names correctly. Since many goals is to permit people to spell their names correctly. Since many
mailbox local parts reflect personal names, that principle applies as mailbox local parts reflect personal names, that principle applies as
well. And NFKC is not recommended because it may lose information well. And NFKC is not recommended because it may lose information
that is needed to correctly spell some names except in unusual that is needed to correctly spell some names in unusual
circumstances. circumstances.
4.2. Changes on MIME Headers 4.2. Changes on MIME Headers
This specification updates Section 6.4 of [RFC2045]. [RFC2045] This specification updates Section 6.4 of [RFC2045]. [RFC2045]
prohibits applying a content-transfer-encoding to all subtypes of prohibits applying a content-transfer-encoding to any subtypes of
message/. This specification relaxes the rule -- it allows newly "message/". This specification relaxes the rule -- it allows newly
defined MIME types to permit content-transfer-encoding, and it allows defined MIME types to permit content-transfer-encoding, and it allows
content-transfer-encoding for message/global (see Section 4.6). content-transfer-encoding for message/global (see Section 4.6).
Background: Normally, transfer of message/global will be done in Background: Normally, transfer of message/global will be done in
8-bit-clean channels, and body parts will have "identity" encodings, 8-bit-clean channels, and body parts will have "identity" encodings,
that is, no decoding is necessary. In the case where a message that is, no decoding is necessary. In the case where a message
containing a message/global is downgraded from 8-bit to 7-bit as containing a message/global is downgraded from 8-bit to 7-bit as
described in [RFC1652], an encoding may be applied to the message; if described in [RFC1652], an encoding may be applied to the message; if
the message travels multiple times between a 7-bit environment and an the message travels multiple times between a 7-bit environment and an
environment implementing UTF8SMTPbis, multiple levels of encoding may environment implementing UTF8SMTPbis, multiple levels of encoding may
skipping to change at page 6, line 34 skipping to change at page 6, line 26
4.3. Syntax Extensions to RFC 5322 4.3. Syntax Extensions to RFC 5322
The following rules are intended to extend the corresponding rules in The following rules are intended to extend the corresponding rules in
[RFC5322] in order to allow UTF-8 characters. [RFC5322] in order to allow UTF-8 characters.
FWS = <see [RFC5322] Section 3.2.2, folding white space> FWS = <see [RFC5322] Section 3.2.2, folding white space>
CFWS = <see [RFC5322] Section 3.2.2> CFWS = <see [RFC5322] Section 3.2.2>
ctext =/ UTF8-xtra-char ctext =/ UTF8-non-ascii
utext =/ UTF8-xtra-char
comment = "(" *([FWS] uCcontent) [FWS] ")" comment = "(" *([FWS] uCcontent) [FWS] ")"
word = uAtom / uQuoted-String word = uAtom / uQuoted-String
This means that all the [RFC5322] constructs that build upon these This means that all the [RFC5322] constructs that build upon these
will permit UTF-8 characters, including comments and quoted strings. will permit UTF-8 characters, including comments and quoted strings.
We do not change the syntax of <atext> in order to allow UTF-8 We do not change the syntax of <atext> in order to allow UTF-8
characters in <addr-spec>. This would also allow UTF-8 characters in characters in <addr-spec>. This would also allow UTF-8 characters in
<message-id>, which is not allowed due to the limitation described in <message-id>, which is not allowed due to the limitation described in
Section 4.5. Instead, <uAtext> is added to meet this requirement. Section 4.5. Instead, <uAtext> is added to meet this requirement.
uText = %d1-9 / ; all UTF-8 characters except uText = %d1-9 / ; all UTF-8 characters except
%d11-12 / ; US-ASCII NUL, CR, and LF %d11-12 / ; US-ASCII NUL, CR, and LF
%d14-127 / %d14-127 /
UTF8-xtra-char UTF8-non-ascii
uQuoted-Pair = ("\" uText) / obs-qp uQuoted-Pair = ("\" (VCHAR / WSP / UTF8-non-ascii )) / obs-qp
uQcontent = uQtext / uQuoted-Pair VCHAR = <See appendix B.1 of RFC 5234>
uQuoted-String = [CFWS] DQUOTE *([FWS] uQcontent) [FWS] DQUOTE [CFWS] WSP = <See appendix B.1 of RFC 5234>
uQcontent = uQtext / uQuoted-Pair
uQuoted-Pair = ("\" uText) / obs-qp
DQUOTE = <See appendix B.1 of RFC 5234> DQUOTE = <See appendix B.1 of RFC 5234>
uCcontent = ctext / uQuoted-Pair / comment uCcontent = ctext / uQuoted-Pair / comment
uQtext = qtext / UTF8-xtra-char uQtext = qtext / UTF8-non-ascii
uAtext = ALPHA / DIGIT / uAtext = ALPHA / DIGIT /
"!" / "#" / ; Any character except "!" / "#" / ; Any character except
"$" / "%" / ; controls, SP, and specials. "$" / "%" / ; controls, SP, and specials.
"&" / "'" / ; Used for atoms. "&" / "'" / ; Used for atoms.
"*" / "+" / "*" / "+" /
"-" / "/" / "-" / "/" /
"=" / "?" / "=" / "?" /
"^" / "_" / "^" / "_" /
"`" / "{" / "`" / "{" /
"|" / "}" / "|" / "}" /
"~" / "~" /
UTF8-xtra-char UTF8-non-ascii
uAtom = FWS] 1*uAtext [CFWS] uAtom = [CFWS] 1*uAtext [CFWS]
uDot-Atom = CFWS] uDot-Atom-text [CFWS] uDot-Atom = [CFWS] uDot-Atom-text [CFWS]
uDot-Atom-text = 1*uAtext *("." 1*uAtext) uDot-Atom-text = 1*uAtext *("." 1*uAtext)
qcontent = uQcontent qcontent =/ uQcontent
To allow the use of UTF-8 in a Content-Description header field To allow the use of UTF-8 in a Content-Description header field
[RFC2045], the following syntax is used: [RFC2045], the following syntax is used:
description = "Content-Description:" unstructured CRLF description = "Content-Description" ":" *uText
; Replace description in Section 8 of [RFC2045]
The <utext> syntax is extended above to allow UTF-8 in all The <uText> syntax is extended above to allow UTF-8 in all
<unstructured> header fields. <description> header fields.
Note, however, this does not remove any constraint on the character Note, however, this does not remove any constraint on the character
set of protocol elements; for instance, all the allowed values for set of protocol elements; for instance, all the allowed values for
timezone in the "Date:" headers are still expressed in ASCII. And timezone in the "Date:" header fields are still expressed in ASCII.
also, none of this revised syntax changes what is allowed in a And also, none of this revised syntax changes what is allowed in a
<message-id>, which will still remain in pure ASCII. <msg-id>, which will still remain in pure ASCII.
4.4. Change on addr-spec Syntax 4.4. Change on addr-spec Syntax
Internationalized email addresses are represented in UTF-8. Thus, Internationalized email addresses are represented in UTF-8. Thus,
all header fields containing <mailbox>es are updated from [RFC5321] all header fields containing <mailbox>es are updated from [RFC5321]
Section 4.1.2 to permit UTF-8 addresses. Section 4.1.2 to permit UTF-8 addresses.
mailbox = name-addr / addr-spec / uAddr-Spec mailbox = name-addr / addr-spec / uAddr-Spec
; Replace mailbox in Section 3.4.1 of RFC 5322 ; Replace mailbox in Section 3.4 of RFC 5322
angle-addr =/ [CFWS] "<" uAddr-Spec">" [CFWS] / obs-angle-addr
; Replace angle-addr in Section 3.4 of RFC 5322
uAddr-Spec = uLocal-Part "@" uDomain angle-addr =/ [CFWS] "<" uAddr-Spec ">" [CFWS]
; Replace angle-addr in Section 3.4 of RFC 5322
uLocal-Part = uDot-String / uQuoted-String uAddr-Spec = uLocal-Part "@" ( uDomain / address-literal )
; Replace Local-Part in Section 3.4.1 of RFC 5322
uDot-string = uAtom *("." uAtom) address-literal = <See Section 4.1.2 of RFC 5321>
uDomain = (sub-udomain 1*("." sub-uDomain)) / uLocal-Part = uDot-String / uQuoted-String / obs-Local-Part
dot-atom / domain-literal / obs-domain ; Replace Local-Part in Section 4.1.2 of RFC 5321
; Replace Domain in Section 4.1.2 of RFC 5321
sub-udomain = uLet-dig [uLdh-str] uDot-string = uAtom *("." uAtom)
; Replace sub-domain in Section 4.1.2 of RFC 5321 ; Replace Dot-string in RFC 5321, Section 4.1.2
uLet-dig = Let-dig / UTF8-xtra-char uDomain = (sub-udomain 1*("." sub-uDomain)) /
; Replace uLet-dig in Section 4.1.2 of RFC 5321 dot-atom / domain-literal / obs-domain
; Replace Domain in Section 4.1.2 of RFC 5321
Let-dig = <See Section 4.1.3 of RFC 5321> sub-udomain = uLet-dig [uLdh-str]
; Replace sub-domain in Section 4.1.2 of RFC 5321
uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-xtra-char) uLet-dig uLet-dig = Let-dig / UTF8-non-ascii
; Replace Ldh-str Section 4.1.2 of RFC 5321 ; Replace uLet-dig in Section 4.1.2 of RFC 5321
Let-dig = <See Section 4.1.2 of RFC 5321>
uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig
; Replace Ldh-str Section 4.1.2 of RFC 5321
Below are a few examples of possible <mailbox> representations. Below are a few examples of possible <mailbox> representations.
"DISPLAY_NAME" <ASCII@ASCII> "DISPLAY_NAME" <ASCII@ASCII>
; traditional mailbox format ; traditional mailbox format
"DISPLAY_NAME" <non-ASCII@non-ASCII>
; message will bounce if UTF8SMTPbis extension is not supported "DISPLAY_NAME" <non-ASCII@non-ASCII>
<non-ASCII@non-ASCII> ; message will be rejected if UTF8SMTPbis extension is not supported
; without DISPLAY_NAME and quoted string
; message will bounce if UTF8SMTPbis extension is not supported <non-ASCII@non-ASCII>
; without DISPLAY_NAME and quoted string
; message will be rejected if UTF8SMTPbis extension is not supported
4.5. Trace Field Syntax 4.5. Trace Field Syntax
The uFor ( described in [I-D.ietf-eai-rfc5336bis] Section 3.6.3 )) The 'uFor' clause in "Received:" fields has been allowed the use of
has been added to allow the use of internationalized addresses in internationalized addresses in "For" fields. It described in
"For" fields. by use of the new uFor syntax. UTF-8 information may [I-D.ietf-eai-rfc5336bis], Section 3.6.3.
be needed in "Received:" fields. Such information is therefore
allowed to preserve the integrity of those fields. The uFor syntax
retains the original UTF-8 email address between email address
internationalization EAI-aware MTAs.
The "Return-path" designates the address to which messages indicating The "Return-path" designates the address to which messages indicating
non-delivery or other mail system failures are to be sent. Thus, the non-delivery or other mail system failures are to be sent. Thus, the
header is augmented to carry UTF-8 addresses (see the revised syntax header is augmented to carry UTF-8 addresses (see the revised syntax
of <angle-addr> in Section 4.4 of this document). This will not of <angle-addr> in Section 4.4 of this document). This will not
break the rule of trace field integrity, because the header field is break the rule of trace field integrity, because the header field is
added at the last MTA and described in [RFC5321]. added at the last MTA and described in [RFC5321].
The <item-value> on "Received:" field syntax is augmented to allow The <received-token> on "Received:" field ( described in Section
UTF-8 email address in the "For" field. <angle-addr> is augmented to 3.6.7 of [RFC5322]) syntax is augmented to allow UTF-8 email address
include UTF-8 email address. In order to allow UTF-8 email addresses in the "For" field. <angle-addr> is augmented to include UTF-8 email
in an <addr-spec>, <uAddr-Spec> is added to <item-value>. address. In order to allow UTF-8 email addresses in an <addr-spec>,
<uAddr-Spec> is added to <received-token>.
item-value =/ uAddr-Spec received-token =/ uAddr-Spec
4.6. message/global 4.6. message/global
Internationalized messages MUST only be transmitted as authorized by Internationalized messages MUST only be transmitted as authorized by
[I-D.ietf-eai-rfc5336bis] or within a non-SMTP environment which [I-D.ietf-eai-rfc5336bis] or within a non-SMTP environment which
supports these messages. A message is a "message/global message", if supports these messages. A message is a "message/global message", if
o it contains UTF-8 header values as specified in this document, or o it contains UTF-8 header values as specified in this document, or
o it contains UTF-8 values in the headers fields of body parts. o it contains UTF-8 values in the headers fields of body parts.
The type message/global is similar to message/rfc822, except that it The type message/global is similar to message/rfc822, except that it
specifies that a message can contain UTF-8 characters in the headers specifies that a message can contain UTF-8 characters in the headers
of the message or body parts. If this type is sent to a 7-bit-only of the message or body parts. If this type is sent to a 7-bit-only
system, it has to be encoded in MIME [RFC2045]. (Note that a system system, it has to be encoded in MIME [RFC2045]. (Note that a system
compliant with MIME that doesn't recognize message/global MUST treat compliant with MIME that doesn't recognize message/global SHOULD
it as "application/octet-stream" as described in Section 5.2.4 of treat it as "application/octet-stream" as described in Section 5.2.4
[RFC2046].) of [RFC2046].)
Type name: message Type name: message
Subtype name: global Subtype name: global
Required parameters: none Required parameters: none
Optional parameters: none Optional parameters: none
Encoding considerations: Any content-transfer-encoding is permitted. Encoding considerations: Any content-transfer-encoding is permitted.
skipping to change at page 11, line 18 skipping to change at page 11, line 21
"public.message" and "public.composite-content", but does not "public.message" and "public.composite-content", but does not
necessarily conform to "public.utf8-plain-text". necessarily conform to "public.utf8-plain-text".
Person & email address to contact for further information: See the Person & email address to contact for further information: See the
Author's Address section of this document. Author's Address section of this document.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: This is a structured media type which embeds Restrictions on usage: This is a structured media type which embeds
other MIME media types. The 8-bit or binary content-transfer- other MIME media types. The 8-bit or binary content-transfer-
encoding MUST be used unless this media type is sent over a 7-bit- encoding SHOULD be used unless this media type is sent over a
only transport. 7-bit-only transport.
Author: See the Author's Address section of this document. Author: See the Author's Address section of this document.
Change controller: IETF Standards Process Change controller: IETF Standards Process
5. Security Considerations 5. Security Considerations
If a user has a non-ASCII mailbox address and an ASCII mailbox If a user has a non-ASCII mailbox address and an ASCII mailbox
address, a digital certificate that identifies that user may have address, a digital certificate that identifies that user may have
both addresses in the identity. Having multiple email addresses as both addresses in the identity. Having multiple email addresses as
identities in a single certificate is already supported in PKIX identities in a single certificate is already supported in PKIX
(Public Key Infrastructure for X.509 Certificates) and OpenPGP. (Public Key Infrastructure for X.509 Certificates) [RFC5280] and
OpenPGP [RFC3156].
Because UTF-8 often requires several octets to encode a single Because UTF-8 often requires several octets to encode a single
character, internationalized local parts may cause mail addresses to character, internationalized local parts and header value may cause
become longer. As specified in [RFC5322], each line of characters mail addresses to become longer. As specified in [RFC5322], each
MUST be no more 998 octets, excluding the CRLF. line of characters MUST be no more 998 octets, excluding the CRLF.
On the other hand, MDA (Mail Delivery Agent) processes that parse,
Because internationalized local parts may cause email addresses to be store, or handle email addresses or local parts must take extra care
longer, processes that parse, store, or handle email addresses or not to overflow buffers, truncate addresses, or exceed storage
local parts must take extra care not to overflow buffers, truncate allotments. Also, they must take care, when comparing, to use the
addresses, or exceed storage allotments. Also, they must take care, entire lengths of the addresses.
when comparing, to use the entire lengths of the addresses.
In this specification, a user could provide an ASCII alternative In this specification, a user could provide an ASCII alternative
address for a non-ASCII address. However, it is possible these two address for a non-ASCII address. However, it is possible these two
addresses go to different mailboxes, or even different people. This addresses go to different mailboxes, or even different people. This
configuration may be based on a user's personal choice or on configuration may be based on a user's personal choice or on
administration policy. We recognize that if ASCII and non-ASCII administration policy. We recognize that if ASCII and non-ASCII
email is delivered to two different destinations, based on MTA email is delivered to two different destinations, based on MTA
capability, this may violate the principle of least astonishment, but capability, this may violate the principle of least astonishment, but
this is not a "protocol problem". this is not a "protocol problem".
skipping to change at page 13, line 17 skipping to change at page 13, line 21
1. ABNF revised. 1. ABNF revised.
8.4. draft-ietf-eai-rfc5335bis-03 8.4. draft-ietf-eai-rfc5335bis-03
1. Fix typos 1. Fix typos
2. ABNF revised 2. ABNF revised
3. Improve sentence 3. Improve sentence
8.5. draft-ietf-eai-rfc5335bis-04
1. improve sentences and ABNF revised based on AD and Co-chairs
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-eai-5378bis] Resnick, P., Newman, C., and S. Shen,
"IMAP Support for UTF-8",
draft-ietf-eai-5378bis-00 (work in
progress), November 2010.
[I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and
Framework for Internationalized Framework for Internationalized
Email", Email",
draft-ietf-eai-frmwrk-4952bis-10 (work draft-ietf-eai-frmwrk-4952bis-10 (work
in progress), September 2010. in progress), September 2010.
[I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension [I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension
for Internationalized Email Address", for Internationalized Email Address",
draft-ietf-eai-rfc5336bis-04 (work in draft-ietf-eai-rfc5336bis-05 (work in
progress), October 2010. progress), December 2010.
[RFC1652] Klensin, J., Freed, N., Rose, M., [I-D.ietf-eai-rfc5721bis] Gellens, R., Newman, C., Yao, J., and
Stefferud, E., and D. Crocker, "SMTP K. Fujiwara, "POP3 Support for UTF-8",
Service Extension for 8bit- draft-ietf-eai-rfc5721bis-00 (work in
MIMEtransport", RFC 1652, July 1994. progress), September 2010.
[RFC2119] Bradner, S., "Key words for use in [RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement Levels", RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, March 1997. BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation [RFC3629] Yergeau, F., "UTF-8, a transformation
format of ISO 10646", STD 63, format of ISO 10646", STD 63,
RFC 3629, November 2003. RFC 3629, November 2003.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode [RFC5198] Klensin, J. and M. Padlipsky, "Unicode
skipping to change at page 14, line 13 skipping to change at page 14, line 25
STD 68, RFC 5234, January 2008. STD 68, RFC 5234, January 2008.
[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.
9.2. Informative References 9.2. Informative References
[NFC] Davis, M. and K. Whistler, "Unicode
Standard Annex #15: Unicode
Normalization Forms", September 2010,
<http://www.unicode.org/reports/
tr15/>.
[RFC1652] Klensin, J., Freed, N., Rose, M.,
Stefferud, E., and D. Crocker, "SMTP
Service Extension for 8bit-
MIMEtransport", RFC 1652, July 1994.
[RFC2045] Freed, N. and N. Borenstein, [RFC2045] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, Message Bodies", RFC 2045,
November 1996. November 1996.
[RFC2046] Freed, N. and N. Borenstein, [RFC2046] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", (MIME) Part Two: Media Types",
RFC 2046, November 1996. RFC 2046, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose [RFC2047] Moore, K., "MIME (Multipurpose
Internet Mail Extensions) Part Three: Internet Mail Extensions) Part Three:
Message Header Extensions for Non- Message Header Extensions for Non-
ASCII Text", RFC 2047, November 1996. ASCII Text", RFC 2047, November 1996.
[RFC3156] Elkins, M., Del Torto, D., Levien, R.,
and T. Roessler, "MIME Security with
OpenPGP", RFC 3156, August 2001.
[RFC5280] Cooper, D., Santesson, S., Farrell,
S., Boeyen, S., Housley, R., and W.
Polk, "Internet X.509 Public Key
Infrastructure Certificate and
Certificate Revocation List (CRL)
Profile", RFC 5280, May 2008.
Authors' Addresses Authors' Addresses
Abel Yang Abel Yang
TWNIC TWNIC
4F-2, No. 9, Sec 2, Roosevelt Rd. 4F-2, No. 9, Sec 2, Roosevelt Rd.
Taipei, 100 Taipei, 100
Taiwan Taiwan
Phone: +886 2 23411313 ext 505 Phone: +886 2 23411313 ext 505
EMail: abelyang@twnic.net.tw EMail: abelyang@twnic.net.tw
 End of changes. 57 change blocks. 
110 lines changed or deleted 140 lines changed or added

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