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/
- Re: URI-protocol mapping Ron Daniel Jr.
- Re: URI-protocol mapping Daniel LaLiberte
- Re: URI-protocol mapping touch