Re: [Inip-discuss] Domain Names

[Lyman Chapin <[e-mail]>]

On Jan 15, 2016, at 5:43 AM, Olaf Kolkman wrote:

> On 14 Jan 2016, at 15:11, Lyman Chapin wrote:
> 
>>> Hmm… but I thought we were discussing the syntax of the name-space. It seems that we then arrive at 3 things that all hook together: syntax, namespace, and resolution protocol.
>> 
>> 
>> A domain name that identifies a point within the domain name space has a syntax, but the name space itself does not. Syntax is a set of rules that govern the structure of (in this case) domain names - the composition of labels, and how they may be ordered. The domain name space is just a labelled directed rooted tree, a math/graph construct that doesn't have (or need) a syntax. (I apologize for the way in which this sounds "preachy" - I'm just trying to be as precise as possible in the way in which these terms are used.)
> 
>> 
>>> 
>>> The Internet DNS namespace is specifically defined through the resolution system starting at the IANA root. To first approximation it is the hints file used at the resolver that defines the name-space.
>> 
>> 
>> The domain name space is explicitly (going back to RFC 1034) not defined by the DNS resolution system. If it's useful to do so, we can define the "Internet DNS namespace" to be the domain name space overlaid with the semantics expected by the resolution system (servers and resolvers). But that would assume an answer to at least one of the questions we're still discussing: "if it is resolved by something other than the DNS, is it a domain name?"
> 
> Aha…
> 
> I conceptually I always thought there are multiple domain name spaces where each names space is internally consistent (In the context of alternate roots: different root-hints implies different namespace). So for me name-spaces are plural. When you talk about the domain namespace I note you talk about as singular.
> 
> In your definition you say "The domain name space constitutes a labelled directed rooted tree" I guess the specifics of that root are important. I tend to think of my.server.in.my.home as being part of a different name-space as the isoc.org in my email address.
> Both seem to be captured under your definition. Correct?

Yes. Whatever software you use to resolve my.server.in.my.home knows how to do it because it implements the same understanding of the LDRT structure and label syntax of the domain name space as the software that resolves isoc.org. The database that supplies the semantics may be different, but it's the same domain name space - labels have to follow the same rules with respect to allowable characters and length, they have to be ordered in a sequence that represents a directed path to the root, etc.

> So perhaps as a question: Does your definition allow for multiple namespaces, do we want a definition to allow for multiple namespaces.

Not in the sense in which I think you mean "multiple namespaces." When you put "local" or "home" in the TLD position of a domain name, you haven't left the domain name space. What you've done is added some additional semantics to the name - the directive (protocol switch) to resolution software to "do something special" that it wouldn't do otherwise. In the case of "local" or "home," that directive is presumably (in simple terms) "use mDNS". That's not a name space issue, it's a protocol issue.

To avoid duplication I'll pick up from there in my reply to Warren's question "Does this somehow help solve the underlying issues?" -

- Lyman