Changing the xn-- prefix

John C Klensin klensin at jck.com
Thu Mar 20 16:25:31 CET 2008



--On Thursday, 20 March, 2008 15:17 +0100 Simon Josefsson
<simon at josefsson.org> wrote:

> Vint Cerf <vint at google.com> writes:
> 
>> i would support option 1 as formulated below although I
>> sincerely hope that the documents as they stand support a
>> conclusion that the  prefix need not be altered.
> 
> The -issues document contain a starting pointer, but it needs
> to be improved.
 
> What is missing now is an analysis of why changing the prefix
> is still a bad idea if IDNABIS contains other backwards
> incompatible changes.

We agree.  I hope to get proposed new text posted to this list
within the next few days.  I would welcome suggested text in the
interim.

> I have not seen any discussion that weights the cost of
> changing the prefix with the cost of living with any security
> problems caused by IDNA2003 and IDNABIS incompatibilities.
> Partly that is because the discussions about _which_ backwards
> incompatible changes IDNABIS will make have not finished yet.
> Until those discussions reach a conclusion, we can't evaluate
> whether changing the prefix is too costly or not.
> 
> If the backwards incompatible changes in IDNABIS will be
> limited to the PR-29 strings, I believe we can live with the
> costs off having the PR-29 strings be filtered by IDNA200x
> implementations.  If there will be other changes, such as
> permitting german-ezset, the answer could be different.
> 
> Note that having to change the prefix can be an argument
> against permitting german-ezset in IDNABIS, so these to issues
> interact.

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 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?

   john



More information about the Idna-update mailing list