Eszett and IDNAv2 vs IDNA2008

Vint Cerf vint at
Fri Mar 20 12:34:01 CET 2009


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.

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.


Vint Cerf
1818 Library Street, Suite 400
Reston, VA 20190
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