Subject: Re: SHOULD-level requirements in p6-caching

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 Nov 2011 13:08:16 +1100

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/[email-masked]>). 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/

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 5 Nov 2011 08:28:03 +0100

Hi Mark,

On Sat, Nov 05, 2011 at 01:08:16PM +1100, Mark Nottingham wrote:
(...)
> We had a separate discussion about this (starting at <http://www.w3.org/mid/[email-masked]>). I'm still uneasy putting a SHOULD-level requirement in for Warning, given that most implementations don…

My feeling is that if we're certain that we won't break any client by sending
interim 110 responses before the final response, SHOULD is the right wording to
use to promote the new feature. However if we fear that some clients don't
expect an 1xx interim response, then maybe we should use a MAY. I think the
risk is not null, because till now, the only really visible 1xx is 100 which
is exposed only when the client asks for it. I would not be surprised that a
number of crappy package update tools or AV update daemons do not implement
interim responses at all.

Well, I've just tried with wget and it broke. It speaks 1.0 though, so the
client's version could be one condition to add for these interim responses :

  $ wget http://127.1:8000/a
  --2011-11-05 08:21:57--  http://127.1:8000/a
  Resolving 127.1... 127.0.0.1
  Connecting to 127.1|127.0.0.1|:8000... connected.
  HTTP request sent, awaiting response... 110 Response is stale
  2011-11-05 08:22:10 ERROR 110: Response is stale.

  $ nc -lp8000
  GET /a HTTP/1.0
  User-Agent: Wget/1.11.4
  Accept: */*
  Host: 127.1:8000
  Connection: Keep-Alive

  HTTP/1.1 110 Response is stale

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

I'm fine with this too and I don't remember having ever seen a date with
an abnormal case, so Roy is certainly right here.

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

No opinion on this one.

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

That's exactly what I was going to say about the should before I read your
last sentence :-)

Best regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 5 Nov 2011 20:49:50 +1100

Willy,

Again -- this is about Warn-codes, NOT status codes.

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 5 Nov 2011 10:57:25 +0100

> Again -- this is about Warn-codes, NOT status codes.

Arghh... Sorry Mark, I always get trapped in this. I think it's the syntax
which systematically makes me believe it's a status code which indicates
a warning. In fact, taken out of context, it's easy to get fooled I think,
especially since the warn codes cleanly intersect with status codes without
conflict.

Cheers,
Willy