Changing the xn-- prefix

[Martin Duerst]

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
>at <http://www.norid.no/domeneregistrering/idn/idn_nyetegn.html>.
>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
>s/^xn--/xp--/.

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.

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