[Inip-discuss] FW: Domain Names

[Edward Lewis <[e-mail]>]

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].
>
>
>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.)