draft-ietf-eai-rfc5337bis-dsn-05.txt   draft-ietf-eai-rfc5337bis-dsn-06.txt 
Network Working Group T. Hansen, Ed. Network Working Group T. Hansen, Ed.
Internet-Draft AT&T Laboratories Internet-Draft AT&T Laboratories
Obsoletes: 5337 (if approved) C. Newman Obsoletes: 5337 (if approved) C. Newman
Updates: 3461, 3462, 3464, 3798 Oracle Updates: 3461, 3462, 3464, 3798 Oracle
(if approved) A. Melnikov (if approved) A. Melnikov
Intended status: Standards Track Isode Ltd Intended status: Standards Track Isode Ltd
Expires: May 3, 2012 October 31, 2011 Expires: May 17, 2012 November 14, 2011
Internationalized Delivery Status and Disposition Notifications Internationalized Delivery Status and Disposition Notifications
draft-ietf-eai-rfc5337bis-dsn-05 draft-ietf-eai-rfc5337bis-dsn-06
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 Standards operation of an email system. However, the existing Draft Standards
(RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text
in the machine-readable portions of the protocol. This specification in the machine-readable portions of the protocol. This specification
adds a new address type for international email addresses so an adds a new address type for international email addresses so an
original recipient address with non-US-ASCII characters can be original recipient address with non-US-ASCII characters can be
correctly preserved even after downgrading. This also provides correctly preserved even after downgrading. This also provides
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 May 3, 2012. This Internet-Draft will expire on May 17, 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 2, line 30 skipping to change at page 2, line 30
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. The message/global-delivery-status Media Type . . . . . . 6 4.1. The message/global-delivery-status Media Type . . . . . . 6
4.2. The message/global Media Type . . . . . . . . . . . . . . 9 4.2. The message/global Media Type . . . . . . . . . . . . . . 9
4.3. The message/global-headers Media Type . . . . . . . . . . 9 4.3. The message/global-headers Media Type . . . . . . . . . . 9
4.4. Using These Media Types with multipart/report . . . . . . 9 4.4. Using These Media Types with multipart/report . . . . . . 9
4.5. Additional Requirements on SMTP Servers . . . . . . . . . 9 4.5. Additional Requirements on SMTP Servers . . . . . . . . . 9
5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 10 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 11 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 11
6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 12 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 11
6.3. message/global-headers . . . . . . . . . . . . . . . . . . 12 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 12
6.4. message/global-delivery-status . . . . . . . . . . . . . . 14 6.4. message/global-delivery-status . . . . . . . . . . . . . . 13
6.5. message/global-disposition-notification . . . . . . . . . 15 6.5. message/global-disposition-notification . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Changes Since ... . . . . . . . . . . . . . . . . . . 18 Appendix A. Changes Since RFC 5337 . . . . . . . . . . . . . . . 18
A.1. Changes Since -00 . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18
A.2. Changes Since RFC 5337 . . . . . . . . . . . . . . . . . . 19
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 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-rfc5336bis] extension and Internationalized Email [I-D.ietf-eai-rfc5336bis] extension and Internationalized Email
Headers [I-D.ietf-eai-rfc5335bis], it is sometimes necessary to Headers [I-D.ietf-eai-rfc5335bis], it is sometimes necessary to
return that message or generate a Message Disposition Notification return that message or generate a Message Disposition Notification
(MDN) [RFC3798]. As a message sent to multiple recipients can (MDN) [RFC3798]. As a message sent to multiple recipients can
generate a status and disposition notification for each recipient, it generate a status and disposition notification for each recipient, it
is helpful if a client can correlate these notifications based on the is helpful if a client can correlate these notifications based on the
skipping to change at page 4, line 9 skipping to change at page 4, line 9
at the end of this section. at the end of this section.
An SMTP [RFC5321] server that advertises both the UTF8SMTP extension An SMTP [RFC5321] server that advertises both the UTF8SMTP extension
[I-D.ietf-eai-rfc5336bis] and the DSN extension [RFC3461] MUST accept [I-D.ietf-eai-rfc5336bis] and the DSN extension [RFC3461] MUST accept
a UTF-8 address type in the ORCPT parameter including 8-bit UTF-8 a UTF-8 address type in the ORCPT parameter including 8-bit UTF-8
characters. This address type also includes a 7-bit encoding characters. This address type also includes a 7-bit encoding
suitable for use in a message/delivery-status body part or an ORCPT suitable for use in a message/delivery-status body part or an ORCPT
parameter sent to an SMTP server that does not advertise UTF8SMTP. parameter sent to an SMTP server that does not advertise UTF8SMTP.
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. Only the first form is 7-bit safe (only uses and utf-8-address. Only the first form is 7-bit safe (only uses US-
7-bit characters). ASCII characters).
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. That protocols capable of native representation of 8-bit characters. That
is, the utf-8-address form MUST NOT be used in the ORCPT parameter is, the utf-8-address form MUST NOT be used:
when 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 (utf-8-addr-xtext MUST be used instead); or
parameter forbids unencoded SP and the = character), or in a 7-bit
transport environment including a message/delivery-status Original- 2. the SMTP server supports UTF8SMTP, but the address contains US-
Recipient or Final-Recipient field. In the first and third case, the ASCII characters not permitted in the ORCPT parameter (e.g., the
utf-8-addr-xtext form (see below) MUST be used instead; in the second ORCPT parameter forbids unencoded SP and the = character),
case, either the utf-8-addr-unitext or the utf-8-addr-xtext form MUST (either utf-8-addr-unitext or utf-8-addr-xtext MUST be used
be used. The utf-8-address form MAY be used in the ORCPT parameter instead); or
when the SMTP server also advertises support for UTF8SMTP and the
address doesn't contain any US-ASCII characters not permitted in the 3. in a 7-bit transport environment including a message/
ORCPT parameter. It SHOULD be used in a message/ delivery-status Original-Recipient or Final-Recipient field,
global-delivery-status Original-Recipient or Final-Recipient DSN (utf-8-addr-xtext MUST be used instead).
field, or in an Original-Recipient header field [RFC3798] if the
message is a UTF8SMTP message. The 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 contain any US-ASCII characters not permitted in the ORCPT
parameter. It SHOULD be used 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.
When used in the ORCPT parameter, the UTF-8 address type requires When used in the ORCPT parameter, the UTF-8 address type requires
that US-ASCII CTLs, SP, \, +, and = be encoded using 'unitext' that US-ASCII CTLs, SP, \, +, and = be encoded using 'unitext'
encoding (see below). This is described by the utf-8-addr-xtext and encoding (see below). This is described by the utf-8-addr-xtext and
utf-8-addr-unitext forms in the ABNF below. The 'unitext' encoding utf-8-addr-unitext forms in the ABNF below. The 'unitext' encoding
uses "\x{HEXPOINT}" syntax (EmbeddedUnicodeChar in the ABNF below) uses "\x{HEXPOINT}" syntax (EmbeddedUnicodeChar in the ABNF below)
for encoding any Unicode character outside of US-ASCII range, as well for encoding any Unicode character outside of US-ASCII range, as well
skipping to change at page 11, line 47 skipping to change at page 11, line 47
(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 characters from the US-ASCII repertoire, a specification for how
they are to be encoded as graphic US-ASCII characters in a DSN they are to be encoded as graphic US-ASCII characters in a DSN
Original-Recipient or Final-Recipient DSN field. Original-Recipient or Final-Recipient DSN field.
This address type has 3 forms (as defined in Section 3): utf-8- This address type has 3 forms (as defined in Section 3): utf-8-
addr-xtext, utf-8-addr-unitext, and utf-8-address. Only the addr-xtext, utf-8-addr-unitext, and utf-8-address. Only the
first form is 7-bit safe. first form is 7-bit safe.
The utf-8-address form MUST NOT be used:
1. in the ORCPT parameter when the SMTP server doesn't advertise
support for UTF8SMTP;
2. or the SMTP server supports UTF8SMTP, but the address contains
US-ASCII characters not permitted in the ORCPT parameter (e.g.,
the ORCPT parameter forbids SP and the = characters);
3. or in a 7-bit transport environment including a message/
delivery-status Original-Recipient or Final-Recipient field.
The utf-8-addr-xtext form MUST be used instead in the first and the
third case; the utf-8-addr-unitext form MUST be used in the second
case.
The 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 contain 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
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 [RFC3464] and The mail diagnostic type registry was created by [RFC3464] and
updated by [RFC5337] and this specification. The registration for updated by [RFC5337] and this specification. The registration for
the 'smtp' diagnostic type should be updated to reference RFC XXXX in the 'smtp' diagnostic type should be updated to reference RFC XXXX in
addition to [RFC3464] and [RFC5337]. addition to [RFC3464] and [RFC5337].
When the 'smtp' diagnostic type is used in the context of a message/ When the 'smtp' diagnostic type is used in the context of a message/
delivery-status body part, it remains as presently defined. When the delivery-status body part, it remains as presently defined. When the
'smtp' diagnostic type is used in the context of a message/ 'smtp' diagnostic type is used in the context of a message/
skipping to change at page 18, line 10 skipping to change at page 17, line 26
BNF for Syntax Specifications: ABNF", BNF for Syntax Specifications: ABNF",
STD 68, RFC 5234, January 2008. STD 68, RFC 5234, January 2008.
[I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed, [I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed,
"Internationalized Email Headers", "Internationalized Email Headers",
draft-ietf-eai-rfc5335bis-13 (work in draft-ietf-eai-rfc5335bis-13 (work in
progress), October 2011. progress), October 2011.
[I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension [I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension
for Internationalized Email", for Internationalized Email",
draft-ietf-eai-rfc5336bis-15 (work in draft-ietf-eai-rfc5336bis-16 (work in
progress), October 2011. progress), November 2011.
[I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and
Framework for Internationalized Framework for Internationalized
Email", Email",
draft-ietf-eai-frmwrk-4952bis-12 (work draft-ietf-eai-frmwrk-4952bis-12 (work
in progress), October 2011. in progress), October 2011.
8.2. Informative References 8.2. Informative References
[RFC2045] Freed, N. and N. Borenstein, [RFC2045] Freed, N. and N. Borenstein,
skipping to change at page 18, line 37 skipping to change at page 18, line 5
[RFC2046] Freed, N. and N. Borenstein, [RFC2046] Freed, N. and N. Borenstein,
"Multipurpose Internet Mail Extensions "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", (MIME) Part Two: Media Types",
RFC 2046, November 1996. RFC 2046, November 1996.
[RFC5337] Newman, C. and A. Melnikov, [RFC5337] Newman, C. and A. Melnikov,
"Internationalized Delivery Status and "Internationalized Delivery Status and
Disposition Notifications", RFC 5337, Disposition Notifications", RFC 5337,
September 2008. September 2008.
Appendix A. Changes Since ... Appendix A. Changes Since RFC 5337
A.1. Changes Since -00
NOTE TO RFC EDITOR: Remove this section for publication.
Incorporated changes from draft-ietf-eai-dsnbis-01.
Fixed description of utf-8-addr-xtext and utf-8-addr-unitext.
Other minor corrections.
Incorporated comments by Apps Area reviewers.
References to Downgrade and uMailbox removed/fixed.
A.2. Changes Since RFC 5337
Made changes to move from Experimental to Standards Track. The most Made changes to move from Experimental to Standards Track. The most
significant was the removal of an embedded alternative ASCII address significant was the removal of an embedded alternative ASCII address
within a utf-8-address, and reflections of the ABNF changes in within a utf-8-address, and reflections of the ABNF changes in
[I-D.ietf-eai-rfc5336bis]. [I-D.ietf-eai-rfc5336bis].
Fixed description of utf-8-addr-xtext and utf-8-addr-unitext.
References to Downgrade and uMailbox removed/fixed.
ABNF changes and errata suggested by Alfred Hoenes. ABNF changes and errata suggested by Alfred Hoenes.
Minor changes to MIME type references. Minor changes to MIME type references.
Other minor corrections. Other minor corrections.
Appendix B. Acknowledgements Appendix B. 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, Harald Alvestrand, Frank Ellermann, SM, Alfred Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, Alfred
 End of changes. 11 change blocks. 
76 lines changed or deleted 43 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/