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

On 04/07/2012, at 3:44 AM, Julian Reschke wrote:

> On 2012-06-29 03:34, Mark Nottingham wrote:
>> 
>> On 24/06/2012, at 8:18 PM, Julian Reschke wrote:
>> 
>>> P6, 2.3.3:
>>> 
>>>   If a cache receives a first-hand response (either an entire response,
>>>   or a 304 (Not Modified) response) that it would normally forward to
>>>   the requesting client, and the received response is no longer fresh,
>>>   the cache can forward it to the requesting client without adding a
>>>   new Warning (but without removing any existing Warning header
>>>   fields).  A cache shouldn't attempt to validate a response simply
>>>   because that response became stale in transit.
>>> 
>>> "shouldn't" -> "SHOULD NOT"
>> 
>> I think I prefer the "shouldn't" here; it's not a conformance requirement, but instead simply trying to explain how things work. I.e., this doesn't affect interop.
> 
> It falls under what RFC 2119 calls "to limit behavior which has potential for causing harm (e.g., limiting retransmisssions)".
> 
> That being said; can you propose alternate prose that doesn't use "may/should/must"?

"ought not"? :)


>>> 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.
> 
> True. Can we use "ought", or rephrase to something like
> 
> "However, if any of the stored responses contains only partial content, and the request is for a range that would be fully satisfied by that stored response,  it would be pointless for the cache to include its entity-tag in the If-None-Match header field."

There was subsequent discussion and I think we settled on something along the lines of:

"""
... However, a cache MUST NOT include an entity tag from a stored partial response if that response does not fully satisfy the requested range.
"""

>>> P6, 3.2.3:
>>> 
>>>   For example, consider a hypothetical new response directive called
>>>   "community" that acts as a modifier to the private directive.  We
>>>   define this new directive to mean that, in addition to any private
>>>   cache, any cache that is shared only by members of the community
>>>   named within its value may cache the response.  An origin server
>>>   wishing to allow the UCI community to use an otherwise private
>>>   response in their shared cache(s) could do so by including
>>> 
>>> "may" -> "can"
>> 
>> OK.
> 
> As suggested by Björn I made this "is allowed to".


Works for me.

Thanks,

--
Mark Nottingham   http://www.mnot.net/

Received on Tuesday, 3 July 2012 19:08:29 UTC