Changeset 2247 for draft-ietf-httpbis/latest/p6-cache.xml

Timestamp:

May 8, 2013, 6:06:21 AM (6 years ago)

Author:

mnot@…

Message:

Address editorial feedback from Alex; see #480

File:

• draft-ietf-httpbis/latest/p6-cache.xml (modified) (8 diffs)

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

@@ -204 +204 @@
 </artwork></figure>
 <t>
-   If an implementation receives a delta-seconds value larger than the largest
+   If a cache receives a delta-seconds value larger than the largest
    positive integer it can represent, or if any of its subsequent calculations
    overflows, it &MUST; consider the value to be 2147483648
    (2<x:sup>31</x:sup>). Recipients parsing a delta-seconds value &MUST; use
    an arithmetic type of at least 31 bits of range, and senders &MUST-NOT;
-   send delta-seconds with a value greater than 2147483648.
+   generate delta-seconds with a value greater than 2147483648.
 </t>
 </section>
@@ -246 +246 @@
    The primary <x:dfn>cache key</x:dfn> consists of the request method and
    target URI.  However, since HTTP caches in common use today are typically
-   limited to caching responses to GET, many implementations simply decline
+   limited to caching responses to GET, many caches simply decline
    other methods and use only the URI as the primary cache key.
 </t>
@@ -736 +736 @@
 </t>
 <t>
-   A cache &MUST-NOT; send a stale response if it is prohibited by an
+   A cache &MUST-NOT; generate a stale response if it is prohibited by an
    explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
    directive, a "must-revalidate" cache-response-directive, or an applicable
@@ -760 +760 @@
    an entire response, or a <x:ref>304 (Not Modified)</x:ref> 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
+   response is no longer fresh, the cache &MAY; forward it to the requesting
    client without adding a new <x:ref>Warning</x:ref> (but without removing
    any existing Warning header fields). A cache shouldn't attempt to validate
@@ -845 +845 @@
      &weak-and-strong;), then that strong validator identifies the selected
      representation for update. All of the stored responses with the same
-     strong validator are selected. If none of the stored responses contain
-     the same strong validator, then the new response &MUST-NOT; be used to
+     strong validator are selected. If none of the stored responses contain the
+     same strong validator, then the cache &MUST-NOT; use the new response to
      update any stored responses.
     </t>
@@ -1283 +1283 @@
    &Note; Although it has been back-ported to many implementations, some
    HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache
-   response directives with field-names are often handled by implementations
+   response directives with field-names are often handled by caches
    as if an unqualified no-cache directive was received; i.e., the special
    handling for the qualified form is not widely implemented.
@@ -1367 +1367 @@
    where the response can be stored; it cannot ensure the privacy of the
    message content. Also, private response directives with field-names are
-   often handled by implementations as if an unqualified private directive
+   often handled by caches as if an unqualified private directive
    was received; i.e., the special handling for the qualified form is not
    widely implemented.
@@ -1579 +1579 @@
 <t>
    When the <x:ref>Cache-Control</x:ref> header field is not present in a
-   request, the no-cache request pragma-directive &MUST; have the same effect
-   on caches as if "Cache-Control: no-cache" were present (see <xref
-   target="cache-request-directive" />).
+   request, caches &MUST; consider the no-cache request pragma-directive as
+   having the same effect as if "Cache-Control: no-cache" were present (see
+   <xref target="cache-request-directive" />).
 </t>
 <t>