Re: Confusion about Age: accuracy vs. safety

> Aside from the minor point that you have "demonstrated" no such
> thing (since you almost certainly don't have sufficient data to
> to quantify the amount of overestimation error would be introduced
> by the algorithm in the spec, or to quantify the resultant number
> of cache misses caused by errors of this magnitude), your argument
> is based on a premise that you know to be false, because you insisted
> on its falsity during the design of HTTP/1.1.  To wit: the spec
> explicitly allows your caches to ignore the expiration times (because
> you insisted on this) and, if so, it hardly matters what the Age is.

Okay, what you are saying now is that the actual calculation of Age
is irrelevant because caches will ignore it anyway?  Then why do
we have it in the first place?  The reason is so that caches that WANT
an accurate Age value will get an accurate Age value even in the presence
of clock skew.  An Age value which is consistently overestimated by more
than a few seconds, and always by as much as any single clock skewed
along the route of response, is worthless -- in that situation, we are
better off just relying on the clock.

The requirements regarding revalidation of a stale entity are SHOULD
requirements because that is how the system works.  Browsers have an
option for "never check" because that option is useful to users. 
Cache managers often override the default expiration mechanism for
certain sites (e.g., entertainment sites) because not doing so would
result in a shortage of network bandwidth for those purposes that paid for
that bandwidth.  Making those requirements a MUST would only invalidate
the specification -- it would have no effect on practice.

SHOULD is not the same as MAY, just as telling a programmer that they
SHOULD jump over a cliff is substantially different than telling them
they MAY jump over a cliff.  SHOULD is not a license to ignore the
requirement; it means that there may exist some circumstances wherein
it is necessary (or just better for interoperability) to violate the
requirement.

If Age is broken in practice, then it will be ignored in practice.
This has nothing to do with IETF requirements or what is written down
in any formal spec, it is simply how we all adjust to life. Age does
have a useful purpose -- Koen's idea for the Age header was probably
the best idea to come out of the caching subgroup. However, the whole
idea will be wasted if you insist on breaking the Age calculation by
continuing to misinterpret when the Age header is generated.

What I can't understand is why you are insisting on this misinterpretation.
Koen objected to this way back in April in
<199604081332.PAA04235@wsooti04.win.tue.nl> on http-caching@pa.dec.com.
Even your original summary to the subgroup says
(in <9601222328.AA05142@acetes.pa.dec.com>, 22 Jan 96):

>>(2) clock skew
>>        Koen Holtman has proposed a simple and (with a few
>>        minor modifications) compatible mechanism to avoid
>>        clock skew problems in most cases.  This involves
>>        caches tracking how long they have held onto an
>>        unrefreshed response, and then transmitting this
>>        information in an "Age:" header.  One then computes
>>        the difference between the origin server's Date:
>>        and Expires: headers, then sums all of the Ages
>>        and subtracts that sum from the expiration difference
>>        to decide if the fresh-until time has passed.

This discussion has gone beyond the point of usefulness.  There is only
one way to correctly implement Age, and that is to only add to the Age
value the amount of time that the response has aged within that cache.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 4 September 1996 16:46:51 UTC