Changing the xn-- prefix
Shawn.Steele at microsoft.com
Wed Mar 26 17:33:00 CET 2008
> 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.
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.
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.)
More information about the Idna-update