Re: First draft of a list of goals

On Wed, 27 Dec 1995, Jeffrey Mogul wrote:

> 
> Finally, my definition (above) of "valid" could include "the server knows
> that the object will not change before a certain date, and so can
> safely assign a lengthy expiration period."  In the extreme case,

I don't know that the protocol needs to care, but from my experience
with many forms of documents over the years I believe we should
acknowledge that the most important issue with respect to 'staleness'
of a document is the impact on the receiver of incorrect content.

As servers get more sophisticated in their document management model,
expiration will become a more meaningful concept. Some documents
must be current. For many documents, expiration is not a hard date
but rather a general notion something like we know the minimum
review cycle for a updated personnel standard is X days. Hence,
at any qiven point in time the smart server could report an expiration
of NOW+X days unless the document is marked as under review.

Basically, from the protocol perspective, a well formed expiration model
should expect expiration to change without any other change to
the document.  

If we look beyond HTTP 1.1 into the future, we must recognize that 
HTTP caching (client, proxy, mirror) is a form of pretty primative
distributed data base. There has been research and development for
years in that problem domain and not all distributed data base models
insist on exact copies.  As I look forward, I would expect that
caching systems would notify the 'owner' of intent to cache. In that
world, expirations can be safely set for long intervals because the
'owner' can notify caches of changes.  THe cache can then decide to
simply purge the data, pre-fetch frequently referenced data, etc.

Dave Morris

Received on Thursday, 28 December 1995 01:47:19 UTC