Changing the xn-- prefix (was: Re: Wwhich RFCs the new work would obsolete, vs update or leave alone)

Andrew Sullivan ajs at
Tue Mar 18 19:45:14 CET 2008

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.

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

My view is that, if IDNA2003 is to be replaced, we need to do it once,
and correctly.  The deployment to date is not so great as to make
prefix replacement an insurmountable task right now.  I'd hate for us
to wait until it became one, and then learn we need to do this again.
If we need to change the prefix (and yes, I do see some of the
advantages), let's take the hit one time and be done with it.


Andrew Sullivan
ajs at
+1 503 667 4564 x104

More information about the Idna-update mailing list