W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

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

From: James French <jfrench@denirostaff.com>
Date: Fri, 29 Jun 2012 16:23:04 +0000
Message-ID: <CAD0z36XUmrL-X8yWsLv5LqvKUSc9Uw1Kc8JOrqHN=o2SqHhVHQ@mail.gmail.com>
To: ietf-http-wg@w3.org
"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 <mnot@mnot.net> 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.
>
>
>> 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 Monday, 2 July 2012 16:10:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 July 2012 16:10:46 GMT