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

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.


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


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

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

Received on Friday, 29 June 2012 01:35:18 UTC