validators (was: Re: Koen's comments on...)

> 
> Jeffrey Mogul:
> [...requiring headers not absolutelty necessary...]
> >This is a similar misunderstanding as the one related to a cache's
> >choice of a Fresh-until value where none is specified.
> >
> >Let me make it QUITE clear (since I have obviously failed to do so)
> >that I am not trying to make any extra work for service authors.
> >My expectation is that in almost all cases, the server implementor
> >will choose a simple and unmodifiable algorithm for generating
> >Cache-validator: values, and the service author (or system
> >administrator will never have to think about them).
> Koen Holtman:
> Extra work that can be automated is still extra work, because the
> automation also takes work.  What guarantees can you give me that this
> work will be done?  Again, let me repeat:
>   
>    I can't guarantee that the zero default collapse scenario outlined
>    in my earlier message _will_ happen, but I see no justification for
>    taking such a risk.
> 
> [...]
> >So, to restate things as clearly as possible: NO SERVICE AUTHOR
> >NEED EVER CARE ABOUT THIS.
> 
> I include special-purpose http server authors and CGI script authors
> in the group of service authors, and they _will_ need to care.
> 
> [...]
> >    >what [should] a client
> >    >do if a server doesn't provide one?  (Revert to GET I-M-S?)
> >    
> >    Yes.
> >
> >I'm comfortable with this, as long as it is made an absolutely
> >mandatory part of the specification that all HTTP/1.1 clients
> >and caches completely and properly implement the opaque-validator
> >mechanism.  That is, if the server does supply an opaque validator,
> >then the clients and caches MUST use it instead of a Last-modified
> >date (in order to claim compliance with HTTP/1.1).  If you'll agree
> >to this requirement, I'd be willing to make it optional for servers
> >to generate Cache-validator: headers.
> 
> I agree to that requirement.  Does this mean we now have consensus
> that opaque validators are not required every 1.1 response?

Hmmm. We have more options than opaque validators.

			-----                validators           --------------
			opaque/sequence timestamp crc's/checksums digests/hashes
			numbers					  signatures

clock skew immunity	+		-		+		+

data corruption detect.	-		-		+		+

Location misuse		?		-		?		+

freshness check		+		+?		+		+
*using HEAD from orig server

ease of implementation	+		+		-		--
computing costs

chunked transfer	+		+		-		-

cache integrity		-		-		+		++

freshness comparison	-/+		+?		-		-
between caches

I hope the above table summarises briefly pluses and minuses.

I think we should support any of them, and data owners /service authors can
choose the appropriate validators for a particular URL.

The prioritised list is: digest checksum opaque timestamp.

I propose the following matrix for compliance:

			digest	crc	opaque	timestamp
	servers		may	may	should	should
	clients		may	may	must	must

(servers must generate timestamps or opaque validators if appropriate for the
data, clients must support both timestamps and opaque validators)


If I'm too terse, just ask why, but I expect everybody considered these.

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Thursday, 11 January 1996 06:28:46 UTC