headers
Julian Reschke | 24 Jun 2012 12:18
Picon
Picon

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

P1, 2.1:

       Note: The term 'user agent' covers both those situations where
       there is a user (human) interacting with the software agent (and
       for which user interface or interactive suggestions might be made,
       e.g., warning the user or given the user an option in the case of
       security or privacy options) and also those where the software
       agent may act autonomously.

"may" -> "can"

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"

    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.
(Continue reading)

Permalink | Reply |
headers
Bjoern Hoehrmann | 25 Jun 2012 00:26
Picon

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

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

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

>P2, 2.2.1:
>
(Continue reading)

Permalink | Reply |
headers
Julian Reschke | 3 Jul 2012 19:38
Picon
Picon

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

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-
(Continue reading)

Permalink | Reply |
headers
Musatov, Martin - CW | 25 Jun 2012 17:51
Favicon

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

"Can" is the most common for asking for, giving or refusing permission:
"May" formal way to ask for or give permission:
"Should" is clearly not neutral and implies "proper"

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@...] 
Sent: Sunday, June 24, 2012 5:19 AM
To: HTTP Working Group
Subject: #271: use of "may" and "should"

P1, 2.1:

       Note: The term 'user agent' covers both those situations where
       there is a user (human) interacting with the software agent (and
       for which user interface or interactive suggestions might be made,
       e.g., warning the user or given the user an option in the case of
       security or privacy options) and also those where the software
       agent may act autonomously.

"may" -> "can"

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
(Continue reading)

Permalink | Reply |
headers
Mark Nottingham | 29 Jun 2012 03:34
Favicon
Gravatar

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.
(Continue reading)

Permalink | Reply |
headers
Julian Reschke | 3 Jul 2012 19:44
Picon
Picon

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
(Continue reading)

Permalink | Reply |
headers
Mark Nottingham | 3 Jul 2012 21:08
Favicon
Gravatar

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


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

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

"ought not"? :)

>>> P6, 2.4:
>>>
(Continue reading)

Permalink | Reply |
headers
Julian Reschke | 3 Jul 2012 19:28
Picon
Picon

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

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
Permalink | Reply |

Gmane