Changing the xn-- prefix

[James Seng]

I am happy to go with what John proposed.

Shawn, I dont think we differ in what we want as the end result. We
want to see as minimum disruption to the existing IDNs. Therefore,
changing or not changing the prefix is really not the issue. A
proposal that keep xn-- prefix but change punycode encoding to
something else would not likely to work.

We got here today because IDNA is stuck in Unicode 3.2. Not sure how
many remember but that restriction was added at fairly late stage.
Just as the old working group wrap up the work, Unicode Consortium
releases Unicode 4.0, which make some mapping changes to their
normalization table. While it is a correcting some mistakes and it is
fairly minor, they break their promise of "never changing the
mapping". If they can break this in 4.0, they might do it again later,
despite Mark assure it will be the last correction, so the group
thought back then.

Right now, if we see the xn-- prefix, it say "This is an IDN label". I
can imaging we expand further such that xn-- => "IDN label under
Unicode 3.2 rules", xx-- "IDN labels for Unicode 4.0> rules". Once
again, this is not a proposal (I have no proposal at this moment) but
what I hope to see is that we keep options open for protocol
designers.

-James Seng

>  Regardless of how one feels about a prefix change, I tend to
>  agree with those who have suggested that, if we embark on that
>  course, going through a charter change and review would be, IMO,
>  a useful exercise in making sure that the community was willing
>  to accept the implications of such a change.  Failure to do that
>  would create an unreasonable risk of doing the work and then
>  having the whole business rejected at Last Call.    So, per my
>  previous note, can we keep the topic open for discussion if
>  people believe it is necessary but specify that we would go back
>  for community review (in the form of rechartering) if we
>  actually decided a prefix change was necessary?