Changeset 2247 for draft-ietf-httpbis/latest

Timestamp:

08/05/13 13:06:21 (10 years ago)

Author:

mnot@…

Message:

Address editorial feedback from Alex; see #480

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (14 diffs)
• p6-cache.xml (modified) (8 diffs)

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

@@ -452 +452 @@
   } 
   @bottom-center {
-       content: "Expires November 8, 2013"; 
+       content: "Expires November 9, 2013"; 
   } 
   @bottom-right {
@@ -492 +492 @@
       <link href="p5-range.html" rel="prev">
       <link href="p7-auth.html" rel="next">
-      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.594, 2013/04/30 16:11:28, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.594, 2013/04/30 16:11:28, XSLT vendor: SAXON 9.1.0.8 from Saxonica http://www.saxonica.com/">
       <link rel="schema.dct" href="http://purl.org/dc/terms/">
       <meta name="dct.creator" content="Fielding, R.">
@@ -498 +498 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-05-07">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-05-08">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
@@ -524 +524 @@
             </tr>
             <tr>
-               <td class="left">Expires: November 8, 2013</td>
+               <td class="left">Expires: November 9, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -533 +533 @@
             <tr>
                <td class="left"></td>
-               <td class="right">May 7, 2013</td>
+               <td class="right">May 8, 2013</td>
             </tr>
          </tbody>
@@ -559 +559 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on November 8, 2013.</p>
+      <p>This Internet-Draft will expire on November 9, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -720 +720 @@
       <p id="rfc.section.1.2.1.p.1">The delta-seconds rule specifies a non-negative integer, representing time in seconds.</p>
       <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
-</pre><p id="rfc.section.1.2.1.p.3">If an implementation receives a delta-seconds value larger than the largest positive integer it can represent, or if any of
-         its subsequent calculations overflows, it <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">MUST</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> send delta-seconds with a value greater than 2147483648.
+</pre><p id="rfc.section.1.2.1.p.3">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 <em class="bcp14">MUST</em> consider the value to be 2147483648 (2<sup>31</sup>). Recipients parsing a delta-seconds value <em class="bcp14">MUST</em> use an arithmetic type of at least 31 bits of range, and senders <em class="bcp14">MUST NOT</em> generate delta-seconds with a value greater than 2147483648.
       </p>
       <div id="rfc.iref.c.2"></div>
@@ -737 +737 @@
       <div id="rfc.iref.c.4"></div>
       <p id="rfc.section.2.p.3">The primary <dfn>cache key</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 other methods and use only the URI as the primary cache key.
+         responses to GET, many caches simply decline other methods and use only the URI as the primary cache key.
       </p>
       <p id="rfc.section.2.p.4">If a request target is subject to content negotiation, its cache entry might consist of multiple stored responses, each differentiated
@@ -998 +998 @@
          is not fresh according to the calculations in <a href="#expiration.model" title="Freshness">Section&nbsp;4.1</a>.
       </p>
-      <p id="rfc.section.4.1.4.p.2">A cache <em class="bcp14">MUST NOT</em> send a stale response if it is prohibited by an explicit in-protocol directive (e.g., by a "no-store" or "no-cache" cache
+      <p id="rfc.section.4.1.4.p.2">A cache <em class="bcp14">MUST NOT</em> 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 "s-maxage" or "proxy-revalidate" cache-response-directive;
          see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;7.2.2</a>).
@@ -1008 +1008 @@
       </p>
       <div id="rfc.iref.f.3"></div>
-      <p id="rfc.section.4.1.4.p.5">Note that if a cache receives a <dfn>first-hand</dfn> response (one where the freshness model is not in use; i.e., its age is 0, whether it is an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> 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 <a href="#header.warning" class="smpl">Warning</a> (but without removing any existing Warning header fields). A cache shouldn't attempt to validate a response simply because
+      <p id="rfc.section.4.1.4.p.5">Note that if a cache receives a <dfn>first-hand</dfn> response (one where the freshness model is not in use; i.e., its age is 0, whether it is an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache <em class="bcp14">MAY</em> forward it to the requesting client without adding a new <a href="#header.warning" class="smpl">Warning</a> (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.
       </p>
@@ -1047 +1046 @@
       <ul>
          <li>If the new response contains a <dfn>strong validator</dfn> (see <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), 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 <em class="bcp14">MUST NOT</em> be used to update any stored responses.
+            strong validator are selected. If none of the stored responses contain the same strong validator, then the cache <em class="bcp14">MUST NOT</em> use the new response to update any stored responses.
          </li>
          <li>If the new response contains a weak validator and that validator corresponds to one of the cache's stored responses, then
@@ -1259 +1258 @@
       <p id="rfc.section.7.2.2.2.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>
       <p id="rfc.section.7.2.2.2.p.5"> <b>Note:</b> 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 as if an unqualified no-cache directive
-         was received; i.e., the special handling for the qualified form is not widely implemented.
+         Also, no-cache 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.
       </p>
       <p id="rfc.section.7.2.2.2.p.6"> <b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
@@ -1294 +1293 @@
       <p id="rfc.section.7.2.2.6.p.4">The field-names given are not limited to the set of header fields defined by this specification. Field names are case-insensitive.</p>
       <p id="rfc.section.7.2.2.6.p.5"> <b>Note:</b> This usage of the word "private" only controls 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 was received; i.e., the special handling for the qualified form is not widely implemented.
+         content. Also, private response directives with field-names are 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.
       </p>
       <p id="rfc.section.7.2.2.6.p.6"> <b>Note:</b> This directive uses the quoted-string form of the argument syntax. Senders <em class="bcp14">SHOULD NOT</em> use the token form (even if quoting appears not to be needed for single-entry lists).
@@ -1400 +1399 @@
   <a href="#header.pragma" class="smpl">pragma-directive</a> = "no-cache" / <a href="#header.pragma" class="smpl">extension-pragma</a>
   <a href="#header.pragma" class="smpl">extension-pragma</a> = <a href="#imported.abnf" class="smpl">token</a> [ "=" ( <a href="#imported.abnf" class="smpl">token</a> / <a href="#imported.abnf" class="smpl">quoted-string</a> ) ]
-</pre><p id="rfc.section.7.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, the no-cache request pragma-directive <em class="bcp14">MUST</em> have the same effect on caches as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
+</pre><p id="rfc.section.7.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, caches <em class="bcp14">MUST</em> consider the no-cache request pragma-directive as having the same effect as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;7.2.1</a>).
       </p>
       <p id="rfc.section.7.4.p.5">When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control:

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>