Alternatives to "valid: (was Re: First draft of a list of goals)

    hmmm... how about the following terms, used to describe responses:

	original -- exactly what the origin server would say
	fresh -- within the lifetime granted by the origin
		server  (or the client, since a request could
		say "I'm happy with stuff less than 1 hour
		out of date").
	stale -- not fresh. Not authentic. Protocol violation.

The only quibble I have with these terms is that your definition
of "fresh" is procedural, not declarative.  That is, it depends
on how tolerant the client is, not just on how the server wants
to define things.  I think this might make it harder to define
things, especially because I believe that only the "server"
(which includes the software, the database, and its administrator)
really knows whether a "fresh" non-original copy is appropriate
to return.

OK, one more quibble: "authentic" implies a connection with
"authentication", which could be misleading.

So I would modify your suggestion to be simply:
	original -- exactly what the origin server would say
	fresh -- within the lifetime granted by the origin
		server.
	stale -- after the lifetime granted by the origin
		server, and possibly suspect.  

As for client preferences, how about this:
	A client may express a willingness to receive a "stale"
	response, and/or a cache may be configured to return
	"stale" responses
but I would hasten to add certain qualifications (although this
is drifting away from simply defining terms).  For example, we
might insist that a "stale" response be marked as such when it
is returned (perhaps using some flavor of Cache-control header).
This might be done either because the origin server is not responding
to a validation check, or because the proxy administrator has
deemed it preferrable to trade correctness for performance, etc.

In this formulation, "stale" is not a protocol violation, but a
property of a cache entry.  We could debate about whether it is
a protocol violation to return a "stale" response without marking
it as such.

   Note that these describe responses, not entities.

Yes, especially because we will have to include response headers
such as MD5 hash values, etc.

   Many of these mechanisms also assume a global clock.

Or rather, they assume some understanding about the definition
of "lifetime".  I've added this to my list of "issues" for this
subgroup, we'll have to address it at some point.  There has been
a lot of theoretical work about clock synchronization that might
prove helpful here, especially in understanding what is possible.

-Jeff

Received on Wednesday, 27 December 1995 22:37:10 UTC