numeric (ascii) labels (was: Re: draft-liman-tld-names-00.txt and bidi)
ebw at abenaki.wabanaki.net
Mon Mar 9 18:26:54 CET 2009
When the preliminary language to what is now ICANN's Guidebook for
Applicants (GfA, but it has several alternate TLAs, just to be amusing),
contained the "no numeric label" language, in decimal, octal and hex
forms, I spent some time, initially with Kurt Pritz, and later with Olaf
Nordling, to explain the inet_addr(3) issue.
The language didn't change in GfAv2, issued two weeks ago, though
someone did explain, as Lyman did below, that there is software which
does the wrong thing. The GfAv2 text, like Lyman's, doesn't fully treat
the cases to find the set of constraints which will allow a sequence of
labels, some of which are numeric, to be strictly interpreted as a name,
rather than as an address.
In the history of ICANN's "new gTLD" effort(s), software which does the
wrong thing has been ignored, e.g., the "terminal labels have length 4
or less" error (.arpa and the three and two ascii sequence labels,
resulting in the temporary clobbering of .museum and other new gTLDs),
and software which does the wrong thing has been controlling, e.g., the
"email addresses are formed of 7-bit octet sequences" (a rationale for
"A" in "IDNA"), the consequences are still before us today.
My personal view is that broken code that isn't a defacto specification
of the DNS, or broken specifications of things other than the DNS, need
to go find their authors and get fixed, and not become dejure nuances of
the "corrected" specifications of the DNS. In particular, it is
reasonable for any zone admin, the IANA included, to make a
registry-local rule reflecting momentary annoyance at the existence of
well-known bugs, but that no such "rule" should be internalized to the
DNS specs, with a vastly longer shelf-life than the random DNS
Yes, there is a bug (actually, a shared bug with multiple, possibly
independent interoperable implementations of obvious brokenness), but
666 is no different from AAA, and a five label sequence composed of
numeric (or octal or hex) character values is safe as houses (if ugly),
and it is possible to constrain allocation of label sequences so that
label sequences terminating in numeric (or octal or hex) character
values, and having fewer than five labels, are also not incorrectly
interpreted by this bug-set as dotted quads.
Of course, ICANN is only a part of the design constraint, and one could
say "0 is not allowed as a label in .", but the rational would be for
reasons other than those in the DNS specs -- and in a separate note I'll
address Limon's draft, which covers some of the issues addressed in 2929.
John C Klensin wrote:
> --On Saturday, March 07, 2009 11:01 -0500 Lyman Chapin
> <lyman at acm.org> wrote:
>> Martin and Andrew,
>> Although it seems that numeric values above 255 would be safe,
>> some software looks only at the low-order 8 bits of a number
>> encoded in a 16-bit (for example) field (ignoring any
>> high-order bits) when it "knows" that a numeric value will
>> always be 255 or less. In that case only the 8 low-order
>> bits (10011010) of 666 (...01010011010) would be recognized.
>> Entering "666" into such an interface would be equivalent to
>> entering "154".
> I'm completely confused and don't know what you are talking
> about. If the issue is domain names, expressed the preferred
> syntax of dot-separated ASCII characters, "666" is as good as
> "ABC" or "ACM". If the issue is numeric values, the DNS spec
> understand only octets and not, e.g., 16 (UTF-16?) or 32
> (UTF-32/UCS-4) data fields. The last I looked, it was quite
> hard to fit a decimal number larger than 255 into an octet.
> So, what are you saying?
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update