Changing the xn-- prefix
duerst at it.aoyama.ac.jp
Wed Mar 19 03:56:02 CET 2008
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).
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.
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
More information about the Idna-update