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

From: James French <[email-masked]>
Date: Fri, 29 Jun 2012 16:23:04 +0000

"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 <[email-masked]> 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/
>
>
>
>

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 03 Jul 2012 13:01:04 +1200

On 30.06.2012 04:23, James French wrote:
> On Thu, Jun 28, 2012 at 6:34 PM, Mark Nottingham wrote:
>>

I think this could lead to interop problems though.

If a cache added such an ETag (because for some reason it wanted too 
and is allowed), there is no way it can supply the range needed when all 
the server sends back is 304.

Imagine a client needing bytes 20+ of an object which has bytes 0-15 
cached in a proxy. Server returns 304, and the proxy returns what 
exactly?

For this use-case I'm inclined to think MUST NOT is a good idea. SHOULD 
NOT being acceptible if we have to be loose (I see no reason why we need 
to be loose though).

AYJ

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Jul 2012 11:26:02 +1000

Hi Amos,

On 03/07/2012, at 11:01 AM, Amos Jeffries wrote:

> If a cache added such an ETag (because for some reason it wanted too and is allowed), there is no way it can supply the range needed when all the server sends back is 304.
> 
> Imagine a client needing bytes 20+ of an object which has bytes 0-15 cached in a proxy. Server returns 304, and the proxy returns what exactly?
> 
> For this use-case I'm inclined to think MUST NOT is a good idea. SHOULD NOT being acceptible if we have to be loose (I see no reason why we need to be loose though).

The original 2616 text was:

>    If any of the existing cache entries contains only partial content
>    for the associated entity, its entity-tag SHOULD NOT be included in
>    the If-None-Match header field unless the request is for a range that
>    would be fully satisfied by that entry.

I agree with your point that this needs to be a requirement. The form "SHOULD NOT ... unless ..." generally means "don't do this unless you meet one of these conditions"; here, it means "don't put an etag on a request when you've cached partial content, unless it covers the whole thing."

So, technically it's correct, but we could make this more clear by rewriting. E.g.,

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

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jul 2012 19:28:34 +0200

On 2012-06-24 12:18, Julian Reschke wrote:
>...

OK, I applied those that were uncontroversial; and for some more I used 
the variants suggested by Björn.

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1707>

This leaves us with two instances of "should not" in P1, and two 
instances of "shouldn't" in P6 which I'll discuss in the follow-up mails.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jul 2012 19:38:30 +0200

On 2012-06-25 00:26, Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:
>> P1, 8.2:
>>
>>     HTTP log information is confidential in nature; its handling is often
>>     constrained by laws and regulations.  Log information needs to be
>>     securely stored and appropriate guidelines followed for its analysis.
>>     Anonymization of personal information within individual entries
>>     helps, but is generally not sufficient to prevent real log traces
>>     from being re-identified based on correlation with other access
>>     characteristics.  As such, access traces that are keyed to a specific
>>     client should not be published even if the key is pseudonymous.
>>
>> "should not" -> "SHOULD NOT"
>
> It seems inconsistent to me make that a SHOULD NOT while keeping the
> "needs to be".

If we elevate "needs to be securely stored" to "SHOULD be securely 
stored" we make many HTTP servers non-compliant, right?

>>     To minimize the risk of theft or accidental publication, log
>>     information should be purged of personally identifiable information,
>>     including user identifiers, IP addresses, and user-provided query
>>     parameters, as soon as that information is no longer necessary to
>>     support operational needs for security, auditing, or fraud control.
>>
>> "should" -> "SHOULD
>
> I think this would have to require minimizing this risk first, other-
> wise there is no requirement if you decide against minimizing it.

Not convinced; what's wrong with saying something like

  "To minimize ... , log information SHOULD be purged of..."?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jul 2012 19:44:45 +0200

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

>>    is for a range that would be fully satisfied by that stored response.
>>

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

>>    response in their shared cache(s) could do so by including

As suggested by Björn I made this "is allowed to".

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Jul 2012 05:08:01 +1000

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

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

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

"""

> As suggested by Björn I made this "is allowed to".

Works for me.

Thanks,