Changing the xn-- prefix

[Shawn Steele]

> John Wrote:
>
>> I certainly agree that changing the prefix would be a terrible
>> idea...

I reread your original mail, and in particular I don't want to get bogged down in the debate of details while trying to set the guidelines, but I'd like to try for "A prefix change MUST be avoided" (removing the condition).  If that's going to cause too much randomization, then I'd back down, but the repercussions of changing the prefix are huge.

I understand that there're concerns about the impact of such things as the behavior of unassigned code points, however I think that any revisions can be generalized as either:

 a) the code points (whether defined or not) don't change between version, so the punycode form doesn't change, or

 b) the code points change, either because they're now illegal, they map to some other code point (casing), or they are now allowed when they weren't before.  In those cases we are intentionally enabling or breaking names that we disallowed/allowed before.

Allowing new names is OK, obviously that'll happen just because of the expanded character repertoire.

Disallowing existing names requires that we intentionally expect to break these names.  That effectively means that "if we allowed this before, we were wrong and you're going to have to pick a new name."  Assuming that's what we mean, then IE certainly isn't going to want to resolve a disallowed name, so changing the prefix isn't helpful. Additionally falling back to an "old" implementation of IDN to support xn-- wouldn't be "safe" since any disallowed name would presumably be bad/dangerous, so being able to distinguish loses its value.

Regarding the changes you regard as necessary, I'm not disagreeing.  What I am saying is that disallowing unassigned codepoints, or changing case mappings, etc. are breaking changes.  Any breaking changes that we

> These conditions are, IMO, a bit too strong.

I'm not disagreeing that these changes are necessary.  What I'm saying is that these are "breaking changes", and that these breaking changes cannot be supported in future versions, EVEN by falling back to an older xn-- version.  We should only take those breaking changes that we are sure fix "bad" behavior, and we should recognize that this means that existing "bad" names will fail in the future.  Trying to pretend that we won't break even bad names by changing the prefix won't help, particularly since such fundamental changes can't be ignored by clients like IE without being considered insecure.

My conditions we're meant to restrict the intentionally breaking changes, but rather only meant to make us recognize that those changes are indeed breaking and there isn't a backwards compatible fix for them.  I could probably have made my point better :)

- Shawn