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.

Cheers,


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

> I've created <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/313> to track the design impact of this (both SHOULD and MAY).
> 
> For a starting-point proposal based on discussion below, see:
>  <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1433#file1>
> 
> 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 <http://www.w3.org/mid/228261B5-B508-4FB3-AEC7-F05070FEF442@mnot.net>). 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   http://www.mnot.net/

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