Ignore:
Timestamp:
Jul 30, 2010, 6:06:01 PM (9 years ago)
Author:
fielding@…
Message:

Replace lowercase should with less normative words, where possible.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p6-cache.xml

    r965 r969  
    280280   <list>
    281281      <t>The time at which the origin server intends that a representation
    282       should no longer be returned by a cache without further validation.</t>
     282      no longer be returned by a cache without further validation.</t>
    283283   </list>
    284284</t>
     
    566566<t>
    567567   If an origin server wishes to force a cache to validate every request, it
    568    can assign an explicit expiration time in the past. This means that the
    569    response is always stale, so that caches should validate it before using it
    570    for subsequent requests. <cref anchor="TODO-response-stale">This wording
    571    might cause confusion, because the response might still be served
    572    stale.</cref>
     568   can assign an explicit expiration time in the past to indicate that the
     569   response is already stale.  Compliant caches will validate the cached response
     570   before reusing it for subsequent requests.
    573571</t>
    574572<t>
     
    17411739</t>
    17421740<t>
    1743    The HTTP Cache Directive Registry should be created at <eref
     1741   The HTTP Cache Directive Registry shall be created at <eref
    17441742   target="http://www.iana.org/assignments/http-cache-directives"/> and be
    17451743   populated with the registrations below:
     
    18171815  The Message Header Field Registry located at <eref 
    18181816  target="http://www.iana.org/assignments/message-headers/message-header-index.html" />
    1819   should be updated with the permanent registrations below (see <xref target="RFC3864" />):
     1817  shall be updated with the permanent registrations below (see <xref target="RFC3864" />):
    18201818</t>
    18211819<?BEGININC p6-cache.iana-headers ?>
     
    18811879   on the cache can reveal information long after a user believes that the
    18821880   information has been removed from the network. Therefore, cache contents
    1883    should be protected as sensitive information.
     1881   need to be protected as sensitive information.
    18841882</t>
    18851883</section>
Note: See TracChangeset for help on using the changeset viewer.