draft-ietf-eai-rfc5336bis-15.txt   draft-ietf-eai-rfc5336bis-16.txt 
Network Working Group J. Yao Network Working Group J. Yao
Internet-Draft W. Mao Internet-Draft W. Mao
Obsoletes: 5336 (if approved) CNNIC Obsoletes: 5336 (if approved) CNNIC
Intended status: Standards Track October 27, 2011 Intended status: Standards Track November 10, 2011
Expires: April 29, 2012 Expires: May 13, 2012
SMTP Extension for Internationalized Email SMTP Extension for Internationalized Email
draft-ietf-eai-rfc5336bis-15.txt draft-ietf-eai-rfc5336bis-16.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. This specification replaces RFC 5336. information. This specification replaces RFC 5336.
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 33 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 April 29, 2012. This Internet-Draft will expire on May 13, 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 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Changes Made to Other Specifications . . . . . . . . . . . 4 1.2. Changes Made to Other Specifications . . . . . . . . . . . 5
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 5 3. Mail Transport-Level Protocol . . . . . . . . . . . . . . . . 5
3.1. Framework for the Internationalization Extension . . . . . 5 3.1. Framework for the Internationalization Extension . . . . . 5
3.2. The UTF8SMTPbis Extension . . . . . . . . . . . . . . . . 6 3.2. The UTF8SMTPbis Extension . . . . . . . . . . . . . . . . 6
3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7 3.3. Extended Mailbox Address Syntax . . . . . . . . . . . . . 7
3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 9 3.4. MAIL Command Parameter Usage . . . . . . . . . . . . . . . 9
3.5. Non-ASCII addresses and Reply-codes . . . . . . . . . . . 9 3.5. Non-ASCII addresses and Reply-codes . . . . . . . . . . . 9
3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 10 3.6. Body Parts and SMTP Extensions . . . . . . . . . . . . . . 10
3.7. Additional ESMTP Changes and Clarifications . . . . . . . 10 3.7. Additional ESMTP Changes and Clarifications . . . . . . . 11
3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 11 3.7.1. The Initial SMTP Exchange . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . 12 3.7.4. UTF-8 Strings in Replies . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4.1. SMTP Service Extensions Registry . . . . . . . . . . . . . 13 4.1. SMTP Service Extensions Registry . . . . . . . . . . . . . 14
4.2. SMTP Enhanced Status Code Registry . . . . . . . . . . . . 14 4.2. SMTP Enhanced Status Code Registry . . . . . . . . . . . . 14
4.3. WITH protocol types sub-registry of the Mail 4.3. WITH protocol types sub-registry of the Mail
Transmission Types Registry . . . . . . . . . . . . . . . 15 Transmission Types Registry . . . . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 17 7.1. draft-yao-eai-rfc5336bis: Version 00 . . . . . . . . . . . 17
7.2. draft-ietf-eai-rfc5336bis: Version 00 . . . . . . . . . . 17 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 . . . . . . . . . . 18
7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 17 7.6. draft-ietf-eai-rfc5336bis: Version 04 . . . . . . . . . . 18
7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 18 7.7. draft-ietf-eai-rfc5336bis: Version 05 . . . . . . . . . . 18
7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 18 7.8. draft-ietf-eai-rfc5336bis: Version 06 . . . . . . . . . . 18
7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 18 7.9. draft-ietf-eai-rfc5336bis: Version 07 . . . . . . . . . . 18
7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 18 7.10. draft-ietf-eai-rfc5336bis: Version 08 . . . . . . . . . . 18
7.11. draft-ietf-eai-rfc5336bis: Version 09 . . . . . . . . . . 18 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 7.13. draft-ietf-eai-rfc5336bis: Version 11 . . . . . . . . . . 18
7.14. draft-ietf-eai-rfc5336bis: Version 12 . . . . . . . . . . 19 7.14. draft-ietf-eai-rfc5336bis: Version 12 . . . . . . . . . . 19
7.15. draft-ietf-eai-rfc5336bis: Version 13 . . . . . . . . . . 19 7.15. draft-ietf-eai-rfc5336bis: Version 13 . . . . . . . . . . 19
7.16. draft-ietf-eai-rfc5336bis: Version 14 . . . . . . . . . . 19 7.16. draft-ietf-eai-rfc5336bis: Version 14 . . . . . . . . . . 19
7.17. draft-ietf-eai-rfc5336bis: Version 15 . . . . . . . . . . 19 7.17. draft-ietf-eai-rfc5336bis: Version 15 . . . . . . . . . . 19
7.18. draft-ietf-eai-rfc5336bis: Version 16 . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The document defines a Simple Mail Transfer Protocol [RFC5321] The document defines a Simple Mail Transfer Protocol [RFC5321]
extension so servers can advertise the ability to accept and process extension so servers can advertise the ability to accept and process
internationalized email addresses (see section 1.1), and internationalized email addresses (see section 1.1), and
internationalized email headers [RFC5335bis]. internationalized email headers [RFC5335bis].
An extended overview of the extension model for internationalized An extended overview of the extension model for internationalized
skipping to change at page 4, line 34 skipping to change at page 4, line 34
keyword should be substituted here. This paragraph should be removed keyword should be substituted here. This paragraph should be removed
before RFC publication.]] before RFC publication.]]
1.1. Terminology 1.1. Terminology
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The terms "UTF-8 string" or "UTF-8 character" are used to refer to The terms "UTF-8 string" or "UTF-8 character" are used to refer to
Unicode characters encoded in UTF-8. All other specialized terms Unicode characters, which may or may not be members of the ASCII
used in this specification are defined in the framework document or subset, encoded in UTF-8. All other specialized terms used in this
in the base Internet email specifications. In particular, the terms specification are defined in the framework document or in the base
"ASCII address", "internationalized email address", "non-ASCII Internet email specifications. In particular, the terms "ASCII
address", "UTF8SMTPbis", "internationalized message", and "message" address", "internationalized email address", "non-ASCII address",
are used in this document according to the definitions in the "UTF8SMTPbis", "internationalized message", and "message" are used in
framework document. this document according to the definitions in the 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 are identified in Section 3.3 as being
under the same names. defined (under the same names) in [RFC5234], [RFC5321], [RFC5890] or
[RFC5335bis].
1.2. Changes Made to Other Specifications 1.2. Changes Made to Other Specifications
This specification extends some syntax rules defined in RFC 5321 and This specification extends some syntax rules defined in RFC 5321 and
permits internationalized email addresses in the envelope, but it permits internationalized email addresses in the envelope, but it
does not modify RFC 5321. It permits data formats defined in does not modify RFC 5321. It permits data formats defined in
[RFC5335bis], but it does not modify RFC 5322. It does require that [RFC5335bis], but it does not modify RFC 5322. It does require that
the 8BITMIME extension [RFC6152] be announced by the UTF8SMTPbis- the 8BITMIME extension [RFC6152] be announced by the UTF8SMTPbis-
aware SMTP server and used with "BODY=8BMITMIME" by the UTF8SMTPbis- aware SMTP server and used with "BODY=8BMITMIME" by the UTF8SMTPbis-
aware SMTP client, but it does not modify the 8BITMIME specification aware SMTP client, but it does not modify the 8BITMIME specification
in any way. in any way.
This specification replaces an earlier, experimental, approach to the This specification replaces an earlier, experimental, approach to the
same problem [RFC5336]. Section 6 of [RFC4952bis] describes the same problem [RFC5336]. Section 6 of [RFC4952bis] describes the
changes in approach between this specification and [RFC5336]. The changes in approach between [RFC5336] and this specification. Anyone
changes between them are significant after the experimental trying to convert an implementation from the experimental
experience. Readers need to review both documents carefully to specification to the specification in this document will need to
change implementation from the experimental specification to this review those changes carefully.
standard specification.
2. Overview of Operation 2. Overview of Operation
This document specifies an element of the email internationalization This document specifies an element of the email internationalization
work, specifically the definition of an SMTP extension for work, specifically the definition of an SMTP extension for
internationalized email. The extension is identified with the token internationalized email. The extension is identified with the token
"UTF8SMTPbis". "UTF8SMTPbis".
The internationalized email headers specification [RFC5335bis] The internationalized email headers specification [RFC5335bis]
provides the details of email header features enabled by this provides the details of email header features enabled by this
skipping to change at page 6, line 37 skipping to change at page 6, line 41
WITH keywords as appropriate [RFC3848]. WITH keywords as appropriate [RFC3848].
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 name to be looked up in the DNS MUST follow RFC 5890 domain name to be looked up in the DNS MUST conform to and be
[RFC5890]. When doing lookups, the UTF8SMTPbis-aware SMTP client or processed as specified for IDNA [RFC5890]. When doing lookups, the
server MUST either use a Unicode aware DNS library, or transform the UTF8SMTPbis-aware SMTP client or server MUST either use a Unicode
internationalized domain name to the form of A-label as described in aware DNS library, or transform the internationalized domain name to
[RFC5890]. the form of A-label as described 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 UTF8SMTPbis-aware SMTP client MUST NOT transmit an the UTF8SMTPbis-aware SMTP client MUST NOT transmit an
internationalized email address and MUST NOT transmit a mail message internationalized email address and MUST NOT transmit a mail message
containing internationalized mail headers as described in containing internationalized mail headers as described in
[RFC5335bis] at any level within its MIME structure [RFC2045]. (For [RFC5335bis] at any level within its MIME structure [RFC2045]. (For
this paragraph, the internationalized domain name in the form of this paragraph, the internationalized domain name in the form of
A-labels as specified in IDNA definitions [RFC5890] is not considered A-labels as specified in IDNA definitions [RFC5890] is not considered
skipping to change at page 7, line 25 skipping to change at page 7, line 28
support the extension, it MUST make one of the following three support the extension, it MUST make one of the following three
choices and the priority order is 1, 2 and 3. 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 specified in RFC 5321 [RFC5321], RFC 3464 [RFC3464], and the
internationalized delivery status and disposition notifications internationalized delivery status and disposition notifications
specification [RFC5337bis]. specification [RFC5337bis].
2. If and only if the UTF8SMTPbis-aware SMTP client (sender) is a 2. If and only if the UTF8SMTPbis-aware SMTP client (sender) is a
Message Submission Agent ("MSA") [RFC4409] [RFC5598], it may Message Submission Agent ("MSA") [RFC4409] [RFC5598], it MAY
choose its own way to deal with this scenario according to the choose its own way to deal with this scenario according to the
provisions of [RFC4409] or its future versions. But the detailed provisions of [RFC4409] or its future versions. But the detailed
specification of this process and its results are outside the specification of this process and its results are outside the
scope of this document. 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 UTF8SMTPbis-aware RFC 5321) or using other means available to the UTF8SMTPbis-aware
SMTP client. SMTP client.
skipping to change at page 8, line 28 skipping to change at page 8, line 30
updated directly or indirectly by this document: updated directly or indirectly by this document:
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 imported from RFC 5335bis, section The following ABNF rule will be imported from RFC 5335bis, section
4.1 directly: 3.1 directly:
o <UTF8-non-ascii> o <UTF8-non-ascii>
The following ABNF rule will be imported 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 imported 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>
skipping to change at page 11, line 22 skipping to change at page 11, line 36
MUST send only ASCII (LDH label or A-label [RFC5890] ) domains in the MUST send only ASCII (LDH label or A-label [RFC5890] ) domains in the
EHLO command and that, if the UTF8SMTPbis-aware SMTP server provides EHLO command and that, if the UTF8SMTPbis-aware SMTP server provides
domain names in the EHLO response, they MUST be in the form of LDH domain names in the EHLO response, they MUST be in the form of LDH
labels or 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 unexpected 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 are defined in in section 4.4 of RFC 5321 [RFC5321]. related rules are defined in in section 4.4 of RFC 5321 [RFC5321].
This document updates <Mailbox> and <Domain> to support non-ASCII This document updates <Mailbox> and <Domain> to support non-ASCII
characters. When the UTF8SMTPbis extension is used, the 'Reverse- characters. When the UTF8SMTPbis extension is used, the 'Reverse-
path' clause of the Return-path-line may include an internationalized path' clause of the Return-path-line may include an internationalized
domain name that uses the U-label form; The 'Stamp' clause of the domain name that uses the U-label form; The 'Stamp' clause of the
skipping to change at page 19, line 27 skipping to change at page 19, line 33
7.16. draft-ietf-eai-rfc5336bis: Version 14 7.16. draft-ietf-eai-rfc5336bis: Version 14
improve the texts improve the texts
7.17. draft-ietf-eai-rfc5336bis: Version 15 7.17. draft-ietf-eai-rfc5336bis: Version 15
improve the texts improve the texts
updates based on IESG members' comments updates based on IESG members' comments
7.18. draft-ietf-eai-rfc5336bis: Version 16
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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
 End of changes. 19 change blocks. 
34 lines changed or deleted 40 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/