draft-ietf-eai-dsn-03.txt   draft-ietf-eai-dsn-04.txt 
Network Working Group C. Newman Network Working Group C. Newman
Internet-Draft Sun Microsystems Internet-Draft Sun Microsystems
Updates: 3461,3464,3798 A. Melnikov, Ed. Updates: 3461,3464,3798 A. Melnikov, Ed.
(if approved) Isode Ltd (if approved) Isode Ltd
Intended status: Experimental September 2, 2007 Intended status: Experimental September 28, 2007
Expires: March 5, 2008 Expires: March 31, 2008
International Delivery and Disposition Notifications International Delivery and Disposition Notifications
draft-ietf-eai-dsn-03.txt draft-ietf-eai-dsn-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 5, 2008. This Internet-Draft will expire on March 31, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Delivery status notifications (DSNs) are critical to the correct Delivery status notifications (DSNs) are critical to the correct
operation of an email system. However, the existing draft standard operation of an email system. However, the existing draft standard
is presently limited to US-ASCII text in the machine readable is presently limited to US-ASCII text in the machine readable
skipping to change at page 2, line 18 skipping to change at page 2, line 18
This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. This document experimentally extends RFC 3461, RFC 3464 and RFC 3798.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document . . . . . . . . . . . . . . 3 2. Conventions Used in this Document . . . . . . . . . . . . . . 3
3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3 3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3
4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6 4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6
4.1. Additional requirements on SMTP servers . . . . . . . . . 8 4.1. Additional requirements on SMTP servers . . . . . . . . . 8
5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 8 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 9 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 10
6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 10 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 11
6.3. message/global-headers . . . . . . . . . . . . . . . . . . 11 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 11
6.4. message/global-delivery-status . . . . . . . . . . . . . . 12 6.4. message/global-delivery-status . . . . . . . . . . . . . . 12
6.5. message/global-disposition-notification . . . . . . . . . 13 6.5. message/global-disposition-notification . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. Changes from -02 . . . . . . . . . . . . . . . . . . 17
Appendix C. Changes from -02 . . . . . . . . . . . . . . . . . . 17 Appendix C. Changes from -01 . . . . . . . . . . . . . . . . . . 17
Appendix D. Changes from -01 . . . . . . . . . . . . . . . . . . 17 Appendix D. Changes from -00 . . . . . . . . . . . . . . . . . . 17
Appendix E. Changes from -00 . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
When an email message is transmitted using the UTF8SMTP When an email message is transmitted using the UTF8SMTP
[I-D.ietf-eai-smtpext] extension and Internationalized Email Headers [I-D.ietf-eai-smtpext] extension and Internationalized Email Headers
[I-D.ietf-eai-utf8headers], it is sometimes necessary to return that [I-D.ietf-eai-utf8headers], it is sometimes necessary to return that
message or generate a Message Disposition Notification [RFC3798] message or generate a Message Disposition Notification [RFC3798]
(MDN). As a message sent to multiple recipients can generate a (MDN). As a message sent to multiple recipients can generate a
status and disposition notification for each recipient, it is helpful status and disposition notification for each recipient, it is helpful
if a client can correlate these returns based on the recipient if a client can correlate these returns based on the recipient
address it provided, thus preservation of the original recipient is address it provided, thus preservation of the original recipient is
important. This specification describes how to preserve the original important. This specification describes how to preserve the original
recipient and updates the MDN and DSN formats to support the new recipient and updates the MDN and DSN formats to support the new
address types. address types.
2. Conventions Used in this Document 2. Conventions Used in this Document
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
in this document are to be interpreted as defined in "Key words for "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
use in RFCs to Indicate Requirement Levels" [RFC2119]. document are to be interpreted as described in [RFC2119].
The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC4234] The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC4234]
notation including the core rules defined in Appendix B of RFC 4234 notation including the core rules defined in Appendix B of RFC 4234
and the rules in section 4 of RFC 3629. and the UTF-8 syntax rules in section 4 of [RFC3629].
3. UTF-8 Address Type 3. UTF-8 Address Type
An Extensible Message Format for Delivery Status Notifications An Extensible Message Format for Delivery Status Notifications
[RFC3464] defines the concept of an address type. The address format [RFC3464] defines the concept of an address type. The address format
introduced in Internationalized Email Headers introduced in Internationalized Email Headers
[I-D.ietf-eai-utf8headers] is a new address type. The syntax for the [I-D.ietf-eai-utf8headers] is a new address type. The syntax for the
new address type in the context of status notifications follows: new address type in the context of status notifications follows:
An SMTP [RFC2821] server which advertises both the UTF8SMTP extension An SMTP [RFC2821] server which advertises both the UTF8SMTP extension
skipping to change at page 4, line 6 skipping to change at page 4, line 6
This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext
and utf-8-address. The first 2 forms are 7-bit safe. and utf-8-address. The first 2 forms are 7-bit safe.
The utf-8-address form is only suitable for use in newly defined The utf-8-address form is only suitable for use in newly defined
protocols capable of native representation of 8-bit characters. I.e. protocols capable of native representation of 8-bit characters. I.e.
the utf-8-address form MUST NOT be used in the ORCPT parameter when the utf-8-address form MUST NOT be used in the ORCPT parameter when
the SMTP server doesn't advertise support for UTF8SMTP or the SMTP the SMTP server doesn't advertise support for UTF8SMTP or the SMTP
server supports UTF8SMTP, but the address contains US-ASCII server supports UTF8SMTP, but the address contains US-ASCII
characters not permitted in the ORCPT parameter (e.g. the ORCPT characters not permitted in the ORCPT parameter (e.g. the ORCPT
parameter forbids unencoded SP and =); or in a 7-bit transport parameter forbids unencoded SP and the = character); or in a 7-bit
environment including a message/delivery-status Original-Recipient or transport environment including a message/delivery-status Original-
Final-Recipient field. In the former case the utf-8-addr-xtext form Recipient or Final-Recipient field. In the former case the utf-8-
(see below) MUST be used instead, in the latter case the utf-8-addr- addr-xtext form (see below) MUST be used instead, in the latter case
unitext form MUST be used. The utf-8-address form MAY be used in the the utf-8-addr-unitext form MUST be used. The utf-8-address form MAY
ORCPT parameter when the SMTP server also advertises support for be used in the ORCPT parameter when the SMTP server also advertises
UTF8SMTP and the address doesn't contains any US-ASCII characters not support for UTF8SMTP and the address doesn't contains any US-ASCII
permitted in the ORCPT parameter. It SHOULD be used in a message/ characters not permitted in the ORCPT parameter. It SHOULD be used
global-delivery-status Original-Recipient or Final-Recipient DSN in a message/global-delivery-status Original-Recipient or Final-
field; or in an Original-Recipient header field [RFC3798] if the Recipient DSN field; or in an Original-Recipient header field
message is a UTF8SMTP message. [RFC3798] if the message is a UTF8SMTP message.
In addition, the utf-8-addr-unitext form can be used anywhere where In addition, the utf-8-addr-unitext form can be used anywhere where
the utf-8-address form is allowed. the utf-8-address form is allowed.
When using in the ORCPT parameter, the UTF-8 address type requires When using in the ORCPT parameter, the UTF-8 address type requires
that US-ASCII CTLs, SP, \, + and = be encoded using xtext encoding as that US-ASCII CTLs, SP, \, + and = be encoded using xtext encoding as
described in [RFC3461]. This is described by the utf-8-addr-xtext described in [RFC3461]. This is described by the utf-8-addr-xtext
form in the ABNF below. Unicode characters MAY be included in a form in the ABNF below. Unicode characters MAY be included in a
UTF-8 address type using a "\x{HEXPOINT}" syntax, where HEXPOINT is 2 UTF-8 address type using a "\x{HEXPOINT}" syntax
to 6 hexadecimal digits. When sending data to a UTF8SMTP capable (EmbeddedUnicodeChar), where HEXPOINT is 2 to 6 hexadecimal digits.
server, native UTF-8 characters SHOULD be used instead of the When sending data to a UTF8SMTP capable server, native UTF-8
QMIDCHAR and QHIGHCHAR encodings described below. When sending data characters SHOULD be used instead of the EmbeddedUnicodeChar syntax
to an SMTP server which does not advertise UTF8SMTP, then the described in details below. When sending data to an SMTP server
QMIDCHAR and QHIGHCHAR encodings MUST be used instead of UTF-8. which does not advertise UTF8SMTP, then the EmbeddedUnicodeChar
syntax MUST be used instead of UTF-8.
When the ORCPT parameter is placed in a message/ When the ORCPT parameter is placed in a message/
global-delivery-status Original-Recipient field, the utf-8-addr-xtext global-delivery-status Original-Recipient field, the utf-8-addr-xtext
form of the UTF-8 address type SHOULD be converted to the 'utf-8- form of the UTF-8 address type SHOULD be converted to the 'utf-8-
address' form (see the ABNF below) by removing all xtext encoding address' form (see the ABNF below) by removing all xtext encoding
first (which will result in the 'utf-8-addr-unitext' form), followed first (which will result in the 'utf-8-addr-unitext' form), followed
by removal of the 'unitext' encoding. However, if an address is by removal of the 'unitext' encoding. However, if an address is
labeled with the UTF-8 address type but does not conform to utf-8 labeled with the UTF-8 address type but does not conform to utf-8
syntax, then it MUST be copied into the message/ syntax, then it MUST be copied into the message/
global-delivery-status field without alteration. global-delivery-status field without alteration.
skipping to change at page 5, line 29 skipping to change at page 5, line 29
; When xtext encoding is removed, ; When xtext encoding is removed,
; the syntax MUST conform to ; the syntax MUST conform to
; 'utf-8-addr-unitext'. ; 'utf-8-addr-unitext'.
utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar)
; MUST follow 'utf-8-address' ABNF when ; MUST follow 'utf-8-address' ABNF when
; dequoted ; dequoted
QUCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e / QUCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e /
UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 / UTF8-3 / UTF8-4
; Printable except CTLs, SP, '\', '+' and '=' ; US-ASCII printable characters except
; CTLs, SP, '\', '+' and '=', plus
; other Unicode characters in UTF-8
EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}"
; starts with "\x" ; starts with "\x"
HEXPOINT = "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms HEXPOINT = "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms
( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms
( NZDHEXDIG 3(HEXDIG) ) / ( NZDHEXDIG 3(HEXDIG) ) /
( "D" %x30-37 2(HEXDIG) ) / ( "D" %x30-37 2(HEXDIG) ) /
; 4 digit forms excluding surrogate ; 4 digit forms excluding surrogate
( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms
skipping to change at page 6, line 13 skipping to change at page 6, line 13
; HEXDIG excluding "0" and "D" ; HEXDIG excluding "0" and "D"
4. UTF-8 Delivery Status Notifications 4. UTF-8 Delivery Status Notifications
A traditional delivery status notification [RFC3464] comes in a A traditional delivery status notification [RFC3464] comes in a
three-part multipart/report [RFC3462] container, where the first part three-part multipart/report [RFC3462] container, where the first part
is human readable text describing the error, the second part is a is human readable text describing the error, the second part is a
7-bit-only message/delivery-status and the optional third part is 7-bit-only message/delivery-status and the optional third part is
used for content (message/rfc822) or header (text/rfc822-headers) used for content (message/rfc822) or header (text/rfc822-headers)
return. As the present DSN format does not permit returning of return. As the present DSN format does not permit returning of
undeliverable UTF8SMTP message, three new media types are needed. undeliverable UTF8SMTP messages, three new media types are needed.
The first type, message/global-delivery-status has the syntax of The first type, message/global-delivery-status has the syntax of
message/delivery-status with three modifications. First, the charset message/delivery-status with three modifications. First, the charset
for message/global-delivery-status is UTF-8 and thus any field MAY for message/global-delivery-status is UTF-8 and thus any field MAY
contain UTF-8 characters when appropriate (see the ABNF below). In contain UTF-8 characters when appropriate (see the ABNF below). In
particular, the Diagnostic-Code field MAY contain UTF-8 as described particular, the Diagnostic-Code field MAY contain UTF-8 as described
in UTF8SMTP [I-D.ietf-eai-smtpext]; the Diagnostic-Code field SHOULD in UTF8SMTP [I-D.ietf-eai-smtpext]; the Diagnostic-Code field SHOULD
be in i-default language [LANGTAGS]. Second, systems generating a be in i-default language [DEFAULTLANG]. Second, systems generating a
message/global-delivery-status body part SHOULD use the utf-8-address message/global-delivery-status body part SHOULD use the utf-8-address
form of the UTF-8 address type for all addresses containing form of the UTF-8 address type for all addresses containing
characters outside the US-ASCII repertoire. These systems SHOULD up- characters outside the US-ASCII repertoire. These systems SHOULD up-
convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a
UTF-8 address type in the ORCPT parameter to the utf-8-address form UTF-8 address type in the ORCPT parameter to the utf-8-address form
of a UTF-8 address type in the Original-Recipient field. Third, a of a UTF-8 address type in the Original-Recipient field. Third, a
new optional field called Localized-Diagnostic is added. Each new optional field called Localized-Diagnostic is added. Each
instance includes a language tag [LANGTAGS] and contains text in the instance includes a language tag [LANGTAGS] and contains text in the
specified language. This is equivalent to the text part of the specified language. This is equivalent to the text part of the
Diagnostic-Code field. All instances of Localized-Diagnostic MUST Diagnostic-Code field. All instances of Localized-Diagnostic MUST
skipping to change at page 7, line 50 skipping to change at page 7, line 50
extension-field =/ extension-field-name ":" *utf8-text extension-field =/ extension-field-name ":" *utf8-text
utf8-text = %d1-9 / ; Any Unicode character except for NUL, utf8-text = %d1-9 / ; Any Unicode character except for NUL,
%d11 / ; CR and LF, encoded in UTF-8 %d11 / ; CR and LF, encoded in UTF-8
%d12 / %d12 /
%d14-127 / %d14-127 /
UTFMB UTFMB
UTFMB = UTF2 / UTF3 / UTF4 UTFMB = UTF2 / UTF3 / UTF4
The second type, used for content return, is message/global which is The second type, used for returning the content, is message/global
similar to message/rfc822, except it contains a message with UTF-8 which is similar to message/rfc822, except it contains a message with
headers. This media type is described in [I-D.ietf-eai-utf8headers]. UTF-8 headers. This media type is described in
[I-D.ietf-eai-utf8headers].
The third type, used for header return, is message/global-headers and The third type, used for returning the headers, is message/
contains only the UTF-8 headers of a message (all lines prior to the global-headers and contains only the UTF-8 header fields of a message
first blank line in a UTF8SMTP message). Unlike message/global, this (all lines prior to the first blank line in a UTF8SMTP message).
body part provides no difficulties for present infrastructure. Unlike message/global, this body part provides no difficulties for
present infrastructure.
Note, that as far as multipart/report [RFC3462] container is Note, that as far as multipart/report [RFC3462] container is
concerned, message/global-delivery-status, message/global and concerned, message/global-delivery-status, message/global and
message/global-headers MUST be treated as equivalent to message/ message/global-headers MUST be treated as equivalent to message/
delivery-status, message/rfc822 and text/rfc822-headers. I.e. delivery-status, message/rfc822 and text/rfc822-headers. I.e.
implementations processing multipart/report MUST expect any implementations processing multipart/report MUST expect any
combinations of the 6 MIME types mentioned above inside a multipart/ combinations of the 6 MIME types mentioned above inside a multipart/
report MIME type. report MIME type.
All three new types will typically use the "8bit" Content-Transfer- All three new types will typically use the "8bit" Content-Transfer-
skipping to change at page 8, line 47 skipping to change at page 8, line 49
corresponding multipart/report. If the return path SMTP server does corresponding multipart/report. If the return path SMTP server does
not support UTF8SMTP, then the undeliverable body part and headers not support UTF8SMTP, then the undeliverable body part and headers
MUST be encoded using a 7 bit Content-Transfer-Encoding such as MUST be encoded using a 7 bit Content-Transfer-Encoding such as
base64 or quoted-printable [RFC2045], as detailed in Section 4. base64 or quoted-printable [RFC2045], as detailed in Section 4.
Otherwise 8bit Content-Transfer-Encoding can be used. Otherwise 8bit Content-Transfer-Encoding can be used.
5. UTF-8 Message Disposition Notifications 5. UTF-8 Message Disposition Notifications
Message Disposition Notifications [RFC3798] have a similar design and Message Disposition Notifications [RFC3798] have a similar design and
structure to DSNs. As a result, they use the same basic return structure to DSNs. As a result, they use the same basic return
format. When generating a MDN for a UTF-8 header message, content or format. When generating a MDN for a UTF-8 header message, the third
header return is the same as for DSNs. The second part of the part of the multipart/report contains the returned content (message/
multipart/report uses a new media type, message/ global) or header (message/global-headers), same as for DSNs. The
second part of the multipart/report uses a new media type, message/
global-disposition-notification, which has the syntax of message/ global-disposition-notification, which has the syntax of message/
disposition-notification with two modifications. First, the charset disposition-notification with two modifications. First, the charset
for message/global-disposition-notification is UTF-8 and thus any for message/global-disposition-notification is UTF-8 and thus any
field MAY contain UTF-8 characters when appropriate (see the ABNF field MAY contain UTF-8 characters when appropriate (see the ABNF
below). (In particular, the failure-field, the error-field and the below). (In particular, the failure-field, the error-field and the
warning-field MAY contain UTF-8. These fields SHOULD be in i-default warning-field MAY contain UTF-8. These fields SHOULD be in i-default
language [LANGTAGS].) Second, systems generating a message/ language [DEFAULTLANG].) Second, systems generating a message/
global-disposition-notification body part (typically a mail user global-disposition-notification body part (typically a mail user
agent) SHOULD use the UTF-8 address type for all addresses containing agent) SHOULD use the UTF-8 address type for all addresses containing
characters outside the US-ASCII repertoire. characters outside the US-ASCII repertoire.
The MDN specification also defines the Original-Recipient header The MDN specification also defines the Original-Recipient header
field which is added with a copy of the contents of ORCPT at delivery field which is added with a copy of the contents of ORCPT at delivery
time. When generating an Original-Recipient header field, a delivery time. When generating an Original-Recipient header field, a delivery
agent writing a UTF-8 header message in native format SHOULD convert agent writing a UTF-8 header message in native format SHOULD convert
the utf-8-addr-xtext or the utf-8-addr-unitext form of a UTF-8 the utf-8-addr-xtext or the utf-8-addr-unitext form of a UTF-8
address type in the ORCPT parameter to the corresponding utf-8- address type in the ORCPT parameter to the corresponding utf-8-
skipping to change at page 10, line 21 skipping to change at page 10, line 33
(c) If addresses of this type are not composed entirely of graphic (c) If addresses of this type are not composed entirely of graphic
characters from the US-ASCII repertoire, a specification for how they characters from the US-ASCII repertoire, a specification for how they
are to be encoded as graphic US-ASCII characters in a DSN Original- are to be encoded as graphic US-ASCII characters in a DSN Original-
Recipient or Final-Recipient DSN field. Recipient or Final-Recipient DSN field.
This address type has 3 forms (as defined in Section 3): utf-8-addr- This address type has 3 forms (as defined in Section 3): utf-8-addr-
xtext, utf-8-addr-unitext and utf-8-address. The first 2 forms are xtext, utf-8-addr-unitext and utf-8-address. The first 2 forms are
7-bit safe. 7-bit safe.
The utf-8-address form MUST NOT be used in the ORCPT parameter when The utf-8-address form MUST NOT be used
the SMTP server doesn't advertise support for UTF8SMTP or the SMTP
server supports UTF8SMTP, but the address contains US-ASCII 1. in the ORCPT parameter when the SMTP server doesn't advertise
characters not permitted in the ORCPT parameter (e.g. the ORCPT support for UTF8SMTP
parameter forbids SP and =); or in a 7-bit transport environment
including a message/delivery-status Original-Recipient or Final- 2. or the SMTP server supports UTF8SMTP, but the address contains
Recipient field. The utf-8-addr-xtext form MUST be used instead in US-ASCII characters not permitted in the ORCPT parameter (e.g.
the former case, the utf-8-addr-unitext form MUST be used in the the ORCPT parameter forbids SP and the = characters);
latter case. The utf-8-address form MAY be used in the ORCPT
parameter when the SMTP server also advertises support for UTF8SMTP 3. or in a 7-bit transport environment including a message/
and the address doesn't contains any US-ASCII characters not delivery-status Original-Recipient or Final-Recipient field.
permitted in the ORCPT parameter; in a message/global-delivery-status
Original-Recipient or Final-Recipient DSN field; or in an Original- The utf-8-addr-xtext form MUST be used instead in the first case, the
Recipient header field [RFC3798] if the message is a UTF8SMTP utf-8-addr-unitext form MUST be used in the other two cases. The
message. utf-8-address form MAY be used in the ORCPT parameter when the SMTP
server also advertises support for UTF8SMTP and the address doesn't
contains any US-ASCII characters not permitted in the ORCPT
parameter; in a message/global-delivery-status Original-Recipient or
Final-Recipient DSN field; or in an Original-Recipient header field
[RFC3798] if the message is a UTF8SMTP message.
In addition, the utf-8-addr-unitext form can be used anywhere where In addition, the utf-8-addr-unitext form can be used anywhere where
the utf-8-address form is allowed. the utf-8-address form is allowed.
6.2. Update to 'smtp' Diagnostic Type Registration 6.2. Update to 'smtp' Diagnostic Type Registration
The mail diagnostic type registry was created by RFC 3464. The The mail diagnostic type registry was created by RFC 3464. The
registration for the 'smtp' diagnostic type should be updated to registration for the 'smtp' diagnostic type should be updated to
reference RFC XXXX in addition to RFC 3464. reference RFC XXXX in addition to RFC 3464.
skipping to change at page 16, line 4 skipping to change at page 16, line 20
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004. Notification", RFC 3798, May 2004.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[I-D.ietf-eai-utf8headers] [I-D.ietf-eai-utf8headers]
Yang, A., "Internationalized Email Headers", Yang, A., "Internationalized Email Headers",
draft-ietf-eai-utf8headers-06 (work in progress), draft-ietf-eai-utf8headers-07 (work in progress),
April 2007. April 2007.
[I-D.ietf-eai-smtpext] [I-D.ietf-eai-smtpext]
Yao, J. and W. Mao, "SMTP extension for internationalized Yao, J. and W. Mao, "SMTP extension for internationalized
email address", draft-ietf-eai-smtpext-07 (work in email address", draft-ietf-eai-smtpext-08 (work in
progress), April 2007. progress), April 2007.
[I-D.ietf-eai-downgrade]
Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for
Email Address Internationalization (EAI)",
draft-ietf-eai-downgrade-04 (work in progress), Mar 2007.
[LANGTAGS] [LANGTAGS]
Phillips, A. and M. Davis, "Tags for Identifying Phillips, A. and M. Davis, "Tags for Identifying
Languages", RFC 4646, September 2006. Languages", RFC 4646, September 2006.
[DEFAULTLANG]
Alvestrand, H., "IETF Policy on Character Sets and
Languages", RFC 2277, January 1998.
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.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. November 1996.
[I-D.ietf-eai-downgrade]
Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for
Email Address Internationalization (EAI)",
draft-ietf-eai-downgrade-04 (work in progress), Mar 2007.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Many thanks for input provided by Pete Resnick, James Galvin, Ned Many thanks for input provided by Pete Resnick, James Galvin, Ned
Freed, John Klensin and members of the EAI WG to help solidify this Freed, John Klensin, Harald Alvestrand, Frank Ellermann and members
proposal. of the EAI WG to help solidify this proposal.
Appendix B. Open Issues
Suggestion to change the utf-8-addr format from \-encoded Unicode to
\-encoded UTF-8 as used in URIs.
Use a single syntax for I18N addresses in ORCPT/DSN instead of two
(Chris)
Potential issue: an SMTP server can't deliver an EAI DSN to the next
hop - need to use a 7bit encoding, downgrade or discard? Need to
describe choices.
Tracker issue #1485: UTF8HDR 4.6/DSN: Choice of body part for
transport of UTF8SMTP messages
Tracker issue #1483: SMTPEXT 2.7: Non-ASCII in response texts
Appendix C. Changes from -02 Appendix B. Changes from -02
Make the space between UTF-8 and ASCII address mandatory. Make the space between UTF-8 and ASCII address mandatory.
Appendix D. Changes from -01 Appendix C. Changes from -01
Cleaned up and tightened ABNF, in particular HEXPOINT. Cleaned up and tightened ABNF, in particular HEXPOINT.
Extended DSN report syntax to allow for localized version of Extended DSN report syntax to allow for localized version of
diagnostic-code-field. diagnostic-code-field.
Added ABNF for the EAI DSN and EAI MDN. Added ABNF for the EAI DSN and EAI MDN.
Appendix E. Changes from -00 Appendix D. Changes from -00
Added paragraph about use of 8bit Content-Transfer-Encoding for new Added paragraph about use of 8bit Content-Transfer-Encoding for new
message sub-types. message sub-types.
Updated the list of open issues. Updated the list of open issues.
Clarified that this document is targeted to become an Experimental Clarified that this document is targeted to become an Experimental
RFC. RFC.
Made the EAI downgrade document a normative reference. Made the EAI downgrade document a normative reference.
 End of changes. 26 change blocks. 
91 lines changed or deleted 88 lines changed or added

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