Message-Id: <9408122131.AA24027@ulua.hal.com>
To: ccoprmm@oit.gatech.edu (Michael Mealling)
Subject: Re: URN server?
In-Reply-To: Your message of "Fri, 12 Aug 1994 15:19:18 EDT."
<199408121919.AA29357@oit.gatech.edu>
Date: Fri, 12 Aug 1994 16:31:36 -0500
From: "Daniel W. Connolly" <connolly@hal.com>
In message <199408121919.AA29357@oit.gatech.edu>, Michael Mealling writes:
>Aaron C. Coday said this:
>> Does anyone have a prototype URN server up? I've been following
>> the list for awhile, but havne't seen mention of one. I'd like to play
>> around with such a server.
>
>I have a prototype one with version of Mosaic that will resolve URNs in
>HTML and give you the one or more URLs. I have some modifications to
>make during the next few weeks but I plan on distributing the mods before
>the end of this month.
Is it reasonable to use the "NNN Redirected" feature of HTTP to
impement this sort of thing? That might work with existing clients.
Somebody said that WWW clients should have a configuration option
where any URI with an unknown scheme gets sent to a proxy HTTP gateway.
So it looks like this:
user invokes client with URI_PROXY = http://proxy.host/
client sees: <a href="urn://ietf/rfc/822">rfc822</a>
client doesn't grok urn:, so it connects to proxy.host:80, sends:
GET urn://ietf/rfc/822 HTTP/1.0
server resolves urn locally or via peer servers.
Server may return:
(1) a redirection response, indicating the client should,
for example, fetch ftp://ds.internic.net/rfc/rfc822.txt
(2) a URC, perhaps in the form of an HTML document, that gives
the title, author, pub date, and several pointers to existing
copies
(3) the text of the document that it has fetched on behalf
of the client
Hmmm... I would want to be able to tell which of (2) or (3) is happening,
and I don't see where to put that info...
Hmmm^2... I don't think folks are going to start marking up documents
using <a href="urn:...">, cuz it won't work in most places. They might
use <a href="http:..." urn="URN:..."> cuz that would (1) work today,
and (2) work tomorrow when the http: address is stale, and the URN:
services are deployed.
I don't mean to advocate making HTTP the protocol for all purposes,
but it is widely deployed, and it seems to me that any TCP based
URN->URL resolution service can easily be merged into HTTP without
breaking things.
The interesting thing will be integrity, reliability, privacy, and
confidentiality features. At the very least, there should be some
parameter that allows the client to say "I'll take any document that
you can guarantee is less than N seconds out of date" to allow
caching. Of course, this assumes an underlying model of computation,
i.e. some definition of what the "right answer" is.
When we get to high performance, datagram-based name services, then
we need to start looking for new protocols. Prospero comes to mind...
Dan