Date: Wed, 2 Jun 93 10:54:00 -0400
From: "Chris Weider" <clw@merit.edu>
Message-Id: <9306021454.AA12129@merit.edu>
To: hoymand@joe.uwex.edu, masinter@parc.xerox.com
Subject: URN/URL model and typing
Hi Dirk, Hi Larry....
Let me lay out my basic model of URN and URL operations in the context of
the discussions we've been having, and see if there are any holes or
inconsistencies in it.
The URN is the basic, immutable reference to a resource. This URN is supposed
to be persistent, i.e. if the resource's location changes, the URN does not.
It is also supposed to be time-invariant, and as far as humanly possible
good forever. However, since it is independent of location, is probably
independent of encoding format, etc., we need a way to retrieve the current
location(s) of that object on the net i.e. retrieve information about a
given instantiation of this object on the net. This URN -> URL mapping
is done by some sort of distributed directory service or distributed
database (even perhaps DNS, suitably modified). Peter and I see WHOIS++
doing this. However, as this mapping may be expensive (in time, in dollar
cost, etc) it is probably a good idea to include a set of URLs with the
URN. Other types of metainformation about a given URN may also be cached
locally once the information is retrieved, such as Author Name, etc.
Also, each URL may have some metainformation associated with it, such as
'type' or 'cost' or 'access restrictions'. One feature my model has which I
think is a fairly large bone of contention is that I see the 'type' of an
resource as being more prone to change than the 'location' of the resource.
Thus I claim that the 'location' is a special attribute in the metainformation
and should be segregated, while 'type' is not. Now, as you have pointed out,
Gopher doesn't make that assumption; the 'type' is explicitly coded into
the URL, if you will. So, in my model, the 'type' is initially looked up
with the URL (perhaps we can place this functionality into the Get_URL(URN)
operation) and can be cached with each URL. That's my assumption... rather
than encoding the type, cost, access restrictions, etc, into the URL, I have
it derivable from its location through a directory lookup. Now, that
model has some tradeoffs associated with it, which is why long term I
see the transponder associated with each resource being contacted for all
of this instantiation-specific information.
So, the upshot of all this is that we can cache some of the more transient
information with the URL without encoding it into the URL. I think that
there's a fairly strong argument to be made to actually encode all of this
into a given URL, but I see some more sophisticated techniques
being used in the future. One thing I see down the road is a 'software
server' which can automatically give you an appropriate viewer for a
given set of data if you don't have one already. It could even serve as a
proxy translator; if my local machine doesn't have enough power to
decode an MPEG, or doesn't have enough storage, I can as a proxy to
translate it for me and send me the relevant data.
I hope this doesn't just seem like an intellectual exercise. I'm eager to
get coding on it and see if it works, as soon as we get that 'rough
consensus'.
Chris