W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: Cache validators

From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
Date: Sun, 10 Mar 1996 20:28:39 -0800
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9603102028.aa22202@paris.ics.uci.edu>
>>    However, I am willing to give-in to that notion IF the opaque
>>    validator is sufficiently useful to cover the cost of sending it.
>>    That is, the opaque validator must be generally interoperable with
>>    existing systems and carry sufficient semantics for use for things
>>    other than cache updates.
> 
> First of all, the generally understood meaning of the word "opaque"
> is "has no meaning to clients", and therefore if you want the
> validator to carry other semantics, you're not talking about an
> "opaque" validator.

Actually, it means "can't see through it" -- it does not mean that
the string cannot hold a given set of semantics.  A validator is
worthless if it doesn't require some mechanism for comparing its
value independent of the source (e.g., byte-equality), since the
source cannot be contacted for all comparisons.

>>    In order to provide that additional usefulness, we need three things:
>>    
>>       1) A guarantee that the validator will change if the content changes
>>	  and should not change if the content remains the same;
>>       2) A guarantee that the validator is byte-comparable (i.e., equal
>>	  validators mean equal content);
>>       3) A guarantee that the validator is world-unique.
>>    
>>    (1) is obvious.
> 
> Not necessarily.  To be useful as a cache validator (unburdened
> by any other semantics), it is sufficient that the value changes
> if the content is semantically different.  It is not necessary
> that the value change on every insignificant change in the content
> (where "significant" is defined by the application that generates
> the content).

I said "additional usefulness".  The particular additional usefulness
I have in mind is for a basic indicator of change which would be usable
for preconditions [i.e., the most often used precondition is
"don't do this if a change has already been made that I don't know about"].
Dual application reduces the cost of implementing both, and I personally
need this functionality more than I need transparent caching.

Since it is unlikely that anyone will ever implement a system which
only changes the validator for "significant" changes, I think it
would be silly to lose the additional functionality gained from a
guaranteed change indicator.

Note also that if we have (1) and (2), we also have a clear algorithm for
constructing a unique ID identical to Content-ID, which would be
useful for gateways and cache tables even if we don't use the Content-ID
syntax of MIME [because we get (3) by combining the validator with the
Request-URI].


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/
Received on Sunday, 10 March 1996 22:59:02 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:48 EDT