Eszett and IDNAv2 vs IDNA2008
vint at google.com
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
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.
1818 Library Street, Suite 400
Reston, VA 20190
vint at google.com
On Mar 19, 2009, at 8:58 PM, JFC Morfin wrote:
> 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)
> - 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.
> 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 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
>> ULA= fd80:4ce1:c66a::/48
>> Idna-update mailing list
>> Idna-update at alvestrand.no
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update