Re: URI-protocol mapping

touch@isi.edu Tue, 25 February 1997 20:08 UTC

Received: from cnri by ietf.org id aa26118; 25 Feb 97 15:08 EST
Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa19866; 25 Feb 97 15:08 EST
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id NAA06334 for uri-out; Tue, 25 Feb 1997 13:48:19 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id NAA06329 for <uri@services.bunyip.com>; Tue, 25 Feb 1997 13:48:16 -0500 (EST)
From: touch@isi.edu
Received: from zephyr.isi.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29865 (mail destined for uri@services.bunyip.com); Tue, 25 Feb 97 13:48:11 -0500
Received: from ash.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id <AA11861>; Tue, 25 Feb 1997 10:48:09 -0800
Date: Tue, 25 Feb 1997 10:48:09 -0800
Posted-Date: Tue, 25 Feb 1997 10:48:09 -0800
Message-Id: <199702251848.AA13026@ash.isi.edu>
Received: by ash.isi.edu (5.65c/4.0.3-6) id <AA13026>; Tue, 25 Feb 1997 10:48:09 -0800
To: touch@isi.edu, liberte@ncsa.uiuc.edu
Subject: Re: URI-protocol mapping
Cc: uri@bunyip.com
X-Auto-Sig-Adder-By: faber@isi.edu
Sender: owner-uri@bunyip.com
Precedence: bulk

> From liberte@sdgmail.ncsa.uiuc.edu Fri Feb 21 08:16:57 1997
> 
> touch@isi.edu 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.

Nope - I was thinking the other way around. That to get to the 
first item you have to have a protocol and a fixed name. More
of a bootstrapping issue, with the observation that the overhead
of changing protocols is of little benefit thereafter.
 
>  > 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?

Precisely that there are many different ways. There should be exactly one.

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

That level, and several others, is equivalent to application layer translation.
There is nothing I can do to prevent that; if it's invisible, I need
never know it, and I should not consider it part of *my* protocol, in
that case.

> 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
... 
> Now let's get rid of the necessary indirection in the URN resolver.

Where do you send the request now?
With what protocol?

THis is the basis of my objection.

Joe
----------------------------------------------------------------------
Joe Touch - touch@isi.edu		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/