numeric (ascii) labels (was: Re: draft-liman-tld-names-00.txt and bidi)

[James Seng]

+1

There is no technical basis to prevent numeric labels at 2nd level or
3rd level, and perhaps also debatable whether numeric labels is
allowed at 1st level (http://hello.123/), it would save a lot of
headache if we forbid all numeric labels at top-level, as a matter of
policy (not technical).

however, i am interested to know if there is any good reason to use
digits in TLD, that might change my mind.

-James Seng

On Tue, Mar 10, 2009 at 2:29 AM, Vint Cerf <vint at google.com> wrote:
> Eric,
>
> On blackberry, so very briefly, DNS specs are not the sole guide to conventions. I think much pain would be avoided if we banned all numeric TLDs since this would assure no possible confusion of a host name and a IP address. Banning initial and trailing numerics might have bidi benefits but perhaps concerns there could be confined within the bidi rule set.
>
> V
>
> ----- Original Message -----
> From: Eric Brunner-Williams <ebw at abenaki.wabanaki.net>
> To: John C Klensin <klensin at jck.com>
> Cc: Lyman Chapin <lyman at acm.org>; Martin Duerst <duerst at it.aoyama.ac.jp>; Andrew Sullivan <ajs at shinkuro.com>; Vint Cerf; idna-update at alvestrand.no <idna-update at alvestrand.no>
> Sent: Mon Mar 09 10:26:54 2009
> Subject: numeric (ascii) labels (was: Re: draft-liman-tld-names-00.txt and bidi)
>
> Howdy,
>
> 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
> (mis)using application.
>
> 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.
>
> Eric
>
>
>
> 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".
>>>
>>
>> Lyman,
>>
>> 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?
>>
>>     john
>>
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>
>>
>>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>