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

[Chris Newman <[e-mail]>]

--On July 26, 2011 19:51:37 +0800 Jiankang Yao <[e-mail]> wrote:
>> 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?

Yes.

Without this sentence, a server can implement old DSN and be compliant with 
the old DSN spec and implement UTF8SMTPbis and be compliant with 
rfc5336bis, and not support UTF-8 in ORCPT. Such a server will break 
interoperability with clients that are compliant with 4952bis which 
requires this behavior.

>> 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?

Let me attempt to re-word based on Dave's feedback:

      SMTP servers are encouraged to detect that recipients can not accept
      internationalized email headers and generate an error after the RCPT
      command rather than waiting until after the DATA command to issue an
      error.

>> 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.

This does not prevent a broken client from generating a UTF-8 domain that 
is not a valid U-label and thus can not be converted to an A-label. It's an 
error a well-intentioned client implementer can make by mistake. And it's a 
subtle error condition a processor may not expect. For those reasons, I 
think it's useful to distinguish it from the class of 
"recipient-can't-handle" errors.

		- Chris