draft-ietf-eai-rfc5335bis-05.txt   draft-ietf-eai-rfc5335bis-06.txt 
Email Address Internationalization Y. Abel Email Address Internationalization Y. Abel
(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 December 04, 2010 Updates: 2045,5321,5322 December 06, 2010
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: June 7, 2011 Expires: June 9, 2011
Internationalized Email Headers Internationalized Email Headers
draft-ietf-eai-rfc5335bis-05 draft-ietf-eai-rfc5335bis-06
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 June 7, 2011. This Internet-Draft will expire on June 9, 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 39 skipping to change at page 2, line 39
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . 12
8.3. draft-ietf-eai-rfc5335bis-02 . . . . . . . . . . . . . . . 12 8.3. draft-ietf-eai-rfc5335bis-02 . . . . . . . . . . . . . . . 12
8.4. draft-ietf-eai-rfc5335bis-03 . . . . . . . . . . . . . . . 12 8.4. draft-ietf-eai-rfc5335bis-03 . . . . . . . . . . . . . . . 12
8.5. draft-ietf-eai-rfc5335bis-04 . . . . . . . . . . . . . . . 13 8.5. draft-ietf-eai-rfc5335bis-04 . . . . . . . . . . . . . . . 13
8.6. draft-ietf-eai-rfc5335bis-05 . . . . . . . . . . . . . . . 13 8.6. draft-ietf-eai-rfc5335bis-05 . . . . . . . . . . . . . . . 13
8.7. draft-ietf-eai-rfc5335bis-06 . . . . . . . . . . . . . . . 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 4, line 23 skipping to change at page 4, line 23
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 "UTF8SMTP" is used to prevent the transmission of messages with UTF-8
UTF-8 header fields to systems that cannot handle such messages. header fields to systems that cannot handle such messages.
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 [I-D.ietf-eai-rfc5721bis] and fields are addressed in [I-D.ietf-eai-rfc5721bis] and
[I-D.ietf-eai-5378bis]. [I-D.ietf-eai-5378bis].
skipping to change at page 5, line 7 skipping to change at page 5, line 7
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
SMTP clients can send header fields in UTF-8 format, if the SMTP clients can send header fields in UTF-8 format, if the UTF8SMTP
UTF8SMTPbis extension is advertised by the SMTP server or is extension is advertised by the SMTP server or is permitted by other
permitted by other transport mechanisms. transport mechanisms.
This protocol does NOT change the [RFC5322] rules for defining header This protocol does NOT change the [RFC5322] rules for defining header
field names. The bodies of header fields are allowed to contain field names. The bodies of header fields are allowed to contain
UTF-8 characters, but the header field names themselves must contain UTF-8 characters, but the header field names themselves must contain
only ASCII characters. only ASCII characters.
To permit UTF-8 characters in field values, the header definition in To permit UTF-8 characters in field values, the header definition in
[RFC5322] is extended to support the new format. The following ABNF [RFC5322] is extended to support the new format. The following ABNF
is defined to substitute those definitions in [RFC5322]. is defined to substitute those definitions in [RFC5322].
skipping to change at page 6, line 11 skipping to change at page 6, line 11
"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 UTF8SMTP, multiple levels of encoding may
occur. This is expected to be rarely seen in practice, and the occur. This is expected to be rarely seen in practice, and the
potential complexity of other ways of dealing with the issue are potential complexity of other ways of dealing with the issue are
thought to be larger than the complexity of allowing nested encodings thought to be larger than the complexity of allowing nested encodings
where necessary. where necessary.
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 Section 3.2.2 of RFC 5322>
CFWS = <see [RFC5322] Section 3.2.2> CFWS = <see Section 3.2.2 of RFC 5322>
ctext =/ UTF8-non-ascii ctext =/ UTF8-non-ascii
; Extending ctext in RFC 5322, Section 3.2.2
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.
skipping to change at page 7, line 16 skipping to change at page 7, line 16
%d11-12 / ; US-ASCII NUL, CR, and LF %d11-12 / ; US-ASCII NUL, CR, and LF
%d14-127 / %d14-127 /
UTF8-non-ascii UTF8-non-ascii
uQuoted-Pair = ("\" (VCHAR / WSP / UTF8-non-ascii )) / obs-qp uQuoted-Pair = ("\" (VCHAR / WSP / UTF8-non-ascii )) / obs-qp
VCHAR = <See appendix B.1 of RFC 5234> VCHAR = <See appendix B.1 of RFC 5234>
WSP = <See appendix B.1 of RFC 5234> WSP = <See appendix B.1 of RFC 5234>
uQcontent = uQtext / uQuoted-Pair obs-qp = <See Section 4.1 of RFC 5322>
uQuoted-Pair = ("\" uText) / obs-qp uQcontent = uQtext / uQuoted-Pair
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-non-ascii 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.
skipping to change at page 8, line 4 skipping to change at page 7, line 51
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" ":" *uText description = "Content-Description" ":" *uText
; Replace description in Section 8 of [RFC2045] ; Replace description in RFC 2045, Section 8
The <uText> syntax is extended above to allow UTF-8 in all The <uText> syntax is extended above to allow UTF-8 in all
<description> 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:" header fields are still expressed in ASCII. timezone in the "Date:" header fields are still expressed in ASCII.
And 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
<msg-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 of RFC 5322 ; Replace mailbox in RFC 5322, Section 3.4
angle-addr =/ [CFWS] "<" uAddr-Spec ">" [CFWS] angle-addr =/ [CFWS] "<" uAddr-Spec ">" [CFWS]
; Replace angle-addr in Section 3.4 of RFC 5322 ; Extending angle-addr in RFC 5322, Section 3.4
uAddr-Spec = uLocal-Part "@" uDomain uAddr-Spec = uLocal-Part "@" uDomain
uLocal-Part = uDot-Atom / uQuoted-String / obs-local-part uLocal-Part = uDot-Atom / uQuoted-String / obs-local-part
; Replace Local-Part in Section 3.4.1 of RFC 5322 ; Replace Local-Part in RFC 5322, Section 3.4.1
uDomain = uDot-Atom / domain-literal / obs-domain uQuoted-String = [CFWS] DQUOTE *([FWS] uQcontent) [FWS] DQUOTE [CFWS]
obs-local-part = <See Section 4.4 of RFC 5322>
uDomain = uDot-Atom / domain-literal / obs-domain
domain-literal = <See Section 3.4.1 of RFC 5322> domain-literal = <See Section 3.4.1 of RFC 5322>
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 be rejected if UTF8SMTPbis extension is not supported ; message will be rejected if UTF8SMTP 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 be rejected if UTF8SMTPbis extension is not supported ; message will be rejected if UTF8SMTP extension is not supported
4.5. Trace Field Syntax 4.5. Trace Field Syntax
The 'uFor' clause in "Received:" fields has been allowed the use of The 'uFor' clause in "Received:" fields has been allowed the use of
internationalized addresses in "For" fields. It described in internationalized addresses in "For" fields. It described in
[I-D.ietf-eai-rfc5336bis], Section 3.6.3. [I-D.ietf-eai-rfc5336bis], Section 3.6.3.
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
skipping to change at page 11, line 47 skipping to change at page 11, line 47
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".
The security impact of UTF-8 headers on email signature systems such The security impact of UTF-8 headers on email signature systems such
as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is as Domain Keys Identified Mail (DKIM), S/MIME, and OpenPGP is
discussed in [I-D.ietf-eai-frmwrk-4952bis], Section 14. discussed in [I-D.ietf-eai-frmwrk-4952bis], Section 14.
6. IANA Considerations 6. IANA Considerations
IANA has registered the message/global MIME type using the IANA is requested to update the registration of the message/global
registration form contained in Section 4.4. MIME type using the registration form contained in Section 4.6.
7. Acknowledgements 7. Acknowledgements
This document incorporates many ideas first described in Internet- This document incorporates many ideas first described in Internet-
Draft form by Paul Hoffman, although many details have changed from Draft form by Paul Hoffman, although many details have changed from
that earlier work. that earlier work.
The author especially thanks Jeff Yeh for his efforts and The author especially thanks Jeff Yeh for his efforts and
contributions on editing previous versions. contributions on editing previous versions.
Most of the content of this document is provided by John C Klensin. Most of the content of this document is provided by John C Klensin.
Also, some significant comments and suggestions were received from Also, some significant comments and suggestions were received from
Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris Charles H. Lindsey, Kari Hurtta, Pete Resnick, Alexey Melnikov, Chris
Newman, Yangwoo Ko, Yoshiro Yoneya, and other members of the JET team Newman, Yangwoo Ko, Yoshiro Yoneya, and other members of the JET team
(Joint Engineering Team) and were incorporated into the document. (Joint Engineering Team) and were incorporated into the document.
The editor sincerely thanks them for their contributions. The editor sincerely thanks them for their contributions.
8. Edit history 8. Edit history
This section is used for tracking the update of this document. Will [[RFC Editor: please remove this section before publishing.]]
be removed after finalize.
8.1. draft-ietf-eai-rfc5335bis-00 8.1. draft-ietf-eai-rfc5335bis-00
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.
skipping to change at page 13, line 14 skipping to change at page 13, line 13
3. Improve sentence 3. Improve sentence
8.5. draft-ietf-eai-rfc5335bis-04 8.5. draft-ietf-eai-rfc5335bis-04
1. improve sentences and ABNF revised based on AD and Co-chairs 1. improve sentences and ABNF revised based on AD and Co-chairs
8.6. draft-ietf-eai-rfc5335bis-05 8.6. draft-ietf-eai-rfc5335bis-05
1. ABNF revised in Section 4.4 based on AD comments 1. ABNF revised in Section 4.4 based on AD comments
8.7. draft-ietf-eai-rfc5335bis-06
1. ABNF revised
2. improve Section 6
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-eai-5378bis] Resnick, P., Newman, C., and S. Shen, [I-D.ietf-eai-5378bis] Resnick, P., Newman, C., and S. Shen,
"IMAP Support for UTF-8", "IMAP Support for UTF-8",
draft-ietf-eai-5378bis-00 (work in draft-ietf-eai-5378bis-00 (work in
progress), November 2010. 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-05 (work in draft-ietf-eai-rfc5336bis-07 (work in
progress), December 2010. progress), December 2010.
[I-D.ietf-eai-rfc5721bis] Gellens, R., Newman, C., Yao, J., and [I-D.ietf-eai-rfc5721bis] Gellens, R., Newman, C., Yao, J., and
K. Fujiwara, "POP3 Support for UTF-8", K. Fujiwara, "POP3 Support for UTF-8",
draft-ietf-eai-rfc5721bis-00 (work in draft-ietf-eai-rfc5721bis-00 (work in
progress), September 2010. progress), September 2010.
[NFC] Davis, M. and K. Whistler, "Unicode
Standard Annex #15: Unicode
Normalization Forms", September 2010,
<http://www.unicode.org/reports/
tr15/>.
[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
Format for Network Interchange", Format for Network Interchange",
skipping to change at page 14, line 15 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., [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.
[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.
 End of changes. 27 change blocks. 
38 lines changed or deleted 47 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/