Changing the xn-- prefix
Shawn Steele
Shawn.Steele at microsoft.com
Mon Mar 24 18:48:48 CET 2008
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
More information about the Idna-update
mailing list