Changing the xn-- prefix
yaojk at cnnic.cn
Wed Mar 19 07:33:15 CET 2008
----- Original Message -----
From: "Martin Duerst" <duerst at it.aoyama.ac.jp>
To: "Simon Josefsson" <simon at josefsson.org>; "Andrew Sullivan" <ajs at commandprompt.com>
Cc: <idna-update at alvestrand.no>
Sent: Wednesday, March 19, 2008 10:56 AM
Subject: Re: Changing the xn-- prefix
> At 06:11 08/03/19, Simon Josefsson wrote:
>>Andrew Sullivan <ajs at commandprompt.com> writes:
>>> Dear colleagues,
>>> On Tue, Mar 18, 2008 at 05:42:33PM +0100, Simon Josefsson wrote:
>>>> Even if they wanted to do so, all registries could not convert all
>>>> IDNA2003 ("xn--") registrations to a new form at the same time
>>>> I don't see why registries would need to convert anything at the same
>>>> time? Supporting IDNABIS will be a gradual process for the few
>>>> registries that support IDNA2003 today. I don't think any registry will
>>>> support IDNABIS the same day it is published. There is no change
>>>> everything at the same time.
>>> I no longer work for a registry; but having been on the pointy end of
>>> that data stick once before, I am pretty sure nobody in the registry
>>> business will want to support both systems at once. Explaining how
>>> all of the current approach is supposed to work even for incredibly
>>> simple cases, like German, takes much more effort than those who are
>>> participating in this discussion might believe. I don't want to
>>> prejudge that the prefix must not change, but I sure want to be clear
>>> that changing the prefix almost certainly means a flag day, and may
>>> well cause currently-operational registrations to become invalid.
>>Given ゜, I'm not sure German is a simple case.
>>I think Norway would be a simpler case, since they only permit
>>registration of domains with non-ASCII characters mentioned in the list
>>Assuming those characters are unaffected by Unicode 3.2 to Unicode 5.0
>>migration, I don't see a major problem to allow registration of both the
>>IDNA2003 form and the IDNABIS form, for every IDN string. The
>>conversion from IDNABIS to IDNA2003 may for .NO be a simple
> I think this points to a reason why a new prefix is costly:
> In a case such as Norway, they'd add a new prefix (some cost)
> essentially for nothing (nothing at all is changing for them).
yes, I agree that a new prefix is too costly.
Adding a new prefix is unnecessary and may cause the instability of domain system.
sometimes, it will cause the confusion between the new and old prefixes to the IDN users.
> In a case such as Germany (let's assume sharp s is going to
> be allowed in IDNABIS), they'll have to figure out the exact
> relationship anyway, and they'll have to do it independently
> of whether there is a new prefix or not. And the new prefix
> actually won't really help them (the fact that xn--sharp-s
> names exist if the prefix won't be changed won't bother
> IDNA2003 applications because they never look for it).
> In my view, a new prefix would only be necessary if there are
> any cases where xn--foo and xp--foo both exist but won't
> map to the same data (IP address). And any such case would
> be a problem in and by itself. There is no real problem with
> cases that resolve under IDNA2003 but not under IDNABIS
> (IDNAbis resolvers just won't resolve them; such cases
> are probably not even going to exist), and there is no real
> problem iwth cases that resolve under IDNABIS but not
> IDNA2003 (see above; such cases most probably will be rare).
> So indeed a new prefix is quite a bit of cost for probably
> essentially no gain.
> Regards, Martin.
> #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
> #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update