Date: Thu, 17 Feb 94 18:03:09 +0100
From: Tim Berners-Lee <timbl@ptpc00.cern.ch>
Message-Id: <9402171703.AA00439@ptpc00.cern.ch>
To: randy@psg.com (Randy Bush)
Subject: Re: caching
I'll pick up Randy and Keith's replies.
> From: randy@psg.com (Randy Bush)
> Date: Wed, 16 Feb 1994 15:41:04 -0800 (PST)
> The point was not support for caching. The point is that some feel that
the
> object which a URN names should be sufficiently stable and unique that an
> entity could fetch it and hold on to it with the presumption that the
object
> would still be a valid referee.
Ah good. In other words, murmuring is not needed as "support for caching"
was never intended. Good. That's clear then.
> The underlying issue is fairly deep and we keep mushing around it without
> being explicit. What is named? A stable object, or a way to get something
> which may differ from request to request?
You are asking, in effect, whether objects are variables or constants.
I strongly beleive that a system which cannot represent variable objects
is not strong enough. (Like trying to program in cpp macros!)
However, as Randy implies, it is really useful to know which you have.
Mail messages, new messages, and the works of Homer are constant.
The weather, the latest URI spec, and the IETF agenda are variables.
The option of giving a URI with a "vary=version" flag in metainformation
about an object in HTTP allows something to be flagged as a variable.
If no "vary" flags are given then a cache, replicator, etc, can use the URI
as a cache index, as the URI must refer to the bit sequence.
An object may have many URIs, with different "vary" properties:
one for the bit stream, and one for "The Illiad" (say) in general.
Conclusion: It is out of the scope of the URN itself to say what its
properties are, but very useful at the URC level.
(I'm equating the
URC level to the headers which come back on an HTTP object, as listed
in
URL: <http://info.cern.ch/hypertext/WWW/Protocols/HTTP/Object_Headers.html>
or as an HTTP header would say,
URI: http://info.cern.ch/hypertext/WWW/Protocols/HTTP/Object_Headers.html
vary=version
The URI filed can give eitehr a URL or a URN -- some of same things
apply)
(BTW: The headers also contain "Expires: <date>" which was put there
to control
caches all the way through gateways, the client software, into the user's
brain. :-) Note, though, that there are two uses of expiry dates
which are overloaded. One is the date at which it may be wise to check
for updates. This never happends for a constant object or LIFN.
The other is a date at which the document will be deleted, cease
to apply, etc -- like announcements
of things which have passed. Constant objects can have one of these.
Is it right to overlay these meanings? Do they boil down to the same
thing? Or is this a blunder in the making?
Answers on a postcard, please, to uri@bunyip.com...)
______________________________________________________
Keith makes the point that URNs are not [unless flagged as in HTTP]
usable as cache indexes. He is right. His argument for "LIFNs"
is fine.
> In a better world, file servers would contain not just the files but also
meta-data
> about each file; such data could include both the content-type of the file,
and a
> location-independent file name (LIFN) for that file.
Yes. This is a better world. However, the URN world is richer still
than that:
the world in which URNs exist does not only have a one to one mapping
of objects to bitstreams, but allows more powerful concepts of objects.
The URN requiremenst allow LIFNs but allows more too. Because the
world is more rich, you have to specify when you in fact have a LIFN.
> 1) Some insist that URNs should refer to something fuzzier than a specific
> pattern of bits. If you ask for a URN, you should get back not a file, but
> some version of that resource -- perhaps translated into a different
> content-type.
Keith, you mention scalability problems in the web ... you are of
course right on all 3 counts, but I'm only talking about URN and
caching in this message.
> Actually, I've always thought that [LIFNs are] what URNs were meant for.
> But all of the
> discussion about what they should look like, instead of what they are to be
used for,
> makes me think that we really don't agree on what URNs are supposed to be
used for.
Karen and Larry are defining what they are supposed to be used for
and I think they have got it right. Let's not sidetrack.
We need what they are making.
Tim