Changing the xn-- prefix

Simon Josefsson simon at
Wed Mar 26 00:32:23 CET 2008

John C Klensin <klensin at> writes:

> Let me make a suggestion in the hope of not going around the
> loop more times.  First, I think Simon has a point: if
> prefix-changing were relatively simple and painless, it would be
> better to change the prefix than to risk any possible ambiguity.
> I may have missed something, but I haven't seen anyone argue
> against that conclusion given the premise.   However, many of us
> believe that prefix-changing is, to put it mildly, neither
> simple nor painless.  Based on that belief, we see
> prefix-changing as a last resort, perhaps even (as Simon notes
> above) an argument against making some changes.

I think you understood exactly the argument I was trying to make.

> I don't see this as a debate that can be settled as a charter
> matter unless we want to set the WG up for failure.  Perhaps
> others disagree and, in particular, don't want to see a WG at
> all unless it meets conditions of theirs, with will/will not
> make a prefix change as one of those conditions.  I don't see
> how to move forward on that basis, but maybe that is just me.
> Could people live with a charter that assumes that we are going
> to work to avoid a prefix change (and says that), but does not
> firmly commit to that conclusion until we get finished?  In
> practical terms, that would make the comment "if you do X, it
> will require a prefix change" in scope and both "no, it doesn't
> require such a change because..." and "yes, but it is important
> enough that a prefix change would be justified" in scope as
> responses?

That could work, but it seems somewhat subjective.

I would feel more comfortable if the WG would be chartered to document
why the cost of changing the prefix would be higher than the cost of not
doing so and living with the costs of having backwards incompatible
changes.  To be useful, the discussion would have to consider every
backwards incompatible change compared to IDNA2003 and the costs
associated with it.

The text could be a section in one of the WG document, like:

  X. Backwards compatibility discussion

  IDNA200x makes a number of changes that affect backwards
  compatibility.  Here we consider every string such that
  IDNA2003-ToASCII(x) != IDNA200x-ToASCII(x).  One aspect of this
  discussion is balance the cost of the backwards incompatible change
  with the cost of changing the ACE prefix.

  X.1 The PR-29 strings

  The Unicode version used by IDNA2003 contained a flaw that affects a
  small number of strings.  blabla.  These strings can be identified
  pragmatically and does not occur in normal human languages, thus their
  real-world impact is considered negligible.  Changing the ACE prefix
  to solve this would lead to very minimal gains.

  X.2 Ezset


  X.3 ZWNJ

  X.4 Final Small Sigma

  X.5 Tonos

And so on.  I would contribute text to a section like that.


More information about the Idna-update mailing list