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@gmx.de] 
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
    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.

"should" -> "SHOULD


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"


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)


P2, 3.1:

    o  Whether the header field should be preserved across redirects.

"should" -> "ought to"


P2, 4.5.4:

    The 303 status code indicates that the server is redirecting the user
    agent to a different resource, as indicated by a URI in the Location
    header field, that is intended to provide an indirect response to the
    original request.  In order to satisfy the original request, a user
    agent SHOULD perform a retrieval request using the Location URI (a
    GET or HEAD request if using HTTP), which may itself be redirected
    further, and present the eventual result as an answer to the original
    request.  Note that the new URI in the Location header field is not
    considered equivalent to the effective request URI.

"may" -> "can"


P4, 2.4:

       HTTP/1.0 clients and caches might ignore entity-tags.  Generally,
       last-modified values received or used by these systems will
       support transparent and efficient caching, and so HTTP/1.1 origin
       servers still ought to provide Last-Modified values.  In those
       rare cases where the use of a Last-Modified value as a validator
       by an HTTP/1.0 system could result in a serious problem, then
       HTTP/1.1 origin servers should not provide one.

(see http://trac.tools.ietf.org/wg/httpbis/trac/ticket/363)


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"


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"


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"



Feedback appreciated, Julian

Received on Monday, 25 June 2012 15:52:34 UTC