Changing the xn-- prefix

[John C Klensin]

(copies trimmed to eliminate duplicates to those already known
to be on the list)

--On Wednesday, 26 March, 2008 09:06 +0800 James Seng
<james at seng.sg> wrote:

> I give you an example (once again only an example) where the
> condition can be satisfied.
> 
> 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.
> 
> The above have a lot of holes of course (particularly on
> security) but leaving for that aside for the moment, it does
> not require the existing xn-- owners nor the cert to be change
> or replace.

I am not convinced that it even works.  Some of the proposals
that are being taken seriously right now involve taking
characters that IDNA2003 maps to others or just deletes and
_changing_ their interpretations so that they actually get
reversibly encoded into the ACE strings.  Whether that change is
incompatible or not, and how seriously incompatible it is,
depends on whether one is at the user interface looking down,
the zone file level looking up, or trying to interpret a string
in a file without necessarily intending to pass it through the
lookup process.   But, regardless of the answer to that
question, the IDNA2003 form and interpretation are clearly valid
in an IDNA2003 context and in Unicode 3.2 (representability in
Unicode 3.2 is, obviously, a necessary condition for IDNA2003
conformance but not a sufficient one).

If we were to give up on all of the changes other than adding an
appropriate subset of the characters added to Unicode between
3.2 and 5.1, it might work, but that would constitute giving up
on the model in the current drafts and that, in turn, would
require a recharter under the current draft charter language
(and it would make a prefix change even less necessary).

> I suggest we remain silent on whether prefix change.

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?

      john