Re: #271: use of "may" and "should"

On 30.06.2012 04:23, James French wrote:
> "shouldn't" is dangerously close, lexically speaking, to "SHOULD 
> NOT",
> and perhaps other phrases would leave a better impression in the
> reader's mind for what is explained by these paragraphs. (e.g. for
> 2.3.3 "Why shouldn't I? Only because I don't NEED to." so we write
> "need not" where we have written "shouldn't." Or, for 2.4 "Why
> shouldn't I? Because I would potentially receive an unusable response
> if the ETag is matched." so we write "would not" where we have 
> written
> "shouldn't")
>
> ----
> jfrench
>
> On Thu, Jun 28, 2012 at 6:34 PM, Mark Nottingham wrote:
>>
>> On 24/06/2012, at 8:18 PM, Julian Reschke wrote:
>>
>>> P6, 2.4:
>>>
>>>   Additionally, a cache can add an If-None-Match header field whose
>>>   value is that of the ETag header field(s) from all responses 
>>> stored
>>>   for the requested URI, if present.  However, if any of the stored
>>>   responses contains only partial content, the cache shouldn't 
>>> include
>>>   its entity-tag in the If-None-Match header field unless the 
>>> request
>>>   is for a range that would be fully satisfied by that stored 
>>> response..
>>>
>>> "shouldn't" -> "SHOULD NOT"
>>
>> Again, this isn't really interop, it's just trying to explain how it 
>> works.

I think this could lead to interop problems though.

If a cache added such an ETag (because for some reason it wanted too 
and is allowed), there is no way it can supply the range needed when all 
the server sends back is 304.

Imagine a client needing bytes 20+ of an object which has bytes 0-15 
cached in a proxy. Server returns 304, and the proxy returns what 
exactly?

For this use-case I'm inclined to think MUST NOT is a good idea. SHOULD 
NOT being acceptible if we have to be loose (I see no reason why we need 
to be loose though).

AYJ

Received on Tuesday, 3 July 2012 01:01:30 UTC