Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt

----- Original Message ----- 
From: "Chris Newman" <chris.newman@oracle.com>
To: <ima@ietf.org>
Sent: Monday, July 25, 2011 10:16 PM
Subject: Re: [EAI] I-D Action: draft-ietf-eai-rfc5336bis-11.txt

> --On July 7, 2011 18:23:52 -0700 internet-drafts@ietf.org wrote:
>> Title           : SMTP Extension for Internationalized Email
>> Author(s)       : Jiankang Yao
>>                           W. Mao
>> Filename        : draft-ietf-eai-rfc5336bis-11.txt
>> Pages           : 20
>> Date            : 2011-07-07
> 
> I've done an extensive "clean slate" review on this document. I found a 
> number of issues I consider largely editorial 
>

thanks a lot for your kind and detailed review.

Some of your suggested editorial texts has been changed back and forth many times.
I am sorry that the texts can not make everyone happy.
I will try to adjust the texts based on your editorial suggestion, but will also follow the previous discussion about
this topic to avoid the "back and forth" text problem.

>and some I consider 
> substantive (in that the decision has technical impact). I've attached my 
> full review with editorial notes embedded in the text. Here are the 
> substantive issues:
> 
> 1. Somewhere this needs to say: If a server advertises both UTF8SMTPbis and 
> DSN, then that server MUST support UTF-8 in the ORCPT parameter. This also 
> has ABNF impact. 
>

my concern is that, if we choose to add the sentence above we cause another problems.

Is it really necessary to add such a sentence?

>
>We need to add:
> 
>   ehlo-param  =/ UTF8-non-ascii
> 
> to allow UTF-8 in mail, rcpt and data parameters.
> 
> 2. I would prefer this ABNF rule be removed:
> 
>   quoted-pairSMTP  =/ %d92 UTF8-non-ascii
>    ; extend the definition of quoted-pairSMTP in RFC5321, section 4.1.2
> 
> This is an unnecessary change and makes 5336bis quoting even less 
> consistent with 5335bis quoting. Conservative generators should never emit 
> \ followed by anything other than \ or double-quote anyway, so adding 
> complexity to explicitly allow generation of useless forms is not helpful.
> 

I agreed it here.

How about Dave's comments about this issue?

>
> 3. I suggest adding a statement to the end of section 3.5:
> 
>      SMTP servers are encouraged to detect that recipients can not
>      accept internationalized email headers and return an error
>      earlier in the transaction whenever possible.
> 

similar comments to Dave's

http://www.ietf.org/mail-archive/web/ima/current/msg04285.html

another question is 

adding this sentence is more clear than without it?

> 4. In section 3.5, I suggest adding an enhanced status code for the case 
> where a U-label can not be converted to an A-label. This is semantically 
> quite different from X.6.7 and X.6.9
> 

based on rfc5890, U-label must be transformed to A-label, otherwise, it can not be called U-label.

John should be authoritive about the defintion of U-label.

> 5. Section 3.7 says the A-label form SHOULD be used. While I don't object 
> to that for relay, I believe it should also say that submission clients MAY 
> use U-labels.
> 

agree.

> 6. Section 3.7.3:
> 
>>   If the messages that include trace fields are sent by an UTF8SMTPbis-
>>   aware SMTP client or relay server with the UTF8SMTPbis parameter at
>>   MAIL commands, trace field values SHOULD use the U-label form for the
>>   internationalized domain name.
> 
>      This wording suggests servers need to convert from A-label to
>      U-label if a previous server did the wrong thing. I don't think
>      that's reasonable. I suggest rewording:
> 
>    When an SMTP server adds a trace field to a message that was or
>    will be transmitted with the UTF8SMTPbis MAIL FROM parameter, that
>    server SHOULD use the U-label form for internationalized domain
>    names in that new trace field.
> 

ok, thanks.

> 7. Section 3.7.3 needs to say (given the current ABNF):
> 
>   The Atom form of the ID clause can contain non-ASCII characters.
>

I think that the current wording below covers the "ID clause" case:

"When the UTF8SMTPbis extension is used, the 'Reverse-
   path' clause of the Return-path-line may include an internationalized
   domain name that uses the U-label form; The 'Stamp' clause ot the
   Time-stamp-line may include an internationalized domain name that
   uses the U-label form.

"

thanks a lot.

Jiankang Yao

--------------------------------------------------------------------------------

> _______________________________________________
> IMA mailing list
> IMA@ietf.org
> https://www.ietf.org/mailman/listinfo/ima
>