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:
>
>    New method definitions need to indicate whether they are safe
>    (Section 2.1.1), what semantics (if any) the request body has, and
>    whether they are idempotent (Section 2.1.2).  They also need to state
>    whether they can be cached ([Part6]); in particular what conditions a
>
>missing "under"?
>
>    cache may store the response, and under what conditions such a stored
>    response may be used to satisfy a subsequent request.
>
>"may" -> "MAY"

As far as I can tell, this is reflecting on options offered elsewhere,
it does not provide such options itself, so it's a "can", not a "MAY".

>P2, 2.3.8:
>
>    Similar to a pipelined HTTP/1.1 request, data to be tunneled from
>    client to server MAY be sent immediately after the request (before a
>    response is received).  The usual caveats also apply: data may be
>    discarded if the eventual response is negative, and the connection
>    may be reset with no response if more than one TCP segment is
>    outstanding.
>
>"may" -> "might" (twice)

(This is saying more "these are valid options" than "it is possible for
that to happen", so more "can" than "might", as far as I am concerned.)

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

This is more an "is allowed to".
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Sunday, 24 June 2012 22:27:38 UTC