Dave Crocker wrote:
The text in RFC 1035 I have in mind is:
> 2.3.1. Preferred name syntax
....
So, no, it doesn't explicitly cite the RFC number, but I read it as
citing the substance.
i think it's non-normative and should not be referenced in your
document. this text:
However, when assigning a domain name for an object, the prudent user
will select a name which satisfies both the rules of the domain system
and any existing rules for the object, whether these rules are published
or implied by existing programs.
....does not require or prohibit. and in your example:
When creating a new host name,
the old rules for HOSTS.TXT should be followed.
....is not using a modern SHOULD, it's general advice only.
bizarrely, we are then greeted by this text:
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.
it says "must", and if this is to be seen as a modern MUST, then it is
true of all labels, and SRV updated 1035. also, the famous example of
3com.com required a change to the SRI-NIC policies of its era, but was
never backported to 1035. so, this text is clearly archaic.
whereas, in 952 we have the following. (more commentary below the break.)
GRAMMATICAL HOST TABLE SPECIFICATION
A. Parsing grammar
<entry> ::= <keyword> ":" <addresses> ":" <names> [":" [<cputype>]
[":" [<opsys>] [":" [<protocol list>] ]]] ":"
<addresses> ::= <address> *["," <address>]
<address> ::= <octet> "." <octet> "." <octet> "." <octet>
<octet> ::= <0 to 255 decimal>
<names> ::= <netname> | <gatename> | <domainname> *[","
<nicknames>]
| <official hostname> *["," <nicknames>]
<netname> ::= <name>
<gatename> ::= <hname>
<domainname> ::= <hname>
<official hostname> ::= <hname>
<nickname> ::= <hname>
<protocol list> ::= <protocol spec> *["," <protocol spec>]
<protocol spec> ::= <transport name> "/" <service name>
| <raw protocol name>
B. Lexical grammar
<entry-field> ::= <entry-text> [<cr><lf> <blank> <entry-field>]
<entry-text> ::= <print-char> *<text>
<blank> ::= <space-or-tab> [<blank>]
<keyword> ::= NET | GATEWAY | HOST | DOMAIN
<hname> ::= <name>*["."<name>]
<name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
<cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.
<opsys> ::= ITS | MULTICS | TOPS20 | UNIX...etc.
<transport name> ::= TCP | NCP | UDP | IP...etc.
<service name> ::= TELNET | FTP | SMTP | MTP...etc.
<raw protocol name> ::= <name>
<comment> ::= ";" <text><cr><lf>
<text> ::= *[<print-char> | <blank>]
<print-char> ::= <any printing char (not space or tab)>
since the _ was chosen as nonconflicting, and since you desire to
explain what it is we aren't conflicting with, and since the RFC 1035
language is both non-normative and archaic by inspection, i really think
that 952 is the correct, and only correct, reference to use.
as a side node, RFC 952 permits host names of only 24 characters or
less, including those which have interior periods for RFC 921 purposes.
therefore, a protocol lawyer could say that any name longer than 24
characters, or beginning with a number, was by definition
non-conflicting with RFC 952, and needs no underscore to achieve same. i
do not harbor this view, and i believe that the LEXICAL GRAMMAR section
is more definitional than the ASSUMPTIONS section of RFC 952.
in: 1.2. Scaling Benefits for TXT, SRV, and URI Resource Records
s/SRV,//; S/"SRV",//
OR s/Some resource records are generic and support a variety of
uses.//;
s/Their use can scale poorly.*different uses\.//;
s/increasingly-popular//; s/approach,/approach/
....
it's not increasingly popular, it doesn't scale poorly, and it's not
generic. so you can either remove those descriptions of SRV, or you
can remove SRV as the object of your description, or you can finesse it.
Trying to eliminate the issue entirely, is this sufficient:
<section title="Scaling Benefits">
<t>Some resource record types are used in a fashion that can create
scaling problems, if an entire RRset associated with a domain name is
aggregated in the leaf node for that name. An increasingly-popular
approach, with excellent scaling properties, places the RR under a
node having an underscore-based name, at a defined place in the DNS
tree under the 'parent' name. This constrains the use of particular
<spanx style="verb">RR</spanx> types associated with that parent
name. A direct lookup to the subordinate leaf node produces only the
desired record types, at no greater cost than a typical DNS
lookup.</t>
<t>The definition of a underscore global registry, provided in this
specification, primarily attends to the top-most names used for
coping an RR type; that is the _underscore "global" names. </t>
</section>
it's almost 100% of the way there. but, you should say "places the
RRset" since an RR never travels singly except in zone files, and all
underscore-using applications i know of will accept more than one RR
having the same name, class, and type -- thus, they process RRsets,
which travel as RRsets on the wire, and the fact that an RRset contains
RRs is unimportant in and of itself -- and describing it this way is
confusing. an RRset with one RR may seem to be a degenerate case, but
it's essential (respects law of least astonishment) to think of it that way.
in: 2. DNS Underscore Scoped Entry Registries Function
...
/name space/name space, just as every RR type owns a distinct,
subordinate name space./
An RR type owns a name space? I don't understand what that means or how
it is correct.
While I think I see a computer science basis for saying that an RR type
has a namespace, I'm continuing to find the point more confusing than
helpful, and fear that other readers will, too.
At the least, can you point me to official documents that explain that
view? I've looked around a bit an haven't found such a specification or
discussion.
it only contains a namespace for the purposes of your underscore
registry. no use of _TCP by any other RR type will conflict with the use
of _TCP by SRV, for example. thus, each RR type effectively has its own
registry, whose names need only be unique within that registry. you may
prefer to call it a dictionary rather than a namespace in order to avoid
confusion around what other DNS RFC's call a "namespace".
--
P Vixie
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
