Changing the xn-- prefix

[Simon Josefsson]

Shawn Steele <Shawn.Steele at microsoft.com> writes:

>> But they will cause problems because IDNA2003-ToUnicode(x) won't be
>> the same as IDNA200x-ToUnicode(x) for a string x which can be
>> expressed in IDNA200x but is not valid under IDNA2003.
>
> I fail to see why that's a problem.  Increasing the space available
> for names is the point, and I expect IDNA 200x to replace IDNA2003.
> It would be terrible if apps had to know both.  RFC 4646 doesn't
> supplement RFC 3066, it replaces it.  I'd expect the same of any
> future IDN versions.

Sure, but IDNA2003 implementations will still be around since they are
already deployed.

> Keeping the distinction isn't interesting for back-compat either
> because an IDNA2003 aware app isn't suddenly going to be IDNA200x
> aware just because its a different prefix.  Either the label will be
> processed or not, the prefix is irrelevent.  If its a "new" name,
> there's nothing the app can do with it if it doesn't understand the
> name.

Right, and that is why IDNA200x would have to describe a transition
strategy if it changes the prefix.  That transition strategy would be
complicated, so I hope we won't end up with changing the prefix.  But it
is possible, and I believe it will help us think about trading costs
against each other.

> How would a new app behave if it had to support both prefixes?
> Somehow the mapping tables would have to include information about
> whether or not new behavior was used, which probably isn't trivial.
> This tremendously complicates code complexity and testing.  If such a
> scheme ends up requiring knowledge of both IDNA2003 & 200x, then it
> also becomes more challenging to implement on devices with limited
> memory (the tables aren't huge, but for a router that wanted to
> validate names or something it'd add up.)

IDNA200x could say that each old name has to be registered under the new
prefix as well, and then both new and old implementations will find it
without problem.  It would thus be possible to implement IDNA200x
without IDNA2003 in a client and have it work.

/Simon