Re: SHOULD-level requirements in p6-caching

Hi Mark,

On Sat, Nov 05, 2011 at 01:08:16PM +1100, Mark Nottingham wrote:
(...)
> > * 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.

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

> > * 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.

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.

> > * 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.

No opinion on this one.

> > * 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.

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

Best regards,
Willy

Received on Saturday, 5 November 2011 07:28:35 UTC