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

From: "Jiankang YAO" <[email-masked]>
Date: Sat, 27 Nov 2010 08:40:13 +0800

thanks,

we will update the draft soon.

Jiankang Yao

----- Original Message ----- 
From: "Alexey Melnikov" <[email-masked]>
To: "EAI WG" <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

---

From: "Jiankang YAO" <[email-masked]>
Date: Sat, 27 Nov 2010 09:13:32 +0800

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

.....
> Can somebody remind me why we have 2 different Enhanced Status Code which

I think that it is due to the Associated basic status code:

      Code:               X.6.8
      Sample Text:        UTF-8 string reply is required,
                          but not permitted by the client
      Associated basic status code:  553, 550

      Code:               X.6.10
      Sample Text:        UTF-8 string reply is required,
                          but not permitted by the client
      Associated basic status code:  252

Jiankang Yao

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Nov 2010 22:59:11 -0500

> we will update the draft soon.

When you do so, please remove the periods after your personal
name and that of Mao Wei in the top header author lines.

I will do a detailed review over the weekend and get back to
you; you might want to hold off posting a new draft until that
is in your hands.

   john

---

From: "Jiankang YAO" <[email-masked]>
Date: Sat, 27 Nov 2010 13:39:12 +0800

----- Original Message ----- 
From: "John C Klensin" <[email-masked]>
To: "Jiankang YAO" <[email-masked]>; "Alexey Melnikov" <[email-masked]>; "EAI WG" <[email-masked]>
Sent: Saturday, November 27, 2010 11:59 AM
Subject: Re: [EAI] AD review of draft-ietf-eai-rfc5336bis-04.txt

> you; you might want to hold off posting a new draft until that

thanks,
waiting for your kind comments.

Jiankang Yao

---

From: "Jiankang YAO" <[email-masked]>
Date: Sat, 27 Nov 2010 20:40:33 +0800

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

....
> 4.  IANA Considerations

RFC5336 has updated the WITH protocol types.
so this time, we might have to update it again.

the updates for WITH protocol types were suggested by Chris Newman  in RFC5336.

I think that Chris may have a better answer to this question.

Jiankang Yao

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 27 Nov 2010 12:51:29 +0000

Hi Jiankang,

>      Associated basic status code:  252
But the first digit of the basic status code should be included in the 
X.6.8/X.6.10 enhanced status code. I.e. X.6.8 would become either 2.6.8 
or 5.6.8, depending on what the first digit of the basic code is.

John or Tony (or anybody else who knows), do you have an opinion?

---

From: John C Klensin <[email-masked]>
Date: Sat, 27 Nov 2010 15:23:01 -0500

--On Saturday, November 27, 2010 8:40 PM +0800 Jiankang YAO
<[email-masked]> wrote:

>>   +---------------+-----------------------------+------------
>>   ---------+ | 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]           |

I'd be happy to hear from Chris but, from the standpoint of the
protocols that affect WITH, I don't see any difference between
5336 and 5336bis and hence no need to change the keyword.  Note
that downgrade considerations cannot apply because the message
is being delivered.   If the first-version experimental
protocols applied, then things would in fact be different.

    john

---

From: John C Klensin <[email-masked]>
Date: Sat, 27 Nov 2010 15:26:23 -0500

--On Saturday, November 27, 2010 12:51 PM +0000 Alexey Melnikov
<[email-masked]> wrote:

>>>  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?
>>>    
>>> 
>> 
> But the first digit of the basic status code should be
> included in the X.6.8/X.6.10 enhanced status code. I.e. X.6.8
> would become either 2.6.8 or 5.6.8, depending on what the
> first digit of the basic code is.
> 

Unless I'm confused, we need either 2.6.8 and 5.6.8 _or_ 2.6.10
and 5.6.10, but not a mixture of x.6.8 and x.6.10.  I.e., I
think I agree with Alexey -- we either need either one basic
enhanced code or more explanation than appears above.

Tony?

    john