Re: [EAI] Add requirement for punycode conversions in downgrade
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [EAI] Add requirement for punycode conversions in downgrade



John C Klensin wrote:
> --On Tuesday, 18 March, 2008 02:34 +0100 Harald Tveit Alvestrand
> <harald at alvestrand.no> wrote:
>
>   
>>> 3. Downgrade should do a punycode conversion instead of
>>> failing because  of no Alternate Address.
>>>
>>> Since attempting delivery is almost always better than
>>> failing a  delivery, I would support adding a requirement to
>>> do the punycode  conversion for these cases in the Downgrade
>>> specification.
>>>       
>> For the case of non-ASCII localparts, this has been discussed 
>> extensively, and version 3 has been consistently rejected by
>> the WG.
>>
>> I haven't seen a discussion that focused on the
>> ASCII at non-ASCII situation.
>>     
>
> It seems to me that we have a tradeoff.  As Yao points out, no
> presentation of punycode to a user is user-friendly.  Punycode
> encoding can also be used to disguise various types of attacks
> that would be obvious if the string were presented in "native"
> form -- an analogy to the use of IP addresses, rather than
> domain names, in URLs might apply here.     One can say "Since
> attempting delivery is almost always better than failing...",
> but perhaps this is one of the exceptions in which it is better
> to get the failure message back to the sender and sending MUA in
> the hope of getting the punycode change made there (or some
> other decision being made).
>
> In any event, it seems to me that the case for _requiring_
> punycode conversion as a downgrade method is weaker than some of
> this discussion would indicate.
>
>     john
>   
The user interface at the recipient can and probably should translate 
punycode domains back to the original UTF8. Web browsers do this (at 
least Firefox and Internet Explorer). If you enter a punycode domain in 
the url field, the browser will translate it to UTF8 if you have the 
appropriate fonts installed. Email clients should provide a similar 
translation for email addresses containing punycode domains that are to 
be displayed to the user. I can add this to the Email Client guidelines 
document.

If Downgrade fails when sending to a recipient of the form 
ascii at non-ascii , what is the recourse for the user? A very few IDNA 
literate users might figure out how to do a punycode conversion and use 
it as an Alternate Address. Most users would have to revert to using a 
traditional email client.

One can also argue that this case will not be very common, as an 
organization that sets up email accounts using an Internationalized 
domain name would surely use EAI email software. However, during the 
transition period that we are in (internationalized domains are being 
registered), this case may occur often enough that Downgrade should 
handle it.

Ernie

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



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.