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

[Chris Newman <[e-mail]>]

--On August 3, 2011 14:44:06 -0400 Joseph Yee <[e-mail]> wrote:
>>>> 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.
>
> I'm not sure if a different error code can help end users at the moment.
> Unless you mean MSA/MTA to detect and report U-label => A-label failure,
> otherwise it is only "recipient-can't-handle" or "host-not-found".
>
> Would love to hear more feedback from everyone regarding this.

A "host-not-found" error is close but not entirely accurate since a UTF-8 
domain that can't be converted to an A-label can't even be looked up to 
determine if the host exists...

But I looked in RFC 3463 again and noticed there are correct codes that an 
MSA/MTA could use for this case.

MAIL FROM:   501 5.1.7 Bad sender's mailbox address syntax
RCPT TO:     501 5.1.3 Bad destination mailbox address syntax

So I think mentioning those codes for the case where a UTF-8 domain can't 
be converted to an A-label would be helpful.

		- Chris