(Message HTTP-TOEDIT:576)
Return-Path: mogul@pa.dec.com
Received: by zorch.w3.org; id AA00987; Mon, 3 Mar 1997 13:49:25 -0500
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by www10.w3.org (8.7.5/8.7.3) with SMTP id NAA17778 for <jg@w3.org>; Mon, 3 Mar 1997 13:49:20 -0500 (EST)
Received: from acetes.pa.dec.com by mail1.digital.com (5.65 EXP 4/12/95 for V3.2/1.0/WV)
	id AA18604; Mon, 3 Mar 1997 10:44:24 -0800
Received: by acetes.pa.dec.com; id AA04301; Mon, 3 Mar 97 10:44:23 -0800
Message-Id: <9703031844.AA04301@acetes.pa.dec.com>
To: Larry Masinter <masinter@parc.xerox.com>
Cc: jg@w3.org, mogul@pa.dec.com
Subject: Re: [Fwd: Re: Cache-Control directive, semantics] 
In-Reply-To: Your message of "Sun, 02 Mar 97 09:02:23 PST."             <3319C0AF.1DA@parc.xerox.com> 
Date: Mon, 03 Mar 97 10:44:23 PST
From: Jeffrey Mogul <mogul@pa.dec.com>

    I didn't see this in your issues list, but this is at least
    an editorial if not a semantic issue about clarifying the
    apparent contradiction between 14.9.4 and 14.8.
    
I believe this one is subsumed by the proposal for proxy-maxage
(draft-mogul-http-revalidate-00.txt).

Embedded in that proposal is a requirement that

            The
            proxy-maxage directive also implies the semantics
            of the proxy-revalidate directive (see section
            14.9.4), i.e., that the proxy MUST NOT use the
            entry after it becomes stale to respond to a
            subsequent request without first revalidating it
            with the origin server.  The proxy-maxage directive
            is always ignored by an end-client.
 
If this proposal is adopted, then the discrepancy between 14.8
and 14.9.4 is trivially resolved, by changing this (from 14.8)

     1. If the response includes the "proxy-revalidate" Cache-Control
        directive, the cache MAY use that response in replying to a
        subsequent request, but a proxy cache MUST first revalidate it with
        the origin server, using the request-headers from the new request
        to allow the origin server to authenticate the new request.

to read

     1. If the response includes the "proxy-maxage" Cache-Control
        directive, the cache MAY use that response in replying to a
        subsequent request, but (if the specified maximum age has
	passed) a proxy cache MUST first revalidate it with
        the origin server, using the request-headers from the new request
        to allow the origin server to authenticate the new request.
	(This is the defined behavior for proxy-maxage.)
	If the response includes "proxy-maxage=0", the proxy MUST
	always revalidate it before re-using it.

Maybe you should press for last call on the proxy-maxage proposal?
Since nobody has objected so far, my next draft of the hit-metering
proposal is also predicated on proxy-maxage being part of HTTP/1.1.

-Jeff