Eszett and IDNAv2 vs IDNA2008

Fri Mar 20 14:37:15 CET 2009

Simon perhaps we are not too far apart. Re-charter, as I understand  
it, would involve the same kind of community consensus building that a  
BOF does.

Before we come to the conclusion that we need new prefix, new  
charters, etc, I would sure like to have an assessment of the  
implications of adopting the present specifications. We already know  
there are some backward incompatibilities and I believe this was  
understood going into the WG in the first place. The question is how  
these can be addressed and whether the solutions are considered  
acceptable.

v

Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com

On Mar 20, 2009, at 9:28 AM, Simon Josefsson wrote:

> Vint Cerf <vint at google.com> writes:
>
>> Folks,
>>
>> introduction of a new prefix at this late stage strikes me as a non-
>> starter. It is proving hard enough to deal with the issues on the
>> table associated with the xn-- prefix. What we need to do is to
>> evaluate essentially the present IDNA2008 specification and  
>> understand
>> implications and transition issues associated with its introduction.
>
> I agree, but maybe for different reasons.
>
> If the IDNA2008 protocol introduces backwards incompatible changes
> compared to IDNA2003, which seems to be the case, we are violating the
> part of the charter that says "Ensure practical stability of validity
> algorithms for IDNs".
>
> Making the changes may be reasonable in some cases (e.g., eszet), but
> the costs of doing so (security problems in protocols that need stable
> domain names across IDNA versions) needs to be compared with the  
> cost of
> changing the prefix.
>
> Thus I believe an evaluation of the trade-offs is needed.
>
>> We are also going to hear from Paul Hoffman his idea for a variation
>> of IDNA2003.
>>
>> If there is a desire among the WG participants to pursue more radical
>> directions than these, I believe those pursuits should be taken up
>> through the IETF BOF process.
>
> The IDNABIS WG charter says that it should stop and recommend that a  
> new
> charter be generated if it concludes that the prefix needs to be
> changed.  There is already a WG in the IETF where this discussion
> belongs.  If the discussion doesn't belong here, the WG cannot ever
> reach a conclusion to change the prefix, which would violate the  
> spirit
> of the WG charter.  Thus, I believe a BOF is the wrong recommendation.
>
> /Simon
>
>> Vint
>>
>>
>>
>>
>>
>> Vint Cerf
>> Google
>> 1818 Library Street, Suite 400
>> Reston, VA 20190
>> 202-370-5637
>> vint at google.com
>>
>>
>>
>>
>> On Mar 19, 2009, at 8:58 PM, JFC Morfin wrote:
>>
>>> Peter,
>>> there is no need to introduce a mess in the DNS which uses LDH
>>> labels, to support IDNA which should permit what-you-want-entries.
>>>
>>> The "only" problems are absolutely not DNS problems :
>>> - there is no presentation layer to differentiate between the codes
>>> of the entries (architecture)
>>> - there is only one code which does not match all the specfic needs
>>> (choice of published Unicode)
>>>
>>> Now,
>>> - the "x.--" permits to define some kind of presentation layer that
>>> can be supported through IDNA
>>> - there can be different code adaptations. "xn--" being the IDNA2008
>>> default adaptation. "xs--" being the case-sensitive adaptation.
>>>
>>> Due to the punycode algorithm capacities, the only remaining need is
>>> for this WG to decide and publish something. Then concerned users
>>> will adapt and start deploying a test that linguistic communities  
>>> may
>>> test to get experience.
>>>
>>> Now, you may want to have Unicode directly in Domain Name. But, then
>>> you have a domain name layer violation: you cannot adapt on an  
>>> "x.--"
>>> basis. You have to create and get supported a new Unicode for each
>>> culture that need some specifc use of Unicode.
>>>
>>> Or develop a brand new system.
>>> jfc
>>>
>>> At 00:22 20/03/2009, Peter Dambier wrote:
>>>
>>>
>>>> John C Klensin wrote:
>>>>
>>>>>
>>>>> You will never get case-sensitivity with ."fra" in the DNS
>>>>> unless your intention is to provide an equal-opportunity mess by
>>>>> encoding everything with a prefix, including basic (undecorated)
>>>>> Latin characters.  That encoding can't be Punycode, since it
>>>>> won't encode those basic Latin characters.
>>>>>
>>>>
>>>> John, don't forget most of us are not us-ascii writers and I guess
>>>> most of us don't even use latin at all.
>>>>
>>>> UTF-8 is a mess, UTF-16 is an excuse and the world really is  
>>>> UTF-32.
>>>>
>>>> Bind e.g. can do UTF-32.
>>>>
>>>> Whether windows or IE can do UTF-32 does not matter. The chinese
>>>> will replace it sooner or later with something better.
>>>>
>>>> Try and compare correct implementation
>>>>
>>>> http://www.das-loch-von-koelle.de/UTF/
>>>>
>>>> and buggy appache stating always UTF-8
>>>>
>>>> http://www.hessen-braucht-sechs.de/UTF/
>>>>
>>>> it is the same text trying ISO, UTF-8, UTF-16 and UTF-32 with
>>>> both big-endian and littel-endian versions.
>>>>
>>>> We do have the bandwidth. We can use UTF-32.
>>>>
>>>> UTF-16 might be favouring the chinese but UTF-32 is same trouble
>>>> for everybody.
>>>>
>>>> Ok the site is about presentation and html. Bind is binary. It
>>>> does not care what code you feed it but you probably have to
>>>> implement the IDNS-patch to make it forget folding cases.
>>>>
>>>> Interestingly enough IE can do UTF-32 but Chrome and Safari, both
>>>> on Windows XP - complained.
>>>>
>>>> Peter
>>>> --
>>>> Peter and Karin Dambier
>>>> Cesidian Root - Radice Cesidiana
>>>> Rimbacher Strasse 16
>>>> D-69509 Moerlenbach-Bonsweiher
>>>> +49(6209)795-816 (Telekom)
>>>> +49(6252)750-308 (VoIP: sipgate.de)
>>>> mail: peter at peter-dambier.de
>>>> http://www.peter-dambier.de/
>>>> http://iason.site.voila.fr/
>>>> https://sourceforge.net/projects/iason/
>>>> ULA= fd80:4ce1:c66a::/48
>>>> _______________________________________________
>>>> Idna-update mailing list
>>>> Idna-update at alvestrand.no
>>>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>>
>>> _______________________________________________
>>> Idna-update mailing list
>>> Idna-update at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/idna-update