Message-Id: <QgoNV163LE06MFHExh@saintjoe.edu>
Date: Fri, 29 Oct 1993 17:25:05 -0500 (CDT)
From: Brian Capouch <brianc@saintjoe.EDU>
To: uri@bunyip.com
Subject: Dreams for Houston
I've been silently following this thread for the past month, as things
have heated up in preparation for the Houston meeting. I wrote a sample
URN/URL resolution server suite last spring, and have been watching the
things you all have been discussing to see what's applicable/not
applicable in the model I chose. Following are some issues that I hope
we will address in Houston. It's not entirely clear to me that all of
these questions have been addressed in the dialogues of the past few
weeks.
1. Retrofitting existing clients and servers
I would assume that the existing base of objects that are being served
by the various http, gopher, ftp, etc., servers are all going to be
retrofitted with URNs in the early, formative days of URN usage. Is the
scheme that gets adopted going to permit easy incorporation into the
various clients (it's not necessary, as far as I can see, to have the
servers know much about URNs) in an expeditious and painless fashion?
This leads to a second question, which is, what do we think the URN is
going to look like, embedded into something such as an HTML page? Will
it augment the URL, or *replace* it entirely? Or exist within the
document in some new sort of syntactic structure? Given the heavy use
that gopher and xmosaic have been "enjoying," I would think that we'd
look to those clients to provide us our first real practice in seeing
how the various concepts will fly.
2. Making the model explicit
I wonder if there's going to be a single resolution model (as distinct
from protocol) that can be assumed by all parties to be the "canonical"
way of dereferencing a URN. I'm going to assume that URN->URL mapping
servers will (soon?) be found running on virtually every machine that
serves up objects to clients on the net. Even if the protocol wars
don't result in a clear winner, I hope I can assume that the same
underlying client-server interaction model will be adopted ubiquitously.
This model will probably have to include interactions designed to
update mapping information for a variety of relationships: "I serve the
resource, I map the URN; I serve the resource, machine xyz does the
mapping; etc." Keeping everything in synch, and especially, discovery
that a URN has become abandoned, should be part of any robust model we
concoct.
3. Identifying a pilot exercise that can be quickly undertaken
I get the distinct feeling that a lot of people are just going to start
doing something they feel to be right if we can't rather quickly give
them some kind of direction about what's going to emerge from our
deliberations. I'd love for us to assign URN Serial Number One (and I'm
only being partly facetious) during the meeting, ideally to the URN RFC
itself. That will give us at least one *real* thing to play with. I
think a lot of entities would come out of the woodwork to register URNs
pretty quickly once their design is set, and that's not to mention the
herculean proof of concept that will result from the retrofitting
mentioned in #1 above. Or don't we think that retrofitting is going to
be part of the picture?
Can't wait to see how these things will wash out. . .
Brian