Re: SHOULD-level requirements in p6-caching

I'm going to mark this as incorporated in -17; see specific notes for what was outstanding below (effectively, they're all 'no change'). As always, feedback appreciated.


On 02/09/2011, at 12:33 PM, Mark Nottingham wrote:

> I've created <> to track the design impact of this (both SHOULD and MAY).
> For a starting-point proposal based on discussion below, see:
>  <>
> Outstanding bits:
> * All of the SHOULDs related to Warning (including one to inform users). We need to discuss this.

We had a separate discussion about this (starting at <>). I'm still uneasy putting a SHOULD-level requirement in for Warning, given that most implementations don't do it, but I'm not going to lie down in the road about it.

> * Roy recently added some requirements to the freshness algorithm (sourced from p1 date, I think):
>>     <t>HTTP/1.1 clients and caches &SHOULD; assume that an RFC-850 date
>>        which appears to be more than 50 years in the future is in fact
>>        in the past (this helps solve the "year 2000" problem).</t>
>>     <t>Although all date formats are specified to be case-sensitive, 
>>        recipients &SHOULD; match day, week and timezone names
>>        case-insensitively.</t>
> I think these should be MUSTs for interop.

Talked to Roy, who pointed out that we have MUST for producers, which should be good enough for interop.

> * There's still a SHOULD around only-if-cached. My take is that only-if-cached support is spotty in implementations, and has become a de facto optional feature of HTTP caching. Therefore, we should downgrade this to prose, or make it a MAY.

Looking at this again, I think SHOULD strikes the right balance; so, proposal is for no change.

> * I'm still undecided about "A server SHOULD include a Vary header...". See below for background discussion.

Looking at this, I was thinking of adding a clause that said something like "... unless the consequences of omitting it are understood." 

However, that's what 2119 SHOULD means, so maybe the best thing here is no change.

Mark Nottingham

Received on Saturday, 5 November 2011 02:09:19 UTC