Subject: [EAI] the suggest text for rfc5335bis

From: "Jiankang YAO" <[email-masked]>
Date: Thu, 19 Aug 2010 17:37:27 +0800

at the end of section 3.2 for the ascii@idn issues:

   This document applies only when an UTF8SMTPbis-aware client is trying
   to send an internationalized message to a server which requires the
   UTF8SMTPbis extensions to handle it.  For all other cases, and for
   addresses and messages that do not require an UTF8SMTPbis extension,
   SMTP clients and servers are expected to behave exactly as specified
   in [RFC5321] and [RFC5322].

   A UTF8SMTPbis aware MUA/MSA sending to a legacy SMTP server [RFC5321]
   and [RFC5322] may convert the ASCII@non-ASCII addresse into the
   format of ASCII@A-label where A-label is defined in IDNA definitions
   [RFC5890] if the email address is in the format of ASCII@non-ASCII.

section 3.5 suggest to remove the following text:

   1.  If there is no BODY parameter, the header contains UTF-8
       characters, but all the body parts are in ASCII (possibly as the
       result of a content-transfer-encoding).

(no parameters in the body is the broken case, so i think that we can remove it.)

any comments are welcom.

Jiankang Yao

---

From: John C Klensin <[email-masked]>
Date: Thu, 19 Aug 2010 13:22:47 -0400

I can live with this.  Minor editorial suggestions below (for
-03, I guess):

--On Thursday, August 19, 2010 17:37 +0800 Jiankang YAO
<[email-masked]> wrote:

>    This document applies only when an UTF8SMTPbis-aware client
> is trying    to send an internationalized message to a server
> which requires the    UTF8SMTPbis extensions to handle it.
> For all other cases, and for    addresses and messages that do
> not require an UTF8SMTPbis extension,    SMTP clients and
> servers are expected to behave exactly as specified    in
> [RFC5321] and [RFC5322].
> 
>    A UTF8SMTPbis aware MUA/MSA sending to a legacy SMTP server
> [RFC5321]    and [RFC5322]

If you say "server", 5322 is, in theory, irrelevant and the
reference can be dropped.  Not really important either way
however.

> may convert the ASCII@non-ASCII

s/may/MAY/

> addresse into the    format of ASCII@A-label where A-label is
> defined in IDNA definitions    [RFC5890] if the email address

This isn't quite right.  If you really intend what this says,
then 
"...ASCII@A-label [RFC5890]" is sufficient: that is what the
citation is for and I think we have already said that an
understanding of both the base Internet email specs (5321/5322
and MIME) and IDNA is necessary to get around in these
documents.  If we haven't said that clearly enough, we should.

> is in the format of ASCII@non-ASCII.

>        characters, but all the body parts are in ASCII
> (possibly as the        result of a content-transfer-encoding).

Good.  Especially since it isn't clear to what a "BODY
parameter" refers.

> any comments are welcom.

See above.
   john