Changing the xn-- prefix

[Simon Josefsson]

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--/.

> In particular,
>
>> IDNABIS could say that for backwards compatible reasons, when you create
>> a domain xp--foo in your zone (for some non-ASCII string), the software
>> needs to make sure there is a xn--foo for the corresponding IDNA2003
>> name too, if there is an equivalent IDNA2003 name.
>
> is a total nightmare.  The people who will get to decide "equivalent"
> for the above will not be linguists, DNS experts, domain registry
> experts, or even database geeks.  This is just a new way of importing
> the entire "name variant" discussion -- which is already complicated
> enough -- into the IDNAbis documents.  Besides, if there's a (ahem)
> simple problem of "equivalence" here, we could just put some
> restrictive bag on the side of IDNA2003 and be done with it.  The
> problem is supposed to be in the underlying philosophy of IDNA2003,
> because of its effects.  Any proposal that enshrines compatibility
> rules with IDNA2003 will just mean that the older standard hangs
> around as a permanent feature, complicating every future decision.
> (By way of analogy, under the above proposal, it seems like IDNA2003
> could become the 8.3 filename format of the Internet.)

Hm, you have a point.  If this approach is to be seriously considered
one would probably have to describe exactly how to map IDNABIS names to
IDNA2003 names, for all the situations where IDNABIS isn't backwards
compatible.  There are certainly more things to consider as well.

/Simon