I think its possible I'm arguing off to the side Ed. But, there was a
scoping quality in domain, as applied to domain names, which is pretty
"big" in my opinion. Its analogous to the ordering issues in fully
qualified (relative) distinguished names in X.500. The order of elements of
Surname= Given= Generational-Qualifier= were perhaps moot, but the nesting
qualities of C= and O= and OU= were not. It was pretty clear (mistakenly?)
to me that you might be able to re-order the S/G/GQ elements in a wildcard
match inside some O=/OU= local context, but searching for all CN=*Smith* at
the C= level was going to be a hard ask.

So this quality of the word 'domain' is not in my mind, just hand waving.
Its innate. The decision to make the dot separator function as both a label
boundary, and potentially a zone-cut, has consequences. a putative FQDN is
like a Relative Distinguished name, except you can't know where the
zone-cut is a-priori, until you get some information back.

AppleTalk names were interesting, structured. They got some ideas from VMS
(or seemed to) which I suspect also were ideas out of Tops-10 and other
places about how you name things according to symbolic types and syntaxes.
DNS names were almost syntax free, with just three rules of significance
here

1) they order L to R. They nest.
2) the dot is a boundary, but not all dots are zone-cuts
3) there were limits on length

Does anyone else find themselves reaching into long term storage over
things like symbolic links with computed values? SunOS and the architecture
${cpu} in the symlink so it was computed on-the-fly to find your
/usr/local/${arch}/bin path in NFS?

DNS didn't do that. there is no my.dom.$intermediate.ain capability in the
name model.

And that kind of quality, rule 1) -they nest, is what the "D" in DNS means.

To me, its not incidental. Its core. If they don't obey the nesting
functions of Domains, they aren't domain-names.

On Fri, Sep 18, 2015 at 11:04 AM, Edward Lewis <edward.le...@icann.org>
wrote:

> On 9/18/15, 9:54, "Alec Muffett" <al...@fb.com> wrote:
>
>
> I feel this may need clarification in your section on Tor addressing.
> Perhaps it's not **really** domain-naming, but it **looks** much more like
> it.
>
>
> The first point of the document is to allow us to answer that "perhaps" -
> without a definition of Domain Names, we don't know.  The question includes
> - are "Domain Names" just things that look like something  or are they
> things that have a lot of baggage (such as means of assignment [which is
> different between DNS and distributed hash tables]).
>
> I'm not disagreeing, just underlining that until the definition is in
> place, it's hard for me to be in complete agreement.
>
>
> Also, there is some information which requires correction:
>
> According to an email message, ".onion" names may (in the future)
>
> exceed the length limits of a label imposed on DNS domain names,
> reaching 64, 80, or more bytes. [DNSOP1]
>
>
> Per this e-mail:
>
> https://www.ietf.org/mail-archive/web/ietf/current/msg94362.html
>
> ...from Nick Mathewson at Tor, he says:
>
> So it's IMO fine to say ".onion addresses are case-insensitive and
> will comply with existing DNS limitations for label lengths (63) and
> maximum fqdn lengths (253ish)".
>
> Which contradicts draft-lewis-domain-names-00
>
>
> So - and not to be pointed - but in your email I reference, should I
> ignore that for the sake of this document?  I mean what the message says
> seems to contradict what you are quoting from Mathewson - which is fine -
> but this is something unclear to me.
>
> (I wasn't aware of Mathweson's message, I'm not subscribed to that list.)
>
>
> Also, my name's not "Alex" :-)
>
>     - alec
>
>
> I got 75% of the name right. ;)  Sorry about that - I don't read all the
> letters on a page.
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to