draft-ietf-eai-rfc5336bis-10.txt   draft-ietf-eai-rfc5336bis-11.txt 
Network Working Group J. Yao Network Working Group J. Yao
Internet-Draft W. Mao Internet-Draft W. Mao
Obsoletes: RFC5336 (if approved) CNNIC Obsoletes: 5336 (if approved) CNNIC
Updates: RFC5321 and 5322 June 2, 2011 Intended status: Standards Track July 7, 2011
(if approved) Expires: January 8, 2012
Intended status: Standards Track
Expires: December 4, 2011
SMTP Extension for Internationalized Email Address SMTP Extension for Internationalized Email
draft-ietf-eai-rfc5336bis-10.txt draft-ietf-eai-rfc5336bis-11.txt
Abstract Abstract
This document specifies an SMTP extension for transport and delivery This document specifies an SMTP extension for transport and delivery
of email messages with internationalized email addresses or header of email messages with internationalized email addresses or header
information. information.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 33
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 December 4, 2011. This Internet-Draft will expire on January 8, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 29 skipping to change at page 3, line 29
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 10
3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 11 3.7.2. Mail eXchangers . . . . . . . . . . . . . . . . . . . 11
3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11 3.7.3. Trace Information . . . . . . . . . . . . . . . . . . 11
3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 16 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 16
7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 16 7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 17
7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 17 7.3. draft-ietf-eai-rfc5336bis: Version 01 . . . . . . . . . . 17
7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 17 7.4. draft-ietf-eai-rfc5336bis: Version 02 . . . . . . . . . . 17
7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 17 7.5. draft-ietf-eai-rfc5336bis: Version 03 . . . . . . . . . . 17
7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 17 7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 17
7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 17 7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 17
7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 17 7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 17
7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 17 7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 17
7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 17 7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 17
7.11. draft-ietf-eai-rfc5336bis: Version 09 . . . . . . . . . . 17 7.11. draft-ietf-eai-rfc5336bis: Version 09 . . . . . . . . . . 18
7.12. draft-ietf-eai-rfc5336bis: Version 10 . . . . . . . . . . 18 7.12. draft-ietf-eai-rfc5336bis: Version 10 . . . . . . . . . . 18
7.13. draft-ietf-eai-rfc5336bis: Version 11 . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . . 19 8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Simple Mail Transfer Protocol [RFC5321] provides a negotiation The Simple Mail Transfer Protocol [RFC5321] provides a negotiation
mechanism about service extension by which SMTP clients can discover mechanism about service extension by which SMTP clients can discover
SMTP server capabilities and make decisions for further processing. SMTP server capabilities and make decisions for further processing.
skipping to change at page 5, line 10 skipping to change at page 5, line 10
"ASCII address", "internationalized email address", "non-ASCII "ASCII address", "internationalized email address", "non-ASCII
address", "UTF8SMTPbis", "internationalized message", and "message" address", "UTF8SMTPbis", "internationalized message", and "message"
are used in this document according to the definitions in the are used in this document according to the definitions in the
framework document. framework document.
Non-ASCII characters or strings referred in this document MUST be Non-ASCII characters or strings referred in this document MUST be
expressed in UTF-8, a standard Unicode Encoding Form. expressed in UTF-8, a standard Unicode Encoding Form.
This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some This specification uses Augmented BNF (ABNF) rules [RFC5234]. Some
basic rules in this document can be found from [RFC5234] or [RFC5321] basic rules in this document can be found from [RFC5234] or [RFC5321]
or [RFC5322] under the same names. under the same names.
1.3. Updates to Other Specifications 1.3. Updates to Other Specifications
This specification modifies RFC 5321 by permitting internationalized This specification extends some syntax rules defined in RFC 5321 and
email address in the envelope. It also updates some syntax rules permits internationalized email address in the envelope, but it does
defined in RFC 5321. It modifies RFC 5322 by permitting data formats not modify RFC 5321. It permits data formats defined in
defined in [RFC5335bis]. It does not modify the 8BITMIME [RFC5335bis], but it does not modify RFC 5322. It does require that
specification [RFC6152] in any way, but it does require that the the 8BITMIME extension [RFC6152] be announced by the UTF8SMTPbis-
8BITMIME extension be announced by the EAI-aware SMTP server and used aware SMTP server and used with "BODY=8BMITMIME" by the UTF8SMTPbis-
with "BODY=8BMITMIME" by the EAI-aware SMTP client. aware SMTP client, but it does not modify the 8BITMIME specification
in any way.
2. Overview of Operation 2. Overview of Operation
This specification describes an optional extension to the email This specification describes an optional extension to the email
transport mechanism that permits non-ASCII characters in both the transport mechanism that permits non-ASCII characters in both the
envelope and header fields of messages, which are encoded in UTF-8. envelope and header fields of messages, which are encoded in UTF-8.
The extension is identified with the token "UTF8SMTPbis". The extension is identified with the token "UTF8SMTPbis".
The EAI UTF-8 header specification [RFC5335bis] provides the details The internationalized email headers specification [RFC5335bis]
of email header features enabled by this extension provides the details of email header features enabled by this
extension
3. Mail Transport-Level Protocol 3. Mail Transport-Level Protocol
3.1. Framework for the Internationalization Extension 3.1. Framework for the Internationalization Extension
The following service extension is defined: The following service extension is defined:
1. The name of the SMTP service extension is "Email Address 1. The name of the SMTP service extension is "Internationalized
Internationalization". Email".
2. The EHLO keyword value associated with this extension is 2. The EHLO keyword value associated with this extension is
"UTF8SMTPbis". "UTF8SMTPbis".
3. No parameter values are defined for this EHLO keyword value. In 3. No parameter values are defined for this EHLO keyword value. In
order to permit future (although unanticipated) extensions, the order to permit future (although unanticipated) extensions, the
EHLO response MUST NOT contain any parameters for this keyword. EHLO response MUST NOT contain any parameters for this keyword.
The EAI-aware SMTP client MUST ignore any parameters if they The UTF8SMTPbis-aware SMTP client MUST ignore any parameters if
appear for this keyword; that is, the EAI-aware SMTP client MUST they appear for this keyword; that is, the UTF8SMTPbis-aware
behave as if the parameters do not appear. If an SMTP server SMTP client MUST behave as if the parameters do not appear. If
includes UTF8SMTPbis in its EHLO response, it MUST be fully an SMTP server includes UTF8SMTPbis in its EHLO response, it
compliant with this version of this specification. MUST be fully compliant with this version of this specification.
4. One OPTIONAL parameter "UTF8SMTPbis" is added to the MAIL 4. One OPTIONAL parameter "UTF8SMTPbis" is added to the MAIL
command. The parameter has no value. If this parameter is set command. The parameter has no value. If this parameter is set
in the MAIL command, it indicates that the SMTP client is EAI- in the MAIL command, it indicates that the SMTP client is
aware and asserts that the envelope includes the non-ASCII UTF8SMTPbis-aware and asserts that the envelope includes the
address or the message being sent is internationalized message non-ASCII address or the message being sent is internationalized
or the message being sent needs the UTF8SMTPbis support. message or the message being sent needs the UTF8SMTPbis support.
5. The maximum length of a MAIL command line is increased by 12 5. The maximum length of a MAIL command line is increased by 13
characters by the possible addition of the UTF8SMTPbis characters by the possible addition of the UTF8SMTPbis
parameter. [[anchor6: RFC Editor: the number '12' will be parameter. [[anchor6: RFC Editor: the number '13' will be
replaced by the new number (1 space + length of the new keyword replaced by the new number (2 spaces + length of the new keyword
supposed to replace "UTF8SMTPbis").]] supposed to replace "UTF8SMTPbis").]]
6. One OPTIONAL parameter "UTF8SMTPbis" is added to the VRFY and 6. One OPTIONAL parameter "UTF8SMTPbis" is added to the VRFY and
EXPN commands. The parameter UTF8SMTPbis has no value. The EXPN commands. The parameter UTF8SMTPbis has no value. The
parameter indicates that the SMTP client can accept Unicode parameter indicates that the SMTP client can accept Unicode
characters in UTF-8 encoding in replies from the VRFY and EXPN characters in UTF-8 encoding in replies from the VRFY and EXPN
commands. commands.
7. No additional SMTP verbs are defined by this extension. 7. No additional SMTP verbs are defined by this extension.
8. Servers offering this extension MUST provide support for, and 8. Servers offering this extension MUST provide support for, and
announce, the 8BITMIME extension [RFC6152]. announce, the 8BITMIME extension [RFC6152].
9. The reverse-path and forward-path of the SMTP MAIL and RCPT 9. The reverse-path and forward-path of the SMTP MAIL and RCPT
skipping to change at page 6, line 40 skipping to change at page 6, line 40
3.2. The UTF8SMTPbis Extension 3.2. The UTF8SMTPbis Extension
An SMTP server that announces this UTF8SMTPbis extension MUST be An SMTP server that announces this UTF8SMTPbis extension MUST be
prepared to accept a UTF-8 string [RFC3629] in any position in which prepared to accept a UTF-8 string [RFC3629] in any position in which
RFC 5321 specifies that a <mailbox> can appear. Although the RFC 5321 specifies that a <mailbox> can appear. Although the
characters in the <local-part> are permitted to contain non-ASCII characters in the <local-part> are permitted to contain non-ASCII
characters, actual parsing of the <local-part>, and the delimiters characters, actual parsing of the <local-part>, and the delimiters
used, are unchanged from the base email specification [RFC5321]. Any used, are unchanged from the base email specification [RFC5321]. Any
domain names to be looked up in the DNS MUST allow for [RFC5890] domain names to be looked up in the DNS MUST allow for [RFC5890]
behavior. When doing lookups, the EAI-aware SMTP client or server behavior. When doing lookups, the UTF8SMTPbis-aware SMTP client or
MUST either use a Unicode aware DNS library, or transform it to server MUST either use a Unicode aware DNS library, or transform it
A-label defined in [RFC5890]. to A-label defined in [RFC5890].
An SMTP client that receives the UTF8SMTPbis extension keyword in An SMTP client that receives the UTF8SMTPbis extension keyword in
response to the EHLO command MAY transmit mailbox names within SMTP response to the EHLO command MAY transmit mailbox names within SMTP
commands as internationalized strings in UTF-8 form. It MAY send a commands as internationalized strings in UTF-8 form. It MAY send a
UTF-8 header [RFC5335bis] (which may also include mailbox names in UTF-8 header [RFC5335bis] (which may also include mailbox names in
UTF-8). It MAY transmit the domain parts of mailbox names within UTF-8). It MAY transmit the domain parts of mailbox names within
SMTP commands or the message header as A-labels or U-labels SMTP commands or the message header as A-labels or U-labels
[RFC5890]. The presence of the UTF8SMTPbis extension does not change [RFC5890]. The presence of the UTF8SMTPbis extension does not change
RFC 5321 server relaying behaviors. RFC 5321 server relaying behaviors.
If the UTF8SMTPbis SMTP extension is not offered by the SMTP server, If the UTF8SMTPbis SMTP extension is not offered by the SMTP server,
the EAI-aware SMTP client MUST NOT transmit an internationalized the UTF8SMTPbis-aware SMTP client MUST NOT transmit an
email address and MUST NOT transmit a mail message containing internationalized email address and MUST NOT transmit a mail message
internationalized mail headers as described in [RFC5335bis] at any containing internationalized mail headers as described in
level within its MIME structure [RFC2045] and [RFC2047]. (For this [RFC5335bis] at any level within its MIME structure [RFC2045] and
paragraph, the internationalized domain name in the form of A-labels [RFC2047]. (For this paragraph, the internationalized domain name in
as specified in IDNA definitions [RFC5890] is not considered to be the form of A-labels as specified in IDNA definitions [RFC5890] is
"internationalized".) Instead, if an EAI-aware SMTP client (EAI- not considered to be "internationalized".) Instead, if an
aware SMTP sender) attempts to transfer an internationalized message UTF8SMTPbis-aware SMTP client (UTF8SMTPbis-aware SMTP sender)
and encounters an SMTP server that does not support the extension, it attempts to transfer an internationalized message and encounters an
MUST make one of the following three choices and the priority order SMTP server that does not support the extension, it MUST make one of
is 1, 2 and 3. the following three choices and the priority order is 1, 2 and 3.
1. It MAY either reject the message during the SMTP transaction or 1. It MAY either reject the message during the SMTP transaction or
accept the message and then generate and transmit a notification accept the message and then generate and transmit a notification
of non-deliverability. Such notification MUST be done as of non-deliverability. Such notification MUST be done as
specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the EAI specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the
delivery status notification (DSN) specification [RFC5337bis]. internationalized delivery status and disposition notifications
2. If and only if the EAI-aware SMTP client (sender) is a Message specification [RFC5337bis].
Submission Agent ("MSA") [RFC4409] [RFC5598], MSA may choose its 2. If and only if the UTF8SMTPbis-aware SMTP client (sender) is a
own way to deal with this scenario according to the provisions of Message Submission Agent ("MSA") [RFC4409] [RFC5598], it may
[RFC4409] or its future versions. But the detailed specification choose its own way to deal with this scenario according to the
of this process and its results is outside the scope of this provisions of [RFC4409] or its future versions. But the detailed
document. specification of this process and its results are outside the
scope of this document.
3. It MAY find an alternate route to the destination that permits 3. It MAY find an alternate route to the destination that permits
UTF8SMTPbis. That route MAY be discovered by trying alternate UTF8SMTPbis. That route MAY be discovered by trying alternate
Mail eXchanger (MX) hosts (using preference rules as specified in Mail eXchanger (MX) hosts (using preference rules as specified in
RFC 5321) or using other means available to the EAI-aware SMTP RFC 5321) or using other means available to the UTF8SMTPbis-aware
client. SMTP client.
This document applies only when an EAI-aware SMTP client is trying to
send an internationalized message to an EAI-aware SMTP server. For
all other cases, and for addresses and messages that do not require
an UTF8SMTPbis extension, EAI-aware SMTP clients and servers do not
change the behavior specified in [RFC5321].
An EAI-aware MUA/MSA sending to a legacy SMTP server [RFC5321] and This document applies when an UTF8SMTPbis-aware SMTP client or server
[RFC5322] MAY convert an ASCII@U-label [RFC5890] address into the supports the UTF8SMTPbis extension. For all other cases, and for
format of ASCII@A-label [RFC5890] if the email address is in the addresses and messages that do not require an UTF8SMTPbis extension,
format of ASCII@U-label. UTF8SMTPbis-aware SMTP clients and servers do not change the behavior
specified in [RFC5321].
3.3. Extended Mailbox Address Syntax 3.3. Extended Mailbox Address Syntax
RFC 5321, section 4.1.2, defines the syntax of a <Mailbox> entirely RFC 5321, section 4.1.2, defines the syntax of a <Mailbox> entirely
in terms of ASCII characters. This document will make <Mailbox> to in terms of ASCII characters. This document extends <Mailbox> to add
support non-ASCII characters. support of non-ASCII characters.
The key changes made by this specification include: The key changes made by this specification include:
o In order to update the <Mailbox> to support the internationalized o In order to update the <Mailbox> to support the internationalized
email address, the <Mailbox> ABNF rule will be importted from RFC email address, the <Mailbox> ABNF rule will be imported from RFC
5321 directly, and other related rules are importted from RFC 5321 directly, and other related rules are imported from RFC 5321,
5321, RFC 5234, RFC 5890 or RFC 5335bis, or are extended in this RFC 5234, RFC 5890 or RFC 5335bis, or are extended in this
document. document.
o Extend the definition of <sub-domain> to permit both the RFC 5321 o Extend the definition of <sub-domain> to permit both the RFC 5321
definition and a UTF-8 string in a DNS label that is conforming definition and a UTF-8 string in a DNS label that is conforming
with IDNA definitions [RFC5890]. with IDNA definitions [RFC5890].
o Extend the definition of <atext> to permit both the RFC 5321 o Extend the definition of <atext> to permit both the RFC 5321
definition and a UTF-8 string. That string MUST NOT contain any definition and a UTF-8 string. That string MUST NOT contain any
of the ASCII graphics or controls characters. of the ASCII graphics or controls characters.
The following ABNF rules will be importted from RFC 5321, section The following ABNF rules will be imported from RFC 5321, section
4.1.2 directly: 4.1.2 directly:
o <Mailbox> o <Mailbox>
o <Local-part> o <Local-part>
o <Dot-string> o <Dot-string>
o <Quoted-string> o <Quoted-string>
o <QcontentSMTP> o <QcontentSMTP>
o <Domain> o <Domain>
o <Atom> o <Atom>
The following ABNF rule will be importted from RFC 5335bis, section The following ABNF rule will be imported from RFC 5335bis, section
4.1 directly: 4.1 directly:
o <UTF8-non-ascii> o <UTF8-non-ascii>
The following ABNF rule will be importted from RFC 5234, appendix B.1 The following ABNF rule will be imported from RFC 5234, appendix B.1
directly: directly:
o <DQUOTE> o <DQUOTE>
The following ABNF rule will be importted from RFC 5890, section The following ABNF rule will be imported from RFC 5890, section
2.3.2.1 directly: 2.3.2.1 directly:
o <U-label> o <U-label>
The following rules are extended in ABNF [RFC5234] as follows. The following rules are extended in ABNF [RFC5234] as follows.
sub-domain =/ U-label sub-domain =/ U-label
; extend the defintion of sub-domain in RFC5321, section 4.1.2 ; extend the definition of sub-domain in RFC5321, section 4.1.2
atext =/ UTF8-non-ascii atext =/ UTF8-non-ascii
; extend the defintion of atext in RFC5321, section 4.1.2 ; extend the definition of atext in RFC5321, section 4.1.2
quoted-pairSMTP =/ %d92 UTF8-non-ascii quoted-pairSMTP =/ %d92 UTF8-non-ascii
; extend the defintion of quoted-pairSMTP in RFC5321, section 4.1.2 ; extend the definition of quoted-pairSMTP in RFC5321, section 4.1.2
qtextSMTP =/ UTF8-non-ascii qtextSMTP =/ UTF8-non-ascii
; extend the defintion of qtextSMTP in RFC5321, section 4.1.2 ; extend the definition of qtextSMTP in RFC5321, section 4.1.2
3.4. MAIL Command Parameter Usage 3.4. MAIL Command Parameter Usage
If the envelope or message being sent requires the capabilities of If the envelope or message being sent requires the capabilities of
the UTF8SMTPbis extension, the EAI-aware SMTP client MUST supply the the UTF8SMTPbis extension, the UTF8SMTPbis-aware SMTP client MUST
UTF8SMTPbis parameter with the MAIL command. If this parameter is supply the UTF8SMTPbis parameter with the MAIL command. If this
provided, it MUST have no value. If the EAI-aware SMTP client is parameter is provided, it MUST have no value. If the UTF8SMTPbis-
aware that neither the envelope nor the message being sent requires aware SMTP client is aware that neither the envelope nor the message
any of the UTF8SMTPbis extension capabilities, it SHOULD NOT supply being sent requires any of the UTF8SMTPbis extension capabilities, it
the UTF8SMTPbis parameter with the MAIL command. SHOULD NOT supply the UTF8SMTPbis parameter with the MAIL command.
Because there is no guarantee that a next-hop SMTP server will Because there is no guarantee that a next-hop SMTP server will
support the UTF8SMTPbis extension, use of the UTF8SMTPbis extension support the UTF8SMTPbis extension, use of the UTF8SMTPbis extension
always carries a risk of transmission failure. In fact, during the always carries a risk of transmission failure. In fact, during the
early stages of deployment for the UTF8SMTPbis extension, the risk early stages of deployment for the UTF8SMTPbis extension, the risk
will be quite high. Hence there is a distinct near-term advantage will be quite high. Hence there is a distinct near-term advantage
for ASCII-only messages to be sent without using this extension. The for ASCII-only messages to be sent without using this extension. The
long-term advantage of casting ASCII [ASCII] characters(0x7f and long-term advantage of casting ASCII [ASCII] characters(0x7f and
below) as UTF-8 form is that it permits pure-Unicode environments. below) as UTF-8 form is that it permits pure-Unicode environments.
This specification does not require that the EAI-aware SMTP client This specification does not require that the UTF8SMTPbis-aware SMTP
inspect the message or otherwise go to extraordinary lengths to client inspect the message or otherwise go to extraordinary lengths
assure itself whether the UTF8SMTPbis extension is REQUIRED for the to assure itself whether the UTF8SMTPbis extension is REQUIRED for
particular message. the particular message.
3.5. Non-ASCII addresses and Reply-codes 3.5. Non-ASCII addresses and Reply-codes
An EAI-aware SMTP client MUST only send an internationalized message An UTF8SMTPbis-aware SMTP client MUST only send an internationalized
to an SMTP server that supports UTF8SMTPbis. If the SMTP server does message to an SMTP server that supports UTF8SMTPbis. If the SMTP
not support this option, then the EAI-aware SMTP client has three server does not support this option, then the UTF8SMTPbis-aware SMTP
choices according to section 3.2 of this specification. client has three choices according to section 3.2 of this
specification.
The three-digit Reply-codes used in this section are based on their The three-digit Reply-codes used in this section are based on their
meanings as defined in RFC 5321. meanings as defined in RFC 5321.
When messages are rejected because the RCPT command requires an ASCII When messages are rejected because the RCPT command requires an ASCII
address, the reply-code 553 is returned with the meaning "mailbox address, the reply-code 553 is returned with the meaning "mailbox
name not allowed". When messages are rejected because the MAIL name not allowed". When messages are rejected because the MAIL
command requires an ASCII address, the reply-code 550 is returned command requires an ASCII address, the reply-code 550 is returned
with the meaning "mailbox unavailable". When the EAI-aware SMTP with the meaning "mailbox unavailable". When the UTF8SMTPbis-aware
server supports enhanced mail system status codes [RFC3463], reply- SMTP server supports enhanced mail system status codes [RFC3463],
code "X.6.7" [RFC5248] is used, meaning that "non-ASCII addresses not reply-code "X.6.7" [RFC5248] is used, meaning that "non-ASCII
permitted for that sender/recipient". addresses not permitted for that sender/recipient".
When messages are rejected for other reasons, the server follows the When messages are rejected for other reasons, the server follows the
model of the base email specifications in RFC 5321; this extension model of the base email specifications in RFC 5321; this extension
does not change those circumstances or reply messages. does not change those circumstances or reply messages.
If the reply-code is issued after the final "." of the DATA command, If the reply-code is issued after the final "." of the DATA command,
the reply-code "554" is used with the meaning "Transaction failed". the reply-code "554" is used with the meaning "Transaction failed".
When the EAI-aware SMTP server supports enhanced mail system status When the UTF8SMTPbis-aware SMTP server supports enhanced mail system
codes [RFC3463], reply-code "X.6.9" [RFC5248] is used, meaning that status codes [RFC3463], reply-code "X.6.9" [RFC5248] is used, meaning
"UTF-8 header message can not be transmitted to one or more that "UTF-8 header message can not be transmitted to one or more
recipients, so the message MUST be rejected". recipients, so the message MUST be rejected".
3.6. Body Parts and SMTP Extensions 3.6. Body Parts and SMTP Extensions
The MAIL command parameter UTF8SMTPbis asserts that a message is an The MAIL command parameter UTF8SMTPbis asserts that a message is an
internationalized message or the message being sent needs the internationalized message or the message being sent needs the
UTF8SMTPbis support. The message being sent via the MAIL command UTF8SMTPbis support. The message being sent via the MAIL command
with the UTF8SMTPbis parameter has still a chance of that the message with the UTF8SMTPbis parameter has still a chance of that the message
transmitted is not an internationalized message. An EAI-aware SMTP transmitted is not an internationalized message. An UTF8SMTPbis-
client or server that requires accurate knowledge of whether a aware SMTP client or server that requires accurate knowledge of
message is internationalized needs to parse all message header fields whether a message is internationalized needs to parse all message
and MIME header fields [RFC2045] and [RFC2047] in the message body. header fields and MIME header fields [RFC2045] and [RFC2047] in the
However, this specification does not require that the EAI-aware SMTP message body. However, this specification does not require that the
client or server inspects the message. UTF8SMTPbis-aware SMTP client or server inspects the message.
While this specification requires that EAI-aware SMTP servers support While this specification requires that UTF8SMTPbis-aware SMTP servers
the 8BITMIME extension [RFC6152] to ensure that servers have adequate support the 8BITMIME extension [RFC6152] to ensure that servers have
handling capability for 8-bit data and to avoid a number of complex adequate handling capability for 8-bit data and to avoid a number of
encoding problems, the use of internationalized email addresses complex encoding problems, the use of internationalized email
obviously does not require non-ASCII body parts in the MIME message addresses obviously does not require non-ASCII body parts in the MIME
in RFC 2045 and RFC 2047. The UTF8SMTPbis extension MAY be used with message in RFC 2045 and RFC 2047. The UTF8SMTPbis extension MAY be
the BODY=8BITMIME parameter [RFC6152] if that is appropriate given used with the BODY=8BITMIME parameter [RFC6152] if that is
the body content or, with the BODY=BINARYMIME parameter, if the SMTP appropriate given the body content or, with the BODY=BINARYMIME
server advertises BINARYMIME [RFC3030] and that is appropriate. parameter, if the SMTP server advertises BINARYMIME [RFC3030] and
that is appropriate.
3.7. Additional ESMTP Changes and Clarifications 3.7. Additional ESMTP Changes and Clarifications
The information carried in the mail transport process involves The information carried in the mail transport process involves
addresses ("mailboxes") and domain names in various contexts in addresses ("mailboxes") and domain names in various contexts in
addition to the MAIL and RCPT commands and extended alternatives to addition to the MAIL and RCPT commands and extended alternatives to
them. In general, the rule is that, when RFC 5321 specifies a them. In general, the rule is that, when RFC 5321 specifies a
mailbox, this SMTP extension requires UTF-8 form to be used for the mailbox, this SMTP extension requires UTF-8 form to be used for the
entire string; when RFC 5321 specifies a domain name, the name SHOULD entire string; when RFC 5321 specifies a domain name, the name SHOULD
be in the form of A-label if this domain name is an internationalized be in the form of A-label if this domain name is an internationalized
domain name[RFC5890]. domain name[RFC5890].
The following subsections list and discuss all of the relevant cases. The following subsections list and discuss all of the relevant cases.
3.7.1. The Initial SMTP Exchange 3.7.1. The Initial SMTP Exchange
When an SMTP connection is opened, the SMTP server sends a "greeting" When an SMTP connection is opened, the SMTP server sends a "greeting"
response consisting of the 220 reply-code and some information. The response consisting of the 220 reply-code and some information. The
SMTP client then sends the EHLO command. Since the SMTP client SMTP client then sends the EHLO command. Since the SMTP client
cannot know whether the SMTP server supports UTF8SMTPbis until after cannot know whether the SMTP server supports UTF8SMTPbis until after
it receives the response from EHLO, the EAI-aware SMTP client MUST it receives the response from EHLO, the UTF8SMTPbis-aware SMTP client
send only ASCII (LDH label or A-label [RFC5890] ) domains in the EHLO MUST send only ASCII (LDH label or A-label [RFC5890] ) domains in the
command and that, if the EAI-aware SMTP server provides domain names EHLO command and that, if the UTF8SMTPbis-aware SMTP server provides
in the EHLO response, they MUST be in the form of LDH labels or domain names in the EHLO response, they MUST be in the form of LDH
A-labels. labels or A-labels.
3.7.2. Mail eXchangers 3.7.2. Mail eXchangers
If multiple DNS MX records are used to specify multiple servers for a If multiple DNS MX records are used to specify multiple servers for a
domain in section 5 of [RFC5321], it is strongly advised that all or domain in section 5 of [RFC5321], it is strongly advised that all or
none of them SHOULD support the UTF8SMTPbis extension. Otherwise, none of them SHOULD support the UTF8SMTPbis extension. Otherwise,
surprising rejections can happen during temporary or permanent surprising rejections can happen during temporary or permanent
failures, which users might perceive as serious reliability issues. failures, which users might perceive as serious reliability issues.
3.7.3. Trace Information 3.7.3. Trace Information
The trace information <Return-path-line>, <Time-stamp-line> and their The trace information <Return-path-line>, <Time-stamp-line> and their
related rules have been defined in in section 4.4 of RFC 5321 related rules are defined in in section 4.4 of RFC 5321 [RFC5321].
[RFC5321]. This document has updated <Mailbox> and <Domain> to This document updates <Mailbox> and <Domain> to support non-ASCII
support non-ASCII characters. So Return-path-line may include the characters. When the UTF8SMTPbis extension is used, the 'Reverse-
'Reverse-path' clause where internationalized domain name with the path' clause of the Return-path-line may include an internationalized
U-label form may be used. Time-stamp-line may include the 'For' domain name that uses the U-label form; The 'Stamp' clause ot the
clause where the internationalized domain name with the U-label form Time-stamp-line may include an internationalized domain name that
may be used. uses the U-label form.
Except in the 'For' clause and 'Reverse-path' clause where If the messages that include trace fields are sent by an UTF8SMTPbis-
internationalized domain name with the U-label form MAY be used, aware SMTP client or relay server without the UTF8SMTPbis parameter
internationalized domain names in Received fields MUST be transmitted at MAIL commands, trace field values must conform to RFC 5321
in the form of A-labels. The protocol value of the 'WITH' clause regardless of the SMTP server's capability.
when this extension is used is one of the UTF8SMTPbis values
specified in the "IANA Considerations" section of this document. If the messages that include trace fields are sent by an UTF8SMTPbis-
aware SMTP client or relay server with the UTF8SMTPbis parameter at
MAIL commands, trace field values SHOULD use the U-label form for the
internationalized domain name.
The protocol value of the 'WITH' clause when this extension is used
is one of the UTF8SMTPbis values specified in the "IANA
Considerations" section of this document.
3.7.4. UTF-8 Strings in Replies 3.7.4. UTF-8 Strings in Replies
3.7.4.1. MAIL Command 3.7.4.1. MAIL Command
If an SMTP client follows this specification and sends any MAIL If an SMTP client follows this specification and sends any MAIL
commands containing the UTF8SMTPbis parameter, the EAI-aware SMTP commands containing the UTF8SMTPbis parameter, the UTF8SMTPbis-aware
server is permitted to use UTF-8 characters in the email address SMTP server is permitted to use UTF-8 characters in the email address
associated with 251 and 551 reply-codes, and the SMTP client MUST be associated with 251 and 551 reply-codes, and the SMTP client MUST be
able to accept and process them. If a given MAIL command does not able to accept and process them. If a given MAIL command does not
include the UTF8SMTPbis parameter, the EAI-aware SMTP server MUST NOT include the UTF8SMTPbis parameter, the UTF8SMTPbis-aware SMTP server
return a 251 or 551 response containing a non-ASCII mailbox. MUST NOT return a 251 or 551 response containing a non-ASCII mailbox.
Instead, it MUST transform such responses into 250 or 550 responses Instead, it MUST transform such responses into 250 or 550 responses
that do not contain non-ASCII addresses. that do not contain non-ASCII addresses.
3.7.4.2. VRFY and EXPN Commands and the UTF8SMTPbis Parameter 3.7.4.2. VRFY and EXPN Commands and the UTF8SMTPbis Parameter
If the VRFY and EXPN commands are transmitted with the parameter If the VRFY and EXPN commands are transmitted with the parameter
"UTF8SMTPbis", it indicates the SMTP client can accept UTF-8 strings "UTF8SMTPbis", it indicates the SMTP client can accept UTF-8 strings
in replies to those commands. This parameter for the VRFY and EXPN in replies to those commands. This parameter for the VRFY and EXPN
commands SHOULD only be used after the SMTP client sees the EHLO commands SHOULD only be used after the SMTP client sees the EHLO
response with the UTF8SMTPbis keyword. This allows the EAI-aware response with the UTF8SMTPbis keyword. This allows the UTF8SMTPbis-
SMTP server to use UTF-8 strings in mailbox names and full names that aware SMTP server to use UTF-8 strings in mailbox names and full
occur in replies without concern that the SMTP client might be names that occur in replies without concern that the SMTP client
confused by them. An SMTP client that conforms to this specification might be confused by them. An SMTP client that conforms to this
MUST accept and correctly process replies from the VRFY and EXPN specification MUST accept and correctly process replies from the VRFY
commands that contain UTF-8 strings. However, the EAI-aware SMTP and EXPN commands that contain UTF-8 strings. However, the
server MUST NOT use UTF-8 strings in replies if the SMTP client does UTF8SMTPbis-aware SMTP server MUST NOT use UTF-8 strings in replies
not specifically allow such replies by transmitting this parameter. if the SMTP client does not specifically allow such replies by
Most replies do not require that a mailbox name be included in the transmitting this parameter. Most replies do not require that a
returned text, and therefore UTF-8 string is not needed in them. mailbox name be included in the returned text, and therefore UTF-8
Some replies, notably those resulting from successful execution of string is not needed in them. Some replies, notably those resulting
the VRFY and EXPN commands, do include the mailbox. from successful execution of the VRFY and EXPN commands, do include
the mailbox.
VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to: VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:
vrfy = "VRFY" SP String vrfy = "VRFY" SP String
[ SP "UTF8SMTPbis" ] CRLF [ SP "UTF8SMTPbis" ] CRLF
; String may include UTF-8 characters ; String may include Non-ASCII characters
expn = "EXPN" SP String expn = "EXPN" SP String
[ SP "UTF8SMTPbis" ] CRLF [ SP "UTF8SMTPbis" ] CRLF
; String may include UTF-8 characters ; String may include Non-ASCII characters
The "UTF8SMTPbis" parameter does not use a value. If the reply to a The "UTF8SMTPbis" parameter does not use a value. If the reply to a
VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8 string, but the VERIFY (VRFY) or EXPAND (EXPN) command requires UTF-8 string, but the
SMTP client did not use the "UTF8SMTPbis" parameter, then the EAI- SMTP client did not use the "UTF8SMTPbis" parameter, then the
aware SMTP server MUST use either the reply-code 252 or 550. Reply- UTF8SMTPbis-aware SMTP server MUST use either the reply-code 252 or
code 252, defined in [RFC5321], means "Cannot VRFY user, but will 550. Reply-code 252, defined in [RFC5321], means "Cannot VRFY user,
accept the message and attempt the delivery". Reply-code 550, also but will accept the message and attempt the delivery". Reply-code
defined in [RFC5321], means "Requested action not taken: mailbox 550, also defined in [RFC5321], means "Requested action not taken:
unavailable". When the EAI-aware SMTP server supports enhanced mail mailbox unavailable". When the UTF8SMTPbis-aware SMTP server
system status codes [RFC3463], the enhanced reply-code as specified supports enhanced mail system status codes [RFC3463], the enhanced
below is used. Using the "UTF8SMTPbis" parameter with a VERIFY reply-code as specified below is used. Using the "UTF8SMTPbis"
(VRFY) or EXPAND (EXPN) command enables UTF-8 replies for that parameter with a VERIFY (VRFY) or EXPAND (EXPN) command enables UTF-8
command only. replies for that command only.
If a normal success response (i.e., 250) is returned, the response If a normal success response (i.e., 250) is returned, the response
MAY include the full name of the user and MUST include the mailbox of MAY include the full name of the user and MUST include the mailbox of
the user. It MUST be in either of the following forms: the user. It MUST be in either of the following forms:
User Name <Mailbox> User Name <Mailbox>
; Mailbox is defined in section 3.3 of this document. ; Mailbox is defined in section 3.3 of this document.
; User Name can contain non-ASCII characters. ; User Name can contain non-ASCII characters.
Mailbox Mailbox
; Mailbox is defined in section 3.3 of this document. ; Mailbox is defined in section 3.3 of this document.
If the SMTP reply requires UTF-8 strings, but UTF-8 string is not If the SMTP reply requires UTF-8 strings, but UTF-8 string is not
allowed in the reply, and the EAI-aware SMTP server supports enhanced allowed in the reply, and the UTF8SMTPbis-aware SMTP server supports
mail system status codes [RFC3463], the enhanced reply-code is enhanced mail system status codes [RFC3463], the enhanced reply-code
"X.6.8" [RFC5248], meaning "A reply containing a UTF-8 string is is "X.6.8" [RFC5248], meaning "A reply containing a UTF-8 string is
REQUIRED to show the mailbox name, but that form of response is not REQUIRED to show the mailbox name, but that form of response is not
permitted by the SMTP client". permitted by the SMTP client".
If the SMTP client does not support the UTF8SMTPbis extension, but If the SMTP client does not support the UTF8SMTPbis extension, but
receives a UTF-8 string in a reply, it may not be able to properly receives a UTF-8 string in a reply, it may not be able to properly
report the reply to the user, and some clients might crash. report the reply to the user, and some clients might crash.
Internationalized messages in replies are only allowed in the Internationalized messages in replies are only allowed in the
commands under the situations described above. Under any other commands under the situations described above. Under any other
circumstances, UTF-8 string MUST NOT appear in the reply. circumstances, UTF-8 string MUST NOT appear in the reply.
Although UTF-8 form is needed to represent email addresses in Although UTF-8 form is needed to represent email addresses in
responses under the rules specified in this section, this extension responses under the rules specified in this section, this extension
does not permit the use of UTF-8 string for any other purposes. EAI- does not permit the use of UTF-8 string for any other purposes.
aware SMTP servers MUST NOT include non-ASCII characters in replies UTF8SMTPbis-aware SMTP servers MUST NOT include non-ASCII characters
except in the limited cases specifically permitted in this section. in replies except in the limited cases specifically permitted in this
section.
4. IANA Considerations 4. IANA Considerations
IANA is requested to add a new value "UTF8SMTPbis" to the SMTP IANA is requested to add a new value "UTF8SMTPbis" to the SMTP
Service Extension subregistry of the Mail Parameters registry, Service Extension subregistry of the Mail Parameters registry,
according to the following data: according to the following data:
+-------------+---------------------------------+-----------+ +-------------+---------------------------------+-----------+
| Keywords | Description | Reference | | Keywords | Description | Reference |
+-------------+---------------------------------+-----------+ +-------------+---------------------------------+-----------+
skipping to change at page 16, line 20 skipping to change at page 16, line 20
The SMTP commands VRFY and EXPN are sometimes used in SMTP The SMTP commands VRFY and EXPN are sometimes used in SMTP
transactions where there is no message to transfer (by tools used to transactions where there is no message to transfer (by tools used to
take automated actions in case potential spam messages are take automated actions in case potential spam messages are
identified). RFC 5321 section 3.5 and 7.3 give some detailed identified). RFC 5321 section 3.5 and 7.3 give some detailed
description of use and possible behaviours. Implementation of description of use and possible behaviours. Implementation of
internationalized addrsses can affect also logs and actions by these internationalized addrsses can affect also logs and actions by these
tools. tools.
6. Acknowledgements 6. Acknowledgements
This document revised the [RFC5336]document based on the EAI WG's This document revised the [RFC5336]document based on the Email
discussion result. Many EAI WG members did some tests and Address Internationalization (EAI) WG's discussion result. Many EAI
implementations to move this document to the Standard Track document. WG members did some tests and implementations to move this document
Significant comments and suggestions were received from Xiaodong LEE, to the Standard Track document. Significant comments and suggestions
Nai-Wen Hsu, Yangwoo KO, Yoshiro YONEYA, and other members of the JET were received from Xiaodong LEE, Nai-Wen Hsu, Yangwoo KO, Yoshiro
team and were incorporated into the specification. Additional YONEYA, and other members of the JET team and were incorporated into
important comments and suggestions, and often specific text, were the specification. Additional important comments and suggestions,
contributed by many members of the WG and design team. Those and often specific text, were contributed by many members of the WG
contributions include material from John C Klensin, Charles Lindsey, and design team. Those contributions include material from John C
Dave Crocker, Harald Tveit Alvestrand, Marcos Sanz, Chris Newman, Klensin, Charles Lindsey, Dave Crocker, Harald Tveit Alvestrand,
Martin Duerst, Edmon Chung, Tony Finch, Kari Hurtta, Randall Gellens, Marcos Sanz, Chris Newman, Martin Duerst, Edmon Chung, Tony Finch,
Frank Ellermann, Alexey Melnikov, Pete Resnick, S. Moonesamy, Soobok Kari Hurtta, Randall Gellens, Frank Ellermann, Alexey Melnikov, Pete
Lee, Shawn Steele, Alfred Hoenes, Miguel Garcia, Magnus Westerlund, Resnick, S. Moonesamy, Soobok Lee, Shawn Steele, Alfred Hoenes,
and Lars Eggert. Of course, none of the individuals are necessarily Miguel Garcia, Magnus Westerlund, and Lars Eggert. Of course, none
responsible for the combination of ideas represented here. of the individuals are necessarily responsible for the combination of
ideas represented here.
Thanks a lot to Dave Crocker for his comments and helping of ABNF Thanks a lot to Dave Crocker for his comments and helping of ABNF
refinement. refinement.
7. Change History 7. Change History
[[anchor14: RFC Editor: Please remove this section.]] [[anchor14: RFC Editor: Please remove this section.]]
7.1. draft-yao-eai-rfc5336bis: Version 00 7.1. draft-yao-eai-rfc5336bis: Version 00
skipping to change at page 18, line 11 skipping to change at page 18, line 15
7.11. draft-ietf-eai-rfc5336bis: Version 09 7.11. draft-ietf-eai-rfc5336bis: Version 09
improve the texts improve the texts
7.12. draft-ietf-eai-rfc5336bis: Version 10 7.12. draft-ietf-eai-rfc5336bis: Version 10
refine the ABNF definitions refine the ABNF definitions
improve the texts improve the texts
7.13. draft-ietf-eai-rfc5336bis: Version 11
remove the update of RFC5321 and RFC5322
change the title from "SMTP Extension for Internationalized Email
Address" to "SMTP Extension for Internationalized Email" based on
Ernie's comment
the trace field of section 3.7.3 is updated to reflect the WG's
conclusion
improve the texts
8. References 8. References
8.1. Normative References 8.1. Normative References
[ASCII] American National Standards Institute (formerly United [ASCII] American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for States of America Standards Institute), "USA Code for
Information Interchange", ANSI X3.4-1968, 1968. Information Interchange", ANSI X3.4-1968, 1968.
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033, [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
October 1996. October 1996.
skipping to change at page 19, line 18 skipping to change at page 19, line 36
I-D rfc5335bis, March 2011. I-D rfc5335bis, March 2011.
[RFC5337bis] [RFC5337bis]
Hansen, T., Ed., Newman, C., and A. Melnikov, Ed., Hansen, T., Ed., Newman, C., and A. Melnikov, Ed.,
"Internationalized Delivery Status and Disposition "Internationalized Delivery Status and Disposition
Notifications", I-D 5337bis, October 2010. Notifications", I-D 5337bis, October 2010.
[RFC5890] Klensin, J., "Internationalizing Domain Names in [RFC5890] Klensin, J., "Internationalizing Domain Names in
Applications (IDNA definitions)", RFC 5890, June 2010. Applications (IDNA definitions)", RFC 5890, June 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010.
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
Service Extension for 8-bit MIME Transport", STD 71, Service Extension for 8-bit MIME Transport", STD 71,
RFC 6152, March 2011. RFC 6152, March 2011.
8.2. Informative References 8.2. Informative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
 End of changes. 50 change blocks. 
188 lines changed or deleted 206 lines changed or added

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