Changing the xn-- prefix

Simon Josefsson simon at
Wed Mar 26 14:11:56 CET 2008

Shawn Steele <Shawn.Steele at> writes:

>> If all chars in the label can be represented in Unicode 3.2, xn--
>> domains are generated, otherwise xx--. On the reverse, a sanity check
>> is mandated for all xx-- that its round-trip must end up with xx--
>> label otherwise it fails.
> In that case a prefix change isn't necessary since the set of labels
> being added (those after Unicode 3.2) won't conflict with the existing
> xn-- space anyway.

But they will cause problems because IDNA2003-ToUnicode(x) won't be the
same as IDNA200x-ToUnicode(x) for a string x which can be expressed in
IDNA200x but is not valid under IDNA2003.  The cost of this can be
difficult to estimate unless we know exactly which strings 'x' we are
talking about.  Thus, before we know that, we don't know whether the
costs of the backwards incompatible strings are higher or lower than
changing the prefix.

I believe the most likely outcome is that we keep on using the same
prefix, but make a small number of carefully considered backwards
incompatible changes.

If we rule out the option of changing the prefix, there is nothing to
compare the cost of making backwards incompatible changes to.  This is
my primary reason for encouraging the WG to compare costs when thinking
about all backwards incompatible changes.

>> I suggest we remain silent on whether prefix change.
> As I've said before, I think the amount of disruption such a change
> causes warrants very strong language opposing it.  Your example isn't
> as disruptive, but it also doesn't require a change in prefix.  I'll
> happily reconsider my position if someone has a strong case where it
> is necessary AND non-disruptive, but so far none have been presented.
> Assuming we use the "MUST NOT have a prefix change" language, then if
> a case is discovered that is severe enough to require a prefix change,
> I would imagine that we would readily gather the consensus to change
> the charter.  If that consensus wasn't easy to get, then probably the
> need wouldn't be great enough to warrant a change in prefix.

It sounds like a good path for a lot of process discussions rather than
focusing on the technical work: just produce text that describe the cost
for each backwards incompatible change and compare that cost to changing
the prefix.  I don't think that text is likely to materialize if we rule
out all discussions related to changing the prefix.


More information about the Idna-update mailing list