Re: [Inip-discuss] Domain Names

[Avri Doria <[e-mail]>]

Hi,

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

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