On Sat, May 17, 2025 at 03:05:17PM -0400, John C Klensin wrote:
>
>
> --On Saturday, May 17, 2025 12:08 -0400 Donald Eastlake
> <d3e...@gmail.com> wrote:
>
> > The DNS protocol itself is binary clean. Bytes in labels can have
> > any value. Of course this may cause problems in applications / user
> > interface code or the like. And it is true that leading underscores
> > and such like may, by convention be reserved. And "host" names are
> > nominally supposed to start with a letter or digits and have only
> > letters, digits, and hyphens. etc.
> >
> > The labels are length value encoded on the wire and there are only 6
> > bits for length so labels are limited to 63 bytes. The label of
> > length zero is reserved for the label of the root node. Labels only
> > "end in a period" in their usual string representation, not on the
> > wire.
>
> +1
> A few suggestions...
> If one is looking for definitions of domain name syntax to reference
> in a document, RFC 1035 is a better reference than 1034. It defines
> a "preferred name syntax" that lies at the core of most applications
> use of the DNS. It is also worth at least looking at Section 6.1.3.5
> of RFC 1123 and Section 11 of RFC 2181 to get a better understanding.
> While a particular application is free to define its own rules for
> labels, that should be done (as those documents suggest) clearly and
> with great care.
>
> For example, if there are going to be dependencies on, or
> recommendations about RFC 7542, whatever syntax rules are adopted
> should be examined to determine whether UTF-8 labels are allowed or
> whether IDNA ("xn--...") are needed or more appropriate.
This draft says names are stored as A-Labels.
> Independent of the above, I thought there was an explicit agreement
> among the IAB, IETF and assorted other parties to not add new
> application uses or conventions to the ARPA. tree. The "control" of
> ARPA. by the IAB mentioned in the I-D is, IIR, just the mechanism to
> enforce that agreement, not an invitation to add additional
> second-level domains. That issue probably should have been more
> closely examined by the IAB and the community when "eap-noob.arpa."
> was adopted but the fact that we have created one such second-level
> domain does not imply that more of them, especially for the same
> general set of protocols, are appropriate. Indeed, it may suggest
> otherwise.
Hmm, I do not really remember something so formal as you indicate here. In
fact, I don't remember much at all relating to .arpa, but I do remember
having the impression that there were some scenarios in which it could be
used.
-Ben
_______________________________________________
Emu mailing list -- emu@ietf.org
To unsubscribe send an email to emu-le...@ietf.org
