Draft: draft-ietf-dnsop-terminology-bis-latest

Commentary: Split into two pairs of commits ( each first changing content and then line lengths ) for easy partial acceptance , should that be desired : Improve grammar and diction Be consistent about ordering domain name labels from the root The second pair attempts to provide a consistent treatment of " domain name " as an abstract sequence of labels in directed graph order starting at the root , while maintaining clarity about wire , presentation , and common display formats rendering domain names in reverse .
Note that this list is a small subset of facets that people have
identified over time for naming systems, and the IETF has yet to
agree on a good set of facets that can be used to compare naming
systems.  For example, other facets might include "protocol to
update data in a name", "privacy of names", and "privacy of data
associated with names", but those do not not have a clear
definitions as the ones listed above.  The list here is chosen
because it helps describe the DNS and naming systems similar to
the DNS.
Note that this list is a small subset of facets that people have
identified over time for naming systems, and the IETF has yet to
agree on a good set of facets that can be used to compare naming
systems.  For example, other facets might include "protocol to
update data in a name", "privacy of names", and "privacy of data
associated with names", but those are not as well-defined as the
ones listed above.  The list here is chosen because it helps
describe the DNS and naming systems similar to the DNS.
Note that this is a definition independent of the DNS RFCs, and
the definition here also applies to systems other than the DNS.
RFC1034 defines the "domain name space" using mathematical trees
and their nodes in graph theory, and the definition in RFC1034 has
the same practical result as the definition here.  Using graph
theory, a domain name is a list of labels identifying a portion
along one edge of an acyclic directed graph.  A domain name can be
relative to other parts of the tree, or it can be fully qualified
(in which case, it ends at the common root of the graph).
Note that this is a definition independent of the DNS RFCs, and
the definition here also applies to systems other than the DNS.
RFC1034 defines the "domain name space" using mathematical trees
and their nodes in graph theory, and the definition in RFC1034 has
the same practical result as the definition here.  Using graph
theory, a domain name is a list of labels identifying a portion
along one edge of a directed acyclic graph.  A domain name can be
relative to other parts of the tree, or it can be fully qualified
(in which case, it begins at the common root of the graph).
Composition of names -- A name in the global DNS has one or more
labels.  The length of each label is between 0 and 63 octets
inclusive.  In a fully-qualified domain name, the first label
(logically speaking) is 0 octets long; it is the only label whose
length may be 0 octets, and it is called the "root" or "root
label".  A domain name in the global DNS has a maximum total
length of 255 octets in the wire format; the root represents one
octet for this calculation.
Composition of names -- A name in the global DNS has one or more
labels.  The length of each label is between 0 and 63 octets
inclusive.  In a fully-qualified domain name, the first label in
the ordered list is 0 octets long; it is the only label whose
length may be 0 octets, and it is called the "root" or "root
label".  A domain name in the global DNS has a maximum total
length of 255 octets in the wire format; the root represents one
octet for this calculation.
The basic wire format for names in the global DNS is a list of
labels with the root label last.  Each label is preceded by a
length octet.  RFC1035 also defines a compression scheme that
modifies this format.
The presentation format for names in the global DNS is a list of
labels, encoded as ASCII, with the root label last, and a "."
character between each label.  In presentation format, a fully-
qualified domain name includes the root label and the associated
separator dot.  In presentation format, a fully-qualified domain
name with two additional labels is always shown as "example.tld."
instead of "example.tld".  RFC1035 defines a method for showing
octets that do not display in ASCII.
The common display format is used in applications and free text.
It is the same as the presentation format, but showing the root
label and the "." before it is optional and is rarely done.  In
common display format, a fully-qualified domain name with two
additional labels is usually shown as "example.tld" instead of
"example.tld.".  Names in the common display format are normally
written such that the first label in the ordered list is in the
last position from the point of view of the directionality of the
writing system (so, in both English and C the first label is the
right-most label; but in Arabic it may be the left-most label,
depending on local conventions).
The basic wire format for names in the global DNS is a list of
labels ordered by decreasing distance from the root, with the root
label last.  Each label is preceded by a length octet.  RFC1035
also defines a compression scheme that modifies this format.
The presentation format for names in the global DNS is a list of
labels ordered by decreasing distance from the root, encoded as
ASCII, with a "." character between each label.  In presentation
format, a fully-qualified domain name includes the root label and
the associated separator dot (for example, in presentation format,
a fully-qualified domain name with two non-root labels is always
shown as "example.tld." instead of "example.tld").  RFC1035
defines a method for showing octets that do not display in ASCII.
The common display format is used in applications and free text.
It is the same as the presentation format, but showing the root
label and the "." before it is optional and is rarely done (for
example, in common display format, a fully-qualified domain name
with two non-root labels is usually shown as "example.tld" instead
of "example.tld.").  Names in the common display format are
normally written such that the directionality of the writing
system presents labels by decreasing distance from the root (so,
in both English and C the first label in the ordered list is
right-most; but in Arabic it may be left-most, depending on local
conventions).
This is often just a clear way of saying the same thing as "domain
name of a node", as outlined above.  However, the term is
ambiguous.  Strictly speaking, a fully qualified domain name would
include every label, including the final, zero-length label of the
root: such a name would be written "www.example.net." (note the
terminating dot).  But because every name eventually shares the
common root, names are often written relative to the root (such as
"www.example.net") and are still called "fully qualified".  This
term first appeared in RFC0819.  In this document, names are often
written relative to the root.
This is often just a clear way of saying the same thing as "domain
name of a node", as outlined above.  However, the term is
ambiguous.  Strictly speaking, a fully qualified domain name would
include every label, including the zero-length label of the root:
such a name would be written "www.example.net." (note the
terminating dot).  But because every name eventually shares the
common root, names are often written relative to the root (such as
"www.example.net") and are still called "fully qualified".  This
term first appeared in RFC0819.  In this document, names are often
written relative to the root.
The need for the term "fully qualified domain name" comes from the
existence of partially qualified domain names, which are names
where some of the right-most names are left off and are understood
only by context.
The need for the term "fully qualified domain name" comes from the
existence of partially qualified domain names, which are names
where one or more of the earliest labels in the ordered list are
omitted (for example, "www").  Such relative names are understood
only by context.
A stealth server that is a master for zone transfers.  "In this
arrangement, the master name server that processes the updates is
unavailable to general hosts on the Internet; it is not listed in
the NS RRset."  (Quoted from RFC6781, Section 3.4.3.)  An earlier
RFC, RFC4641, said that the hidden master's name appears in the
SOA RRs MNAME field, although in some setups, the name does not
appear at all in the public DNS.  A hidden master can be either a
secondary or a primary master.
A stealth server that is a primary server for zone transfers.  "In
this arrangement, the master name server that processes the
updates is unavailable to general hosts on the Internet; it is not
listed in the NS RRset."  (Quoted from RFC6781, Section 3.4.3).
An earlier RFC, RFC4641, said that the hidden master's name
"appears in the SOA RRs MNAME field", although in some setups, the
name does not appear at all in the public DNS.  A hidden master
can also be a secondary server itself.