Re: [DNSOP] draft-liman-tld-names-04

[Andrew Sullivan <[e-mail]>]

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
[e-mail]
Shinkuro, Inc.