On Tue, Nov 16, 2010 at 04:06:37PM +0000, Tony Finch wrote: > According to my reading of RFC 1123 it is allowed, and IDNA depends on it > being allowed. The normative text says that anything that isn't a dotted > quad IP address should be treated as a domain name.
Define what you mean by "normative text". You're quite right that the "will be alphabetic" restriction is in the Discussion, and therefore can be construed as not actually part of the protocol (that's actually how I read it). But the argument has been that the Discussion segment amounts to a constraint on the protocol, or anyway may well have been interpreted that way in running code. We don't know. (And of course, as usual in the DNS, we don't have any way of checking.) You're quite right that the "will be alphabetic" stricture has to be released for TLDs to be able to do IDNA at all: every one of them contains "--" and that's not alphabetic. So I read the document as trying to relax that rule just exactly enough to allow A-labels in the TLDs, without relaxing everything. The "don't relax everything" goal is to make the smallest change needed so that if there are any bad effects, they're not magnified more than they ought to be. Given what I have seen in other TLD-checking type code, I'd bet a pretty good lunch that anything _starting_ with a digit in the top level will run into all sorts of troubles. There's probably some heuristic software out there that checks the top-most label, looks for a digit in the first character, and treats the set of labels as an IP address if there is one. To me, the justification for the U-label having to be a letter, then, is that such a label could get passed in as a U-label form, and if the carelessly-written code is running in a Unicode environment it will do exactly the same thing as I just described. So the draft seems to me to make the most conservative change it can. Even if I don't like it, the top level is different from other levels in the DNS, and we need to be careful there. A -- Andrew Sullivan [email protected] Shinkuro, Inc. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
