Changing the xn-- prefix
Simon Josefsson
simon at josefsson.org
Wed Mar 26 00:32:23 CET 2008
John C Klensin <klensin at jck.com> 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.
/Simon
More information about the Idna-update
mailing list