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

["YAO Jiankang" <yaojk at cnnic.cn>]

----- Original Message ----- 
From: "Ernie Dainow" <edainow at ca.afilias.info>
To: "John C Klensin" <klensin at jck.com>
Cc: <ima at ietf.org>
Sent: Wednesday, March 19, 2008 5:03 AM
Subject: 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.

my concern is that if the reciever smtp server is not EAI-compatible, the recipient is more unlikely to use an EAI-compatible email client.
so the form presented to the user has to be the form of unfriendly punycode version if the punycode form is produced in the email client .



Yao Jiankang

> 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
>
_______________________________________________
IMA mailing list
IMA at ietf.org
https://www.ietf.org/mailman/listinfo/ima