SMTP Extension for Internationalized Email
RFC 6531

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: '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:

Technical Summary

   This document specifies an SMTP extension for transport and delivery
   of email messages with internationalized email addresses or header

 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.   


   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.