Internationalized Delivery Status and Disposition Notifications
RFC 6533

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    eai mailing list <>,
    eai chair <>
Subject: Protocol Action: 'Internationalized Delivery Status and Disposition Notifications' to Proposed Standard (draft-ietf-eai-rfc5337bis-dsn-06.txt)

The IESG has approved the following document:
- 'Internationalized Delivery Status and Disposition Notifications'
  (draft-ietf-eai-rfc5337bis-dsn-06.txt) as a Proposed Standard

This document is the product of the Email Address Internationalization
Working Group.

The IESG contact persons are Pete Resnick and Peter Saint-Andre.

A URL of this Internet Draft is:

Technical Summary

   Delivery status notifications (DSNs) are critical to the correct
   operation of an email system.  However, the existing Draft Standards
   (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text
   in the machine-readable portions of the protocol.  This specification
   adds a new address type for international email addresses so an
   original recipient address with non-US-ASCII characters can be
   correctly preserved even after downgrading.  This also provides
   updated content return media types for delivery status notifications
   and message disposition notifications to support use of the new
   address type.

 Working Group Summary 
   There were nothing controversial nor rough for this document.

Document Quality 
   This document was reviewed by many in WG with expertise in mail.
   Many thanks to Elliot Lear for external review.  And big thanks to Tony
   Hansen for his effort to make this document ready for publication.


   Joseph Yee <> is the document shepherd.
   Pete Resnick <> is the cognizant AD.

The EAI Working Group would like these three documents, along with
draft-ietf-eai-frmwrk-4952bis-12 (to which all three have a normative
reference and is still under IESG review) released as a set. We would
greatly appreciate that they get consecutive RFC numbers in the
following (non-obvious) order:


The reason that 5336bis should have a lower number than 5335bis is
because the current ordering of 5335 (the international email format
document) and 5336 (the international email transport document) has
caused some amount of confusion because the base specifications are in
the other order: First is RFC 5321 (the email transport document) and
second is 5322 (the email format document). And if it works out, having
the RFC numbers end in 0, 1, 2, and 3 respectively might be salient to

Thanks for your consideration.