Changing the xn-- prefix

YAO Jiankang yaojk at
Wed Mar 19 07:33:15 CET 2008

----- Original Message ----- 
From: "Martin Duerst" <duerst at>
To: "Simon Josefsson" <simon at>; "Andrew Sullivan" <ajs at>
Cc: <idna-update at>
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> 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 <>.
>>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. 

YAO Jiankang

> 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
> #-#-#       mailto:duerst at     
> _______________________________________________
> Idna-update mailing list
> Idna-update at

More information about the Idna-update mailing list