Re: LAST CALL on MAX-AGE issue

Looks good to me.

....Roy

In message <9707190116.AA23026@acetes.pa.dec.com>, Jeffrey Mogul writes:
>(1) I think this note (in Roy's proposal)
>
>     Note: An origin server wishing to use a relatively new HTTP cache
>     control feature, such as the "private" directive, on a network
>     that includes older caches which do not understand that feature,
>     will need to combine the new feature with an old Expires value
>     in order to prevent the older caches from caching the response.
>
>could be made slightly clearer:
>
>     Note: An origin server wishing to use a relatively new HTTP cache
>     control feature, such as the "private" directive, on a network
>     including older caches that do not understand that feature, will
>     need to combine the new feature with an Expires field whose value
>     is less than or equal to the Date value.  This will prevent older
>     caches from improperly caching the response.
>
>(2) I think it would be a good idea to include after the last
>paragraph of this section (14.9.3):
>
>   If a cache returns a stale response, either because of a max-stale
>   directive on a request, or because the cache is configured to
>   override the expiration time of a response, the cache MUST attach a
>   Warning header to the stale response, using Warning 10 (Response is
>   stale).
>
>the following note:
>
>       Note: A cache may be configured to return stale responses
>       without validation, but only if this does not conflict with any
>       MUST-level requirements concerning cache validation (e.g., a
>       "must-revalidate" Cache-control directive).
>    
>In a private email discussion during March, Roy pointed out that
>this is said elsewhere in the specification.  However, I'm concerned
>that some implementors may misconstrue the discussion in 14.9.3
>without such a reminder.
>
>-Jeff
>