[EAI] AD review of draft-ietf-eai-rfc5336bis-04.txt

[Alexey Melnikov <[e-mail]>]

Hi WG,
Below is my AD review of the document (with some questions to the WG):

(In addition to the ABNF issues I raised in a separate email.)

2.  Overview of Operation

   This specification describes an optional extension to the email
   transport mechanism that permits non-ASCII [ASCII] characters in both
   the envelope and header fields of messages, which are encoded with
   UTF-8 [RFC3629] characters.  The extension is identified with the
   token "UTF8SMTPbis".  In order to provide information that may be
   needed in downgrading, an optional alternate ASCII address may be
   needed if an SMTP client attempts to transfer an internationalized
   message and encounters a server that does not support this extension.

I think the last sentence no longer applies and need to be deleted.

In 3.1:

  9.  The UTF8SMTPbis extension is valid on the submission port
       [RFC4409].

I think this sentence should also say that this extension can be used 
with LMTP.
This will make the reference to RFC 2033 Normative.


In 3.2:

   A UTF8SMTPbis aware MUA/MSA sending to a legacy SMTP server [RFC5321]
   and [RFC5322] MAY convert the ASCII@non-ASCII

Native speakers: should the "the" be replaced with "a" here?

   address into the format
   of ASCII@A-label [RFC5890] if the email address is in the format of
   ASCII@non-ASCII.



3.4.  UTF8 addresses and Response Codes

   An "internationalized message" as defined in the appendix of this
   specification

I think the part that reads "as defined in the appendix of this 
specification"
needs to be removed, because the definition is already in another document
and this document no longer has any appendix.

   MUST NOT be sent to an SMTP server that does not
   support UTF8SMTPbis.  Such a message should be rejected by a server
   if it lacks the support of UTF8SMTPbis.

3.6.2.  Mail eXchangers

   Organizations often authorize multiple servers to accept mail
   addressed to them.  For example, the organization may itself operate
   more than one server, and may also or instead have an agreement with
   other organizations to accept mail as a backup.  Authorized servers
   are generally listed in MX records as described in RFC 5321.  When
   more than one server accepts mail for the domain-part of a mailbox,
   it is strongly advised that either all or none of them support the
   UTF8SMTPbis extension.  Otherwise, surprising downgrades can happen
   during temporary failures, which users might perceive as a serious
   reliability issue.

The last sentence: I think this needs to be reworded or deleted,
as "surprising downgrades" are no longer an issue.


3.6.4.2.  VRFY and EXPN Commands and the UTF8REPLY Parameter

   VERIFY (VRFY) and EXPAND (EXPN) command syntaxes are changed to:

       "VRFY" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF
              ; uLocal-part and uMailbox are defined in
              ; Section 3.3 of this document.

Section 3.3 no longer contains definitions of uLocal-part and uMailbox.
See my separate email message about ABNF errors in rfc5335bis/rfc5336bis.

Also note that RFC 5321 is using:

      vrfy = "VRFY" SP String CRLF

So I suggest using the same format (with "vrfy =") for consistency.


       "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF
              ; uLocal-part and uMailbox are defined in
              ; Section 3.3 of this document.

As above.
Similarly, I suggest using:

      expn = "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF


   If the SMTP reply requires UTF-8 strings, but UTF-8 is not allowed in
   the reply, and the server supports enhanced mail system status codes
   [RFC3463], the enhanced response code is either "X.6.8" or "X.6.10"

Can somebody remind me why we have 2 different Enhanced Status Code which
mean the same thing?

   [RFC5248], meaning "A reply containing a UTF-8 string is required to
   show the mailbox name, but that form of response is not permitted by
   the client".


4.  IANA Considerations

   +---------------+-----------------------------+---------------------+
   | WITH protocol | Description                 | Reference           |
   | types         |                             |                     |
   +---------------+-----------------------------+---------------------+
   | UTF8SMTPbis   | UTF8SMTPbis with Service    | [RFCXXXX]           |
   |               | Extensions                  |                     |
   | UTF8SMTPbisA  | UTF8SMTPbis with SMTP AUTH  | [RFC4954] [RFCXXXX] |
   | UTF8SMTPbisS  | UTF8SMTPbis with STARTTLS   | [RFC3207] [RFCXXXX] |
   | UTF8SMTPbisSA | UTF8SMTPbis with both       | [RFC3207] [RFC4954] |
   |               | STARTTLS and SMTP AUTH      | [RFCXXXX]           |
   +---------------+-----------------------------+---------------------+

Do we really need to change the WITH protocol types?


   [RFC2033]  Myers, J., "Local Mail Transfer Protocol", RFC 2033,
              October 1996.

Make this reference Normative as per my earlier comment.

-- 
IETF Application Area Director, <http://www.ietf.org/iesg/members.html>
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address