Subject: [EAI] text for ascii@non-ascii issues

From: "YAO Jiankang" <[email-masked]>
Date: Mon, 16 Aug 2010 17:42:54 +0800

the last paragragh of section 3.2 of rfc5336bis is supposed to the following text:

   If a server advertises UTF8SMTP and the client does not recognize the
   extension, the client may send a regular message only using the legacy SMTP defintions [RFC5321] and
   [RFC5322].  In this case, the MUAs/MSAs  may continue to use the
   IDNA Definitions document[RFC5890] to transform the domain portion of an address to A-label
   [RFC5890] if the email address is in the format of ASCII@non-ASCII,
  then the UTF8SMTPbis server MUST
   recognize and decode the ACE label(s) as appropriate.
   According to the legacy SMTP specifications [RFC5321] and
   [RFC5322],  the legacy SMTP servers MUST reject the message with the
   ASCII@non-ASCII if the non-ASCII domain part is not transformed into
   the format of A-label by the MUAs/MSAs.

---

From: John C Klensin <[email-masked]>
Date: Mon, 16 Aug 2010 11:43:59 -0400

--On Monday, August 16, 2010 17:42 +0800 YAO Jiankang
<[email-masked]> wrote:

>    If a server advertises UTF8SMTP and the client does not
> recognize the    extension, the client may send a regular
> message only using the legacy SMTP defintions [RFC5321] and
> [RFC5322].  In this case, the MUAs/MSAs  may continue to use
> the    IDNA Definitions document[RFC5890] to transform the
> domain portion of an address to A-label    [RFC5890] if the
> email address is in the format of ASCII@non-ASCII,   then the
> UTF8SMTPbis server MUST
>    [RFC5322],  the legacy SMTP servers MUST reject the message
> with the    ASCII@non-ASCII if the non-ASCII domain part is
> not transformed into    the format of A-label by the MUAs/MSAs.

I think this is consistent with what the WG agreed to in
Maastricht (and to which there has been no dissent on the
mailing list), but it is in serious need of editing.  The text
is hard to follow and does not appear to me to be acceptable for
something to be submitted to the IESG for IETF Last Call.

     john