Changing the xn-- prefix

[Shawn Steele]

John Wrote:

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

> In particular, I would welcome suggestions from either of you
> (or others) about how the "prefix change" material in Section
> 9.3 of  draft-klensin-idnabis-issues-07 can be improved.

The last sentence "Consequently, a prefix change is to be avoided if at all possible,
   even if it means accepting some IDNA2003 decisions about character
   distinctions as irreversible." Should be a statement in the first part of the section :) eg: "A prefix change MUST be avoided if at all possible."

The "conditions requiring a prefix change" and the "implications of prefix changes" should perhaps be correlated with each other.  I would also go farther and come up with requirements based on these implications.

9.3.1 1) & 2) The conversion of an A-label to Unicode (i.e., a U-label) yields
       one string under IDNA2003 (RFC3490) and a different string under
       IDNA200X.
- Therefore the punycode conversion MUST remain the same for all code point sequences that aren't prohibited in the updated version.

3) A fundamental change is made to the semantics of the string that
       is inserted in the DNS, e.g., if a decision were made to try to
       include language or specific script information in that string,
       rather than having it be just a string of characters.
- Therefore such semantics can't change.

4) A sufficiently large number of characters is added to Unicode so
       that the Punycode mechanism for block offsets no longer has
       enough capacity to reference the higher-numbered planes and
       blocks.  This condition is unlikely even in the long term and
       certain not to arise in the next few years.
- Therefore those characters, should they be added, will be illegal in the punycode forms of the names.

Additionally I should note that I consider the entire punycode behavior to be a hack to make a Unicode name be usable in a non-Unicode enabled DNS system.  Additional prefixes or encodings make it much more difficult for the clients to figure out what is the "best" behavior is for a particular scenario.  Should they try older prefixes?  Will that cause security problems such as spoofing and phishing?  If they don't what about the mom & pop domains that "stop working" because they didn't know to update their registrations?  What about the mom & pop shops that are too slow and someone else registers their updated name first?

I would prefer that any updates to this hack be along the lines of allowing UTF-8 in the DNS system as that is certainly a long term complete solution.  UTF-8 is additional much more in alignment with RFC 2277 which states that "UTF-8 support MUST be possible" (for all protocols).  IDN would then "merely" be the stringprep normalization, filtering and matching rules for such names and perhaps security guidelines for using such names.

- Shawn