Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

[Edward Lewis <[e-mail]>]

On 12/4/15, 22:44, "DNSOP on behalf of John Levine"
<[e-mail] on behalf of [e-mail]> wrote:

>It occurs to me that there's a difference between local and localhost
>on the one hand and onion on the other.  With local and localhost, you
>still something like an A or AAAA record with an an IP address that
>you can use in the normal way to open a connection.
>
>With onion you get a rather different thing that looks like an open
>TCP connection, a couple of levels up the protocol stack.  So if the
>theory is that these special names are doing a protocol switch, it's
>not one switch, it's potentially a switch per name.  I suppose you
>could say there's yet another switch for test, example, and invalid
>that returns failure at whatever level of the stack you try.
>
>I'm not sure if that makes the discussion notably more complicated
>but it certainly doesn't make it any simpler.

I think this slices the problem space in two incorrect ways.

First, given an identifier, it's not always an address you want.

Second, the purpose of an identifier is access information about an
object.  If the information is an address, how that address is reached is
beyond the scope of the identifier within the context of resolving then
name.

What I'm leading to is, it doesn't matter to a naming system that Tor will
route packets one way or another, that's up to the forwarding code to
determine.  I might get a 32 bit numeric value understood to be a IPv4
address for a mDNS name or for a Tor name when I am done resolving the
name.  The code that used the mDNS name will then open a channel to that
address for the purposes of doing what it wants to do, the code that
accessed the Tor name will, well, do the same.

This isn't all about addresses though.  Identifiers can be used to refer
to an object in physical space to grab stored data about it, stored in a
database.

There's talk about protocol switches.  I think that's a misnomer.  There
are resolution switches.  I see a lot of utility in it being the top-level
name in a Domain Name.  (I'm not ready to say that's the best way to go.)
The alternative is to have the resolution method identified in meta- or
ancillary- information, like the schema of a URL (http://).  Doesn't the
HTTP:// definition though allow the "authority name" to be anything that
looks like a host or domain name but doesn't have to be a DNS name?
That's what makes me prefer the in-name implicit way of identifying the
resolution method.

(Sorry for handwaving while trying to work on a detailed document to
prevent the need from handwaving.  But it seems more convenient to respond
this way.)

Every name/identifer space has to live in a context.  There are way more
identifiers than objects because of differing perspectives or contexts.
Contexts can overlap, e.g., one context could be all protocols (and
applications built on them) related to the IETF.  A list of IETF protocols
would be rather impossible to make, too long, too many gray areas, etc.,
but then again, the list doesn't have to be a firm boundary for what uses
a set of identifiers.  So long as the "client/initiator" and the
"server/recevier" of the identifier agree on the context, they'll get by.