Eszett and IDNAv2 vs IDNA2008

Vint Cerf vint at
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  


Vint Cerf
1818 Library Street, Suite 400
Reston, VA 20190
vint at

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

> Vint Cerf <vint at> 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
>> 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
>>>> and buggy appache stating always UTF-8
>>>> 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:
>>>> mail: peter at
>>>> ULA= fd80:4ce1:c66a::/48
>>>> _______________________________________________
>>>> Idna-update mailing list
>>>> Idna-update at
>>> _______________________________________________
>>> Idna-update mailing list
>>> Idna-update at

More information about the Idna-update mailing list