Re: Proposal for i23: no-store invalidation

On 11/06/2009, at 8:00 AM, Henrik Nordstrom wrote:
>
> The tricky part is defining "indicates the resource have changed" I
> guess,

... I think this issue is related in no small way:
   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/110

> Been reading the specs again, and in "RFC2616 13.1.1 Cache  
> Correctness"
> the condition of receiving a newer response where a previous  
> response is
> in the cache seems to be specified at only a MAY level, implying that
> it's fine for the cache to keep the previous response as "current" for
> as long as it's fresh. I could not find the corresponding section in
> httpbis-p6. If it's really the intention that caches only MAY replace
> the previous response with the newer response in the cache storage  
> then
> there is also no need for the invalidation requirements in the HEAD or
> caching of negotiated resources sections to be any stronger than a  
> MAY.

Yes; as mentioned before, the concept of "cache correctness" was  
dropped from p6, because it didn't add any binding requirements, and  
it was fuzzy at best anyway. If you think something was lost, please  
say so...

Which requirements are you referring to when you say "caching of  
negotiated resources sections"?

Cheers,


--
Mark Nottingham     http://www.mnot.net/