Ignore:
Timestamp:
Jul 24, 2010, 1:30:41 AM (10 years ago)
Author:
fielding@…
Message:

(editorial) use might instead of may where it might be confused with MAY

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p6-cache.xml

    r897 r908  
    237237  controls its message storage, retrieval, and deletion. A cache stores cacheable responses
    238238  in order to reduce the response time and network bandwidth consumption on future,
    239   equivalent requests. Any client or server may include a cache, though a cache cannot be
     239  equivalent requests. Any client or server &MAY; employ a cache, though a cache cannot be
    240240  used by a server that is acting as a tunnel.
    241241</t>
    … …  
    262262  <list>
    263263    <t>A response is cacheable if a cache is allowed to store a copy of the response message
    264       for use in answering subsequent requests. Even when a response is cacheable, there may
     264      for use in answering subsequent requests. Even when a response is cacheable, there might
    265265      be additional constraints on whether a cache can use the cached copy to satisfy a
    266266      particular request.</t>
    … …  
    537537  assign an explicit expiration time in the past. This means that the response is always
    538538  stale, so that caches should validate it before using it for subsequent requests.
    539   <cref anchor="TODO-response-stale">This wording may cause confusion, because the response may still be served stale.</cref>
    540 </t>
    541 <t>
    542   Since origin servers do not always provide explicit expiration times, HTTP caches may
    543   also assign heuristic expiration times when they are not specified, employing algorithms that
     539  <cref anchor="TODO-response-stale">This wording might cause confusion, because the response might still be served stale.</cref>
     540</t>
     541<t>
     542  Since origin servers do not always provide explicit expiration times, HTTP caches &MAY;
     543  assign heuristic expiration times when explicit times are not specified, employing algorithms that
    544544  use other header values (such as the Last-Modified time) to estimate a plausible
    545545  expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does
    … …  
    559559</t>
    560560<t>
    561   Additionally, clients may need to influence freshness calculation. They can do this using
     561  Additionally, clients might need to influence freshness calculation. They can do this using
    562562  several request cache directives, with the effect of either increasing or loosening
    563563  constraints on freshness. See <xref target="cache-request-directive" />.
    … …  
    874874</t>
    875875<t>
    876   If (after any normalisation that may take place) a header field is absent
     876  If (after any normalization that might take place) a header field is absent
    877877  from a request, it can only match another request if it is also absent there.
    878878</t>
    … …  
    899899<t>
    900900  If the new response contains an ETag, it identifies the stored 
    901   response to use. <cref anchor="TODO-mention-CL">may need language about Content-Location 
     901  response to use. <cref anchor="TODO-mention-CL">might need language about Content-Location 
    902902  here</cref><cref anchor="TODO-inm-mult-etags">cover case where INM with multiple etags was sent</cref>
    903903</t>
    … …  
    973973<t>
    974974  The presence of an Age header field in a response implies that a response is not
    975   first-hand. However, the converse is not true, since HTTP/1.0 caches may not implement the
     975  first-hand. However, the converse is not true, since HTTP/1.0 caches might not implement the
    976976  Age header field.
    977977</t>
    … …  
    10571057    <t>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In
    10581058      particular, malicious or compromised caches might not recognize or obey this
    1059       directive, and communications networks may be vulnerable to eavesdropping.</t>
     1059      directive, and communications networks might be vulnerable to eavesdropping.</t>
    10601060  </list>
    10611061</t>
    … …  
    11591159      cache, whereas the remainder of the response message &MAY; be.</t>
    11601160    <t>
    1161       <x:h>Note:</x:h> This usage of the word private only controls where the response may
    1162       be stored, and cannot ensure the privacy of the message content.
     1161      <x:h>Note:</x:h> This usage of the word private only controls where the response can
     1162      be stored; it cannot ensure the privacy of the message content.
    11631163      Also, private response directives with field-names are often handled by
    11641164      implementations as if an unqualified private directive was received; i.e.,
    … …  
    12031203    <t>This directive is NOT a reliable or sufficient mechanism for ensuring privacy. In
    12041204      particular, malicious or compromised caches might not recognize or obey this
    1205       directive, and communications networks may be vulnerable to eavesdropping.</t>
     1205      directive, and communications networks might be vulnerable to eavesdropping.</t>
    12061206  </list>
    12071207</t>
    … …  
    14511451  request-headers (e.g., the network address of the client), play a role in the selection of
    14521452  the response representation; therefore, a cache cannot determine whether this response is
    1453   appropriate. The "*" value &MUST-NOT; be generated by a proxy server;
    1454   it may only be generated by an origin server.
     1453  appropriate. The "*" value &MUST-NOT; be generated by a proxy server.
    14551454</t>
    14561455<t>
Note: See TracChangeset for help on using the changeset viewer.