Message-Id: <9402242335.AA12964@expresso.bunyip.com>
From: Peter Deutsch <peterd@bunyip.com>
Date: Thu, 24 Feb 1994 18:35:04 -0500
In-Reply-To: Mitra's message as of Feb 24, 21:32
To: mitra@pandora.sf.ca.us (Mitra), <uri@bunyip.com>
Subject: A couple of comments for the list...
Hi all,
My apologies for my extended silence on this list (and I
can imagine what some of you will respond to _that_!) but
things are _real_ busy here at Bunyip Central right now
and I've not had the time needed to compose half-reasoned
replies to what I see going by. I _am_ reading all this
material even if I don't have a moment free to participate
and in general I'm not offended by what I'm seeing at all.
I take this as a sign that we're potentially looking at
looming "rough consensus". Oh, that it be so! :-)
A couple of quick comments:
I _would_ caution against anyone trying to convince
themselves that what we're doing is defining _the_
mechanisms for all of this at this point. I see us having
to try out several different approaches over the next
little while to gain some operational experience and in the
process I think we'll do several things. For example, I
expect we'll either prove the nay-sayers right or wrong
about whether DNS can handle the load, whether WHOIS++
will ever become widely deployed, or whether X.500 will
ever reach critical mass, etc. Hopefully we'll also get
enough operational experience with URNs that we can decide
with a little more authority how they should look, how they
should be deployed and used, etc.
Looking back in hindsight it is my humble opinion that we
tried to freeze URLs too soon. In doing so, I think there
was some confusion, for example, between issues of
architecture and issues of implementation. Our lack of
experience and thus lack of a clear consensus resulted in
somewhat greater delay in getting people to sign on than
might otherwise have been the case.
Also, I think we could have done with a little more
operational experience from other development projects
before we froze that particular spec, and we saw some of
the side-effects of that in such things as the debate over
readability/transcribability/etc, the debate over the news
and FTP URLs, and whether we needed a URL that was more
"script-like" for accessing active services. None of these
things led to the end of the world, but I'd like to see us
avoid the lengthy and bitter process we went through last
time if we can manage it.
What this means in practice is that I'd like to see a
couple of different URN approaches tried at the same time,
with a clear understanding that what we're after is some
field trials and operational experience and this will not
lead to cries of "established user base" if the community
wants to change things afterwards. We're certainly
standing by to put hooks into archie to support URNs and
we're now actively testing our multiple collection version
(with an index of gopherspace, among other things) so from
our point of view now is a very good time to look at
extensions that will give us all some field experience.
We'll be looking for ideas from the community at the next
IETF as we're ready to move on this now.
Also, here's one quick comment on the "finding URN->URL servers"
thread I'd like to toss out for consideration. I'm quite
happy to see the DNS/TXT record approach used to find an
appropriate server although I agree with what I perceive
to be the consensus that DNS shouldn't be used for the actual
dereferencing query itself.
To me this decoupling of server discovery from URN access
allows one very important characteristic which I'd like to
see. It allows us to independently work on resource
discovery and access technologies to give us a better
chance of getting both right.
In practice this means that if you already know where you
want to go to ask your question (eg. you've cached the
server address, you've used your favorite Yellow Pages
service which has a searchable index, somebody comes up
with DNS++, etc) you need not bother DNS's pretty little
head at all. You just go off and ask your question to the
URN server and you're done.
I'd like to see us create multiple resource discovery
channels, independent of the choice of URN->URL protocol
and each having its own advantages and disadvantages. We
could then turn them on and wait to see which one ends up
the most successful. I think this approach would be a
"Good Thing (tm)".
I'm also happy to see any one of several database query
protocols used to do the dereference, at least in the
short term, to allow for Darwinian selection here, too. I
happen to like WHOIS++ in this application (surprise! :-)
but I'm certainly not going to push it as _the_ answer
right now. Let's try out a few approaches and see which
works best in the field.
I want this stuff working as much as anyone right now, but
I think we need some operational experience with _several_
different likely contenders this time, and we need it
_before_ we start on the final draft of the specifications
doc. In the long run, I think we'll get through the whole
process a lot faster if we do it this way.
- peterd
--
---------------------------------------------------------------------------
"The future belongs to neither the conduit or content players, but
those who control the filtering, searching and sense-making tools
we will rely on to navigate through the expanses of cyberspace."
- Paul Saffo, (_Wired_: March,1994)
---------------------------------------------------------------------------