Changing the xn-- prefix
Shawn.Steele at microsoft.com
Mon Mar 24 18:48:48 CET 2008
> I certainly agree that changing the prefix would be a terrible
> 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
- 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.
More information about the Idna-update