- From: James French <jfrench@denirostaff.com>
- Date: Fri, 29 Jun 2012 16:23:04 +0000
- 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 UTC