# caching

Karen R. Sollins (sollins@lcs.mit.edu)
Thu, 17 Feb 94 17:47:20 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: hallam@alws.cern.ch: "Re: caching"
- Previous message: Alexsander Totic: "Re: caching"
- In reply to: Randy Bush: "Re: caching"
- Next in thread: Tim Berners-Lee: "Re: caching"
- Maybe reply: Tim Berners-Lee: "Re: caching"
- Reply: Alexsander Totic: "Re: caching"
- Maybe reply: Alexsander Totic: "Re: caching"
- Maybe reply: hallam@alws.cern.ch: "Re: caching"

    Date: Thu, 17 Feb 94 17:47:20 -0500

    Message-Id: <9402172247.AA00906@zippy.lcs.mit.edu>

    From: Karen R. Sollins <sollins@lcs.mit.edu>

    To: randy@psg.com

    In-Reply-To: Randy Bush's message of Wed, 16 Feb 1994 15:41:04 -0800 (PST) <m0pWvrc-000306C@rip.psg.com>

    Subject: caching

From: Randy Bush <randy@psg.com>
Date: Wed, 16 Feb 1994 15:41:04 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 558

> Can someone please argue for why we should have some support for caching
> in the URN functional spec

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.

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?

Yes, there is a deep question here, or rather a broad question. What
is an "object" or better yet a "resource" in our terms? I believe
strongly that it is not our business to determine or even to have
anything to say about what a resource is other than that it is
something that one of our "customers" (applications using the IIIA) in
collaboration with a naming authority to determine. Lifetimes and
mutability should not be our business. (Some might disagree here.)
What constitutes a long-enough lifetime to merit a global identifier
will be different in different situations. Furthermore, as Peter
Deutsch (and probably others) has said innumerable times, these
identifiers may have a longer lifespan than the resources themselves.
Whether an object is mutable is a matter of perspective. If, between
printings of a book, some spelling corrections are made, do we have
one resource that is mutating slightly (or from some perspectives not
mutating at all since the intellectual content has not changed) and
from others should be distinguishable. What we should be doing is
allowing whoever makes such a determination, to do just that and
represent that determination in some way. We are postulating here
that that can be done by use of URNs.

You are right that we have been "mushing around" here, but you should
see that as a compromise. There are those of us that believe that in
order to provide even some degree of universality, longevity,
evolution, and heterogeneity among applications, we cannot be making
such determinations, but only facilitating them. There are others who
believe that they know all the answers. For example, how does one
determine which object will have a long lifetime? And what do we mean
by a long-lifetime? And how does one define how much a resource can
change before it should be distinguishable from other "versions"? And
of course many other related questions. I have yet to be convinced by
these arguments, but as I said, the hedging is a compromise. Now that
you've identified it, I think we should clear it out.

(In case you can't tell, I'm now trying to duck to avoid the flying
whatevers that will be hurled at me :-)

Thanks for highlighting this issue.

Karen

- Next message: hallam@alws.cern.ch: "Re: caching"
- Previous message: Alexsander Totic: "Re: caching"
- In reply to: Randy Bush: "Re: caching"
- Next in thread: Tim Berners-Lee: "Re: caching"
- Maybe reply: Tim Berners-Lee: "Re: caching"
- Reply: Alexsander Totic: "Re: caching"
- Maybe reply: Alexsander Totic: "Re: caching"
- Maybe reply: hallam@alws.cern.ch: "Re: caching"