Consensus Call Tranche 8 Results

[Vint Cerf]

Folks,

changing the prefix is not in the cards for this round of IDNA  
refinement. While we can discuss the consequences if you like, I  
strongly recommend that we consider only solutions that retain the  
present xn-- structure for IDNs expressed in punycoded UNICODE  
strings made up of PValid characters.

vint


NOTE NEW BUSINESS ADDRESS AND PHONE
Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com




On Nov 5, 2008, at 5:02 AM, YAO Jiankang wrote:

>
> ----- Original Message -----
> From: "Simon Josefsson" <simon at josefsson.org>
> To: "YAO Jiankang" <yaojk at cnnic.cn>
> Cc: "Mark Davis" <mark at macchiato.com>; "Vint Cerf"  
> <vint at google.com>; <idna-update at alvestrand.no>
> Sent: Wednesday, November 05, 2008 5:26 PM
> Subject: Re: Consensus Call Tranche 8 Results
>
>
>> "YAO Jiankang" <yaojk at cnnic.cn> writes:
>>
>>>>> It is still premature to add eszett and final sigma until we  
>>>>> have some
>>>>> accompanying text that addresses the security exploit.
>>>>> The two possibilities I could think of are:
>>>>>
>>>>>    1. Change the prefix for xn--
>>>>
>>>> That would work, but it is costly.  It is good to keep this  
>>>> option in
>>>> the discussion, as a sanity test of the cost-benefits of other  
>>>> options.
>>>> I claim that any solution that is more expensive to implement  
>>>> and deploy
>>>> than changing the xn-- prefix should be disqualified.  Of  
>>>> course, the
>>>> difficult part is to assess costs.
>>>>
>>>
>>> agree, changing the prefix is too costly to work.
>>
>> I didn't say that.
>>
>> Changing the prefix is technically simple but costly from a  
>> deployment
>> point of view.  Without knowing the cost of the other options, you
>> cannot know whether those other options cost more or less than  
>> changing
>> the prefix.  To measure the cost of the other solutions, you need an
>> analysis.  We haven't seen any analysis in this context.
>>
>> If there is no compelling analysis to support another approach, I  
>> would
>> actually support changing the prefix.  There are some advantages in
>> changing the prefix: it becomes clear which version of the IDNA
>> specifications were used by the encoder.  That information is lost  
>> when
>> the same prefix is used by both IDNA2003 and IDNA2008.
>
> changing the prefix is unfair for those who already registered IDN.  
> they must update xn--abcd-example to other prefix--abcd-exapmle.
> another problem is that
> if the prefix is changed, the resolver is trying to resolve the IDN  
> to [xn--abcd-example] or  [ New prefix--abcd-exapmle] for further  
> dns lookup?
>
>
>
>
>>
>> /Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081105/0aec06ec/attachment.htm