Re: [Inip-discuss] Domain Names

[Lyman Chapin <[e-mail]>]

On Jan 10, 2016, at 3:43 PM, Avri Doria wrote:

> Hi,
> 
> Is this a definition specific to the IN class domain name space?

Not at this level - RFC 1034 talks about "parallel" namespaces "[b]ecause we want the name space to be useful in dissimilar
networks and applications" but the definition of the domain name space as a labelled directed rooted tree applies to any class-tagged instantiation of it. It will quickly become specific to the IN class space when we get beyond the label and include the resource records that are also "stored" at each node -

- Lyman

> 
> avri
> 
> On 08-Jan-16 15:20, Warren Kumari wrote:
>> 
>> 
>> On Thu, Jan 7, 2016 at 4:57 PM, Lyman Chapin <[e-mail]
>> <mailto:[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]
>>   <mailto:[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 <http://www.foo.bar.baz.example.com>
>> where the example.com <http://example.com> zonefile is:
>> $ORIGIN example.com <http://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] <mailto:[e-mail]>
>>> https://www.iab.org/mailman/listinfo/inip-discuss
>> 
>>   _______________________________________________
>>   Inip-discuss mailing list
>>   [e-mail] <mailto:[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
>> 
>> 
>> _______________________________________________
>> Inip-discuss mailing list
>> [e-mail]
>> https://www.iab.org/mailman/listinfo/inip-discuss
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> _______________________________________________
> Inip-discuss mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/inip-discuss