Eszett and IDNAv2 vs IDNA2008

Simon Josefsson simon at
Fri Mar 20 14:28:34 CET 2009

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.


> 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