draft-ietf-eai-rfc5335bis-01.txt   draft-ietf-eai-rfc5335bis-02.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, 5322 July 12, 2010 Updates: 2045, 5322 August 19, 2010
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 13, 2011 Expires: February 20, 2011
Internationalized Email Headers Internationalized Email Headers
draft-ietf-eai-rfc5335bis-01 draft-ietf-eai-rfc5335bis-02
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 an variant of Internet mail header fields. This document specifies an 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 January 13, 2011. This Internet-Draft will expire on February 20, 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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . 8 4.5. Trace Field Syntax . . . . . . . . . . . . . . . . . . . . 8
4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9 4.6. message/global . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
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.3. draft-ietf-eai-rfc5335bis-02 . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
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 6, line 39 skipping to change at page 6, line 39
[RFC5322] in order to allow UTF-8 characters. [RFC5322] in order to allow UTF-8 characters.
FWS = <see [RFC5322], folding white space> FWS = <see [RFC5322], folding white space>
CFWS = <see [RFC5322], folding white space> CFWS = <see [RFC5322], folding white space>
ctext =/ UTF8-xtra-char ctext =/ UTF8-xtra-char
utext =/ UTF8-xtra-char utext =/ UTF8-xtra-char
comment = "(" *([FWS] utf8-ccontent) [FWS] ")" comment = "(" *([FWS] uCcontent) [FWS] ")"
word = utf8-atom / utf8-quoted-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, <utf8-atext> is added to meet this Section 4.5. Instead, <uAtext> is added to meet this requirement.
requirement.
utf8-text = %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-xtra-char
utf8-quoted-pair = ("\" utf8-text) / obs-qp uQuoted-Pair = ("\" uText) / obs-qp
utf8-qcontent = utf8-qtext / utf8-quoted-pair uQcontent = uQtext / uQuoted-Pair
utf8-quoted-string = [CFWS] uQuoted-String = [CFWS]
DQUOTE *([FWS] utf8-qcontent) [FWS] DQUOTE DQUOTE *([FWS] uQcontent) [FWS] DQUOTE
[CFWS] [CFWS]
utf8-ccontent = ctext / utf8-quoted-pair / comment uCcontent = ctext / uQuoted-Pair / comment
utf8-qtext = qtext / UTF8-xtra-char uQtext = qtext / UTF8-xtra-char
utf8-atext = 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-xtra-char
utf8-atom = [CFWS] 1*utf8-atext [CFWS] uAtom = [CFWS] 1*uAtext [CFWS]
utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS] uDot-Atom = [CFWS] uDot-Atom-text [CFWS]
utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext) uDot-Atom-text = 1*uAtext *("." 1*uAtext)
qcontent = utf8-qcontent 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:" unstructured CRLF
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. <unstructured> header fields.
Note, however, this does not remove any constraint on the character Note, however, this does not remove any constraint on the character
skipping to change at page 8, line 14 skipping to change at page 8, line 14
timezone in the Date: headers are still expressed in ASCII. And timezone in the Date: headers are still expressed in ASCII. And
also, none of this revised syntax changes what is allowed in a also, none of this revised syntax changes what is allowed in a
<message-id>, which will still remain in pure ASCII. <message-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 to permit UTF-8 all header fields containing <mailbox>es are updated to permit UTF-8
addresses. addresses.
mailbox = name-addr / addr-spec / utf8-addr-spec mailbox = name-addr / addr-spec / uAddr-Spec
angle-addr =/ [CFWS] "<" utf8-addr-spec">" [CFWS] / angle-addr =/ [CFWS] "<" uAddr-Spec">" [CFWS] /
obs-angle-addr obs-angle-addr
utf8-addr-spec = utf8-local-part "@" utf8-domain uAddr-Spec = uLocal-Part "@" uDomain
utf8-local-part= utf8-dot-atom / utf8-quoted-string / obs-local-part uLocal-Part = uDot-String / uQuoted-String
utf8-domain = utf8-dot-atom / domain-literal / obs-domain uQuoted-String = DQUOTE *uQcontent DQUOTE uDomain
= (sub-uDomain 1*("." sub-uDomain)) / address-literal
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> "DISPLAY_NAME" <non-ASCII@non-ASCII>
; message will bounce if UTF8SMTPbis extension is not supported ; message will bounce if UTF8SMTPbis extension is not supported
<non-ASCII@non-ASCII> <non-ASCII@non-ASCII>
; without DISPLAY_NAME and quoted string ; without DISPLAY_NAME and quoted string
; message will bounce if UTF8SMTPbis extension is not supported ; message will bounce if UTF8SMTPbis extension is not supported
skipping to change at page 9, line 10 skipping to change at page 9, line 11
The "Return-Path" header field provides the email return address in The "Return-Path" header field provides the email return address in
the mail delivery. Thus, the header is augmented to carry UTF-8 the mail delivery. Thus, the header is augmented to carry UTF-8
addresses (see the revised syntax of <angle-addr> in Section 4.4 of addresses (see the revised syntax of <angle-addr> in Section 4.4 of
this document). This will not break the rule of trace field this document). This will not break the rule of trace field
integrity, because the header field is added at the last MTA and integrity, because the header field is added at the last MTA and
described in [RFC5321]. described in [RFC5321].
The <item-value> on "Received:" syntax is augmented to allow UTF-8 The <item-value> on "Received:" syntax is augmented to allow UTF-8
email address in the "For" field. <angle-addr> is augmented to email address in the "For" field. <angle-addr> is augmented to
include UTF-8 email address. In order to allow UTF-8 email addresses include UTF-8 email address. In order to allow UTF-8 email addresses
in an <addr-spec>, <utf8-addr-spec> is added to <item-value>. in an <addr-spec>, <uAddr-Spec> is added to <item-value>.
item-value =/ utf8-addr-spec item-value =/ 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.yao-eai-rfc5336bis] or within a non-SMTP environment which [I-D.yao-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.
skipping to change at page 12, line 22 skipping to change at page 12, line 29
1. Applied Errata suggested by Alfred Hoenes. 1. Applied Errata suggested by Alfred Hoenes.
2. Adjust [RFC2821] and [RFC2822] to [RFC5321] and [RFC5322]. 2. Adjust [RFC2821] and [RFC2822] to [RFC5321] and [RFC5322].
3. Abrogate <alt-address> in ABNF of <angle-addr>. 3. Abrogate <alt-address> in ABNF of <angle-addr>.
4. Revoke [RFC5504] from this document. 4. Revoke [RFC5504] from this document.
5. Upgrade some references from I-Ds to RFC. 5. Upgrade some references from I-Ds to RFC.
8.2. draft-ietf-eai-rfc5335bis-01
1. Author name revised.
8.3. draft-ietf-eai-rfc5335bis-02
1. ABNF revised.
9. References 9. References
9.1. Normative References 9.1. Normative References
[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-01 (work draft-ietf-eai-frmwrk-4952bis-02 (work
in progress), July 2010. in progress), July 2010.
[I-D.yao-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension [I-D.yao-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension
for Internationalized Email Address", for Internationalized Email Address",
draft-yao-eai-rfc5336bis-00 (work in draft-yao-eai-rfc5336bis-01 (work in
progress), July 2009. progress), July 2009.
[RFC1652] Klensin, J., Freed, N., Rose, M., [RFC1652] Klensin, J., Freed, N., Rose, M.,
Stefferud, E., and D. Crocker, "SMTP Stefferud, E., and D. Crocker, "SMTP
Service Extension for 8bit- Service Extension for 8bit-
MIMEtransport", RFC 1652, July 1994. MIMEtransport", RFC 1652, July 1994.
[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.
 End of changes. 29 change blocks. 
30 lines changed or deleted 40 lines changed or added

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