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

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"?

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

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

Best regards, Julian

Received on Tuesday, 3 July 2012 17:45:18 UTC