Message-Id: <9310290244.AA05031@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Thu, 28 Oct 1993 22:44:49 -0400
In-Reply-To: Marc Andreessen's message as of Oct 28, 17:15
To: marca@ncsa.uiuc.edu (Marc Andreessen), uri@bunyip.com
Subject: Re: protocol for urn->url
[ You wrote: ]
> I'm a little stunned that it's actually being proposed that a protocol
> NOT be developed/designated for the URN->URL dereferencing process.
Sorry, I certainly didn't want to stun anybody. ;-)
Let's assume that we pick up the naming authority and go
to DNS. Assuming my earlier contrived example of
"URN:ISOC:Deutsch:42", if you're in Gopher, you might
chose to look for a server of the form "gopher.isoc.urn",
(which, if a valid DNS record, might indicate a gopher
server that could handle your request) or a server of the
form "whois.isoc.urn" (which, if a valid DNS record, might
indicate a WHOIS++). It would then be an issue for the
appropriate protocol's community to determine how to handle
such a query (assuming they'd want to tackle the job and
join the race).
Is this any more stunning than saying that we're punting
the entire issue of "sameness" to the naming authority, or
that meta information and typing is not included? Some
people argued for both, but it was decided to avoid
conflict and go for something with unanswered questions
and see how it shakes out.
Having said this, of course, I'd be happy to see WHOIS++
serve as "the" protocol here. I think its data format is
ideal and servers do now exist that are freely available
and could be populated with data now.
> I don't see how the argument for "let the market decide" has any more
> validity here than it would when applied to TCP, IP, FTP, NNTP, or any
> other protocol designed to deliver a specific piece of functionality
> over the network.
But there exist several ways to get a news article, fetch
files and so on, including ftp, nntp, gopher, HTTP and so
on. We live in a multiple protocol world.
> Without a protocol, you have fragmentation and confusion (if even
> that). With a protocol, you have functionality. Isn't that what we
> want?
To me the question was whether the debate to select (or
develop) an appropriate protocol would take longer than
simply allowing Darwinian selection to pick a winner after
a short period of field use among several choices. If the
reaction tonight to my partially tongue-in-cheek proposal
is indicative of the desires of the community at large,
then perhaps I can withdraw my first suggestion and instead
work on making sure WHOIS++ does everything that people
want in this application. I'd be tickled if that's the way
it turns out.
- peterd
--