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

["Jiankang YAO" <[e-mail]>]

thanks,

we will update the draft soon.

Jiankang Yao

----- Original Message ----- 
From: "Alexey Melnikov" <[e-mail]>
To: "EAI WG" <[e-mail]>
Sent: Saturday, November 27, 2010 6:11 AM
Subject: [EAI] AD review of draft-ietf-eai-rfc5336bis-04.txt


> 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
> 
> _______________________________________________
> IMA mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ima