Re: URI-protocol mapping

[Daniel LaLiberte <[e-mail]>]

[e-mail] writes:
 > At some point you must know
 > 	who you're talking with
 > 	what protocol to use

If you are resolving a URN, you need to do the same thing, as you also
pointed out (i.e. you need a protocol to find out what the protocol is).
And when resolving a URL, you might be given that same information as
a redirection.  Perhaps what you meant to say is:

  At some point, you must know when you have the thing you requested
  rather than an indirection to something else.

BTW, people interested in this subject should read:

  Decoupling the URL Scheme from the Transport Protocol
  http://www.ansa.co.uk/ANSA/ISF/decoupling.html

 > A URL is a context-independent absolute identifier.

Consider all the ways I listed for how URLs can, in fact, be resolved
that make them context dependent and relative.  What is wrong with any
of them?

 > > Certainly one must eventually get down to lower level primitives.
 > > But both URNs and URLs can do that, unless you restrict that URNs
 > > can not do that.
 > 
 > That's what I've been doing - the point is that, at some level, you
 > need the lowest level primitives. What do you call them, if not URLs?

It *is* possible to layer names above locations - this only makes
sense, as we discussed, if you restrict that names *cannot* resolve
directly to the objects but must return a location (or some
indirection).  But my claim is that it is not necessary to do so here
and there is no particular benefit in doing so.

Here are several ways in which a URN can resolve directly to the object.

The first looks almost like what people imagine, but there is an
important distinction from the perspective of the client.  The client
hands off a URN to be resolved by a proxy.  The proxy gets a URL back
and resolves the URL and returns the result to the client.  Note that
the client never saw the URL.

Now let's move that indirection out of the proxy up to the URN
resolver.  The client sends a URN to a URN resolver, but instead of
returning a URL, the URN resolver resolves that URL itself and returns
the result to the client.  The client still never saw the URL, and no
one else but the URL resolver saw the URL. (I can address the
efficiency issue later if you want.)

Now let's get rid of the URL altogether.  The client sends a URN to a
URN resolver.  The URN resolver maps the URN to some
protocol/server/path information (not in a URL), and sends the
appropriate request to the server and returns that result.  Not much
difference - there is no URL, but the equivalent information is used.

Now let's get rid of the necessary indirection in the URN resolver.
What happens if, instead of forwarding a request to another resolver,
the URN resolver does that subsequent resolution itself?  The URN
resolver becomes a document store, but so what?  (They might be very
small documents, after all.)  

You might claim that this loses persistence since the URN resolver
might go away.  But if the URN resolver goes away, *all* resolution
via that resolver would go away, even the URN-to-URL resolution.  You
might claim that the same URN could be resolved by another URN
resolver.  But which URN resolver is that?  There could be hundreds or
thousands.  We're back to guessing.


--
Daniel LaLiberte ([e-mail])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/