Changing the xn-- prefix

[James Seng]

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 suggest we remain silent on whether prefix change.

-James Seng

On Wed, Mar 26, 2008 at 12:53 AM, Shawn Steele
<Shawn.Steele at microsoft.com> wrote:
> > b) there must be backward compatibility with all existing IDN labels
>  > with xn prefix.
>
>  This condition cannot be satisfied.  To be backward compatible, my existing xn-- name MUST work when some new browsers try to resolve it.  I cannot be forced to reregister xx-- or whatever because we know that this won't be consistent.  Even if the registrars automagically gave everyone new prefixes & old prefixes, then the servers would still need updated to recognize the new names, and the certificates, and ....  That pretty much guarantees that some existing names will be broken.
>
>  Additionally, if you did guarantee that all existing xn-- names were compatible with any new prefix, then there wouldn't be a need for a new prefix since new names wouldn't collide with the old names and xn-- could be reused.
>
>  I believe that we should use
>
> > "The prefix
>  > xn-- MUST NOT be changed." where MUST NOT is defined according to the
>  > IETF definition in RFC 2119
>
>  To change my mind, one MUST :) prove to me that xn-- and xx-- (whatever) can coexist without breaking existing names and servers or causing even more spoofing.  We cannot force small shops to make changes to their names or servers as that will break those parts of the web.
>
>  - Shawn
>