Re: [Inip-discuss] Domain Names

[Warren Kumari <[e-mail]>]

On Thu, Jan 7, 2016 at 4:57 PM, Lyman Chapin <[e-mail]> wrote:

>
> On Dec 24, 2015, at 11:02 AM, Edward Lewis wrote:
>
> > Acting on Olaf's permission, in trying to prepare another version of my
> > draft.
> >
> > On 12/18/15, 7:05, "Olaf Kolkman" <[e-mail]> wrote:
> >
> >> Feel free to forward to appropriate list.
> >>
> >>
> >> A Domain Name is a sequence of labels concatenated by a designated
> >> separating character.  The Domain Name Space is organized in a strict
> >> hierarchical manner with a recognized root Domain Name.  The
> >> organization follows the rules of tree structure as defined by the
> >> field of graph theory in mathematics [Diestel].
>
> Hi Ed -
>
> In the course of working on another project, I assembled the following
> extended definition of "domain name space" in an attempt to (a) make the
> distinction between "the domain name space" and "domain names" clear, and
> (b) to encourage a bit more precision in the way in which we talk about
> domain names.
>
> -------------------------------
>
> In graph-theoretic terms, the domain name space constitutes a labelled
> directed rooted tree in which the syntax of the label associated with each
> vertex other than the unlabelled root is defined by RFCs 1035, 1123, and
> 2181. The term "nth level domain name label" refers to a member of the set
> of all vertices for which the path to the root contains n edges. For n=1
> the term most often used is "top level domain name label" or simply "top
> level domain" (TLD). A fully qualified domain name is a sequence of labels
> that represents a path from the root to a leaf vertex of the domain name
> space. The shorter term "domain name" is not formally defined; in common
> usage it may be the shorthand equivalent of "fully qualified domain name"
> (FQDN) or refer to any non-empty subset of the sequence of labels formally
> identified by a fully qualified domain name.
>
> In this formulation, the term "domain name space" refers to the complete
> graph consisting of all possible vertices and edges - not just those with
> which a specific meaning has been associated (what we might call
> "allocated" labels). It is a finite graph because the length of the longest
> possible FQDN is finite. At any point in time, there is another labelled
> directed rooted tree - a sub-graph of the domain name space - containing
> only vertices that represent allocated labels.
> ​
>


​
Poking the bear...

​This makes it sound like there is one domain name space of allocated
labels, and a graph with a single root.


This ignores things like:
+------------------+    +------------------+
|     My house     |    |   Your house     |
|                  |    |                  |
|        +-+       |    |        +-+       |
|        |.|       |    |        |.|       |
|        +++       |    |        +++       |
|         |        |    |         |        |
|      +--v--+     |    |      +--v--+     |
|      |local|     |    |      |local|     |
|      +--+--+     |    |      +--+--+     |
|         |        |    |         |        |
|   +-----v----+   |    |   +-----v----+   |
|   | _printer |   |    |   | _printer |   |
|   +----------+   |    |   +----------+   |
+------------------+    +------------------+​

It also ignores:
www.foo.bar.baz.example.com  where the example.com zonefile is:
$ORIGIN example.com.
*   IN A 192.0.2.1

In the first example, the names *do* come from a conceptual single root,
but you end up with 2 disjoint graphs - my .local is not the same as your
.local. While your definition may be technically correct (
https://www.youtube.com/watch?v=hou0lU8WMgo) it seems either incomplete, or
at least folk may be surprised...

In the second example, the "synthesized" vertices created at foo, bar and
baz *could* be claimed to "allocated" labels that exist for a very short
amount of time, but I think that this may be stretching things a bit far...

It feels like this definition works mainly for people who already
understand (and happen to have the same understanding as you and I :-))
what "the domain name space" and "domain names" are.

W




> ​
>
>
> -------------------------------
>
> So mathematically, a domain name is simply a sequence of labels. In most
> of the contexts in which we talk about, write about, or use domain names we
> add representational elements like "top to bottom" or "separating
> character," but those are not properties of a domain name.
>
> Not terribly pragmatic, I know; but it might have a place in your draft -
>
> - Lyman
>
> >>
> >>
> >> That definition covers my street address:
> >>
> >> Olaf Kolkman
> >> Internet Society
> >> 400
> >> Science Park
> >> Netherlands
> >>
> >> I think that the recursive character of a domain from RFC805 should be
> >> part of the definition.
> >
> > This comment hits on the central item in the draft that begs discussion,
> > that is, a definition of Domain Names.
> >
> > There are a few ways to attack the definition, in increasing order of
> > specificity (and perhaps not complete):
> >
> > 1 - The nature of the hierarchical arrangement of domains (embedded in
> the
> > recursive definition in RFC 805). The notion that there is a single root
> > to the tree and domains descend from that.  The notion of "right-to-left"
> > or "left-to-right" is insignificant, "top to bottom" is.  The components
> > of a domain's name are the labels from top to bottom (expressed in
> > whatever order is appropriate for the locality).  The syntax of the
> labels
> > are undefined or rather not specifically defined.  The means to extract
> > information indexed by the domain name is also not specifically defined.
> > Meaning - there has to be some implicit means of determining syntax and
> > resolution process.  Similarly, the management of the domain name is also
> > undefined.
> >
> > 2 - The look of a domain name being a sequence of labels from top to
> > bottom, separated by a dot character. This descends quickly from the
> > architectural plane and comes a long way to what client applications
> (like
> > SSH, FTP, Web Browser) will see from human user input.  The basic
> > definition is tied to ASCII but with punycode, Unicode strings can be
> > mapped in.  There is implicit signaling established for punycode results.
> > What is still a variable are: length of labels, management of labels, and
> > means to resolve.
> >
> > 3 - A definition that is (or starts with) aligned to that of the DNS.
> > There's a syntax defined, both for DNS domain names "on the wire" and in
> > zone file format, which is restricted for an era where acceptable
> > performance assumed fixed or constrained field lengths.  The DNS imposes
> a
> > centralized means of creating and managing names.
> >
> > Of these definitions, the final is the most pragmatic and concrete but
> > perpetuates an ASCII-dominate view of the Internet and is tied to ancient
> > realities of technology.  Personally I don't like that and is why I refer
> > to starting with the DNS definition like "assuming the earth is the
> center
> > of the universe" and then mapping out the other planets' orbits.
> >
> > But, this isn't about defining naming and identifier systems, it is about
> > defining a particular name and identifier system that (continues to)
> > foster reuse of software across various protocols.  Whether there is a
> > line drawn around the collection as "IETF" protocols or not is rather
> > unimportant in so much as it may not be feasible nor desirable to ever
> > draw such a line.
> >
> > Where I see the situation heading is a "clarifications" on the topic.
> The
> > ingredients for a clarification are - lack of a clear definition as
> > evidenced by a plethora of valid interpretations (which my draft has come
> > to build), a specific need to unify the concept to stem or reverse the
> > divergence (the 'crisis' over new entries to the Special-Use Domain Names
> > registry), and a willingness to realize that a clarification is
> inherently
> > a change to the base specification and some backwards compatibility pain
> > will likely be felt.  This latter point is one that has not been reached
> > yet.
> >
> > If we proceed towards a clarification on the topic of Domain Names,
> > whether or not as names and identifiers, the next order of questions to
> > consider includes the next - as one example, but a significant example:
> >
> >> When you say:
> >>
> >> I think, and I mean that as "think", there is a need to find a happy
> >> medium where identifiers can be managed in different ways (DNS hierarchy
> >> and zone admin vs. Tor's cryptographic basis) yet use similar syntax for
> >> the purposes of sharing existing protocols (like HTTP) while using
> >> different resolution processes.
> >>
> >> Then I would agree with you. The requirement that gets out of that is
> >> that there is a requirement to be able to fork the use of that
> identifier
> >> so that the application knows which resolution mechanism to take. Tor
> >> seems to be doing that based on a magic cookie in the form of the TLD
> >> label. Not sure if there are any other ways.
> >
> > There are two ways to determine the means of resolution when given a
> name.
> > One is implicit in the name, using, as an example, the top-level name
> > (note, I don't use top-level domain nor TLD), using that as a switch in
> > software that resolves names.  The other, obviously, is explicit, by
> > building into software knowledge of what kind of name is being handled,
> > e.g., using separate http schemes.
> >
> > Personal opinion of mine feels that explicit means would cause greater
> > disruption than building in an implicit definition.  Explaining this gets
> > into how to solve this as opposed to an architectural discussion, meaning
> > it gets into how client software could be built to add "yet another layer
> > of indirection" when handling the resolution of names.
> >
> > BTW, one implicit way to consider is having the top-level name "looked
> up"
> > within a newer version of a special-use domain names registry.  Limiting
> > the needed lookup key to the top-level name might or might not alleviate
> > concerns over so-called pervasive monitoring.  (I am not sure if that is
> > acceptable.)  Beyond that I can't dream of another scaleable and future
> > proof means, I mean a piece of software would hard-code in the rules for
> > an untra-privacy desiring naming system but that would not be inherently
> > scaleable.
> >
> > (I don't know if extreme privacy can scale well.  One has to be very
> > careful if one wants to be anonymous.)
> > _______________________________________________
> > Inip-discuss mailing list
> > [e-mail]
> > https://www.iab.org/mailman/listinfo/inip-discuss
>
> _______________________________________________
> Inip-discuss mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/inip-discuss
>



-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf