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

[Erik van der Poel]

I agree with Martin that because tmax is 26, the last character of a
Punycode string can only be a letter (a-zA-Z). See the top of page 28
in:

http://www.ietf.org/rfc/rfc3492.txt

I also ran a bunch of Unicode strings through the converter, and the
last character was always a letter.

Erik

On Mon, Mar 9, 2009 at 7:53 PM, Andrew Sullivan <ajs at shinkuro.com> wrote:
> 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
>>>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>