numeric (ascii) labels (was: Re: draft-liman-tld-names-00.txt and bidi)
Mark Andrews
Mark_Andrews at isc.org
Tue Mar 10 03:04:05 CET 2009
In message <8A6A10DF-9F52-4FCC-8F5A-0C0DB69D1900 at google.com>, Vint Cerf writes:
> Eric,
>
> I did not say to ban digits at all levels (and ENUM is an example of
> use of digits that does not cause confusion, for instance).
>
> The limitation in the TLD space does have the benefit that no domain
> name would have the property that it could be confused with an IP
> address. I think that is simpler to implement than trying to check how
> many labels there are in the domain name, and if four labels, can it
> be interpreted as an IP address.
Especially as IPv4 addresses can contain 1, 2, 3 or 4 parts.
> As Lyman Chapin points out, some
> decimal values are interpreted as 32 bit values and thus as IPv4
> addresses by some systems.
> I am only speaking of the TLD label space here, and not lower level
> TLDs. I don't know whether that makes a difference to you?
>
> v
>
>
> Vint Cerf
> Google
> 1818 Library Street, Suite 400
> Reston, VA 20190
> 202-370-5637
> vint at google.com
>
>
>
>
> On Mar 9, 2009, at 6:44 PM, Eric Brunner-Williams wrote:
>
> > Vint,
> >
> > Your position then is that because _people_ may mistake sequences of
> > digits as addresses, that labels be constrained to contain at least
> > one non-digit character, with the same constraint expressed for
> > octal and hex labels?
> >
> > Everyone has their own notion of what constitutes acceptable
> > dumbness, and anyone who thinks that
> >
> > 3.141592653589793238462643383279502884197169399375105820974944592.
> >
> > is an ip address (the name is taken from one of my favorite .com
> > examples) is not doing us any favors by insisting that we design
> > around his or her grasp of the details. Other than by going blind,
> > one space at a time (oh the joy of cards punched long forgotten, and
> > OS dumps before the invention of symbolic debuggers, also mercifully
> > long forgotten), what is the difference between the above and the
> > following:
> >
> > 3.141592653589793238462643383279S02884197169399375105820974944592.
> >
> > Did an infix alpha really buy us anything?
> >
> > Also, it simply isn't useful to state "DNS specs are not the sole
> > guide to conventions" without some specifics. What do we use? Augury?
> >
> > I'm not keen on making the mistaken rule that "." in a string handed
> > to a resolver is punctuation and has a weak directionality property,
> > but if that has any use at all, that is, a limit on leading and
> > trailing digits, I'd prefer to see it at the registry, as local
> > policy, not the protocol, where independent of the directionality of
> > the label, or even the recourse to punycode, the policy is global,
> > and mostly incorrect.
> >
> > Eric
> >
> > Vint Cerf 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.n
> o
> >> <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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the Idna-update
mailing list