SMTP Extension for Internationalized Email
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com>, eai mailing list <firstname.lastname@example.org>, eai chair <email@example.com> Subject: Protocol Action: 'SMTP Extension for Internationalized Email' to Proposed Standard (draft-ietf-eai-rfc5336bis-16.txt) The IESG has approved the following document: - 'SMTP Extension for Internationalized Email' (draft-ietf-eai-rfc5336bis-16.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: http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5336bis/
Technical Summary This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. Working Group Summary There were many discussions but none of the consensuses were tough to reach nor had tough resistance from the consensus. Document Quality This document received lots of attentions and reviews since Nov/Dec 2010 and is in very good shape. As mentioned in Acknowledgement section, many thanks to Dave Crocker's suggestions that led to refinements in the ABNF. Personnel Joseph Yee <firstname.lastname@example.org> is the document shepherd. Pete Resnick <email@example.com> 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: draft-ietf-eai-frmwrk-4952bis-12 draft-ietf-eai-rfc5336bis-16 draft-ietf-eai-rfc5335bis-13 draft-ietf-eai-rfc5337bis-dsn-06 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 readers. Thanks for your consideration.