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

Tue Mar 10 03:53:11 CET 2009

Dear colleagues,

I'd like again to suggest that we take further discussion of whether  
all-number TLDs are safe over to the dnsop mailing list, since that's  
the place one is most likely to find the IETF participants who really  
have to deal in their professional or technical lives with the  
assortment of specification, oral tradition, and good and bad  
implementations that actually makes up the functioning DNS. The  
present thread is to some degree the reason I asked for responses off- 
list.

What is still needed, however, if anyone wants to provide it, is a  
pointer to the Fine Material showing that a Punycode-encoded label can  
or cannot end with a digit. I _think_ the answer is no, but I'd sure  
like a strong confirmation.

Best regards,

A

Andrew Sullivan
ajs at shinkuro.com

On 9-Mar-09, at 22:34, James Seng <james at seng.sg> wrote:

> +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
>>