Changeset 1675 for draft-ietf-httpbis

Timestamp:

11/06/12 13:29:02 (10 years ago)

Author:

julian.reschke@…

Message:

bcp14 markup (editorial)

Location:

draft-ietf-httpbis/latest

Files:

• p6-cache.html (modified) (7 diffs)
• p6-cache.xml (modified) (2 diffs)

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

@@ -452 +452 @@
   } 
   @bottom-center {
-       content: "Expires December 3, 2012"; 
+       content: "Expires December 13, 2012"; 
   } 
   @bottom-right {
@@ -494 +494 @@
       <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="2012-06-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-06-11">
       <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. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
@@ -520 +520 @@
             </tr>
             <tr>
-               <td class="left">Expires: December 3, 2012</td>
+               <td class="left">Expires: December 13, 2012</td>
                <td class="right">M. Nottingham, Editor</td>
             </tr>
@@ -537 +537 @@
             <tr>
                <td class="left"></td>
-               <td class="right">June 1, 2012</td>
+               <td class="right">June 11, 2012</td>
             </tr>
          </tbody>
@@ -567 +567 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on December 3, 2012.</p>
+      <p>This Internet-Draft will expire on December 13, 2012.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1112 +1112 @@
       </p>
       <p id="rfc.section.2.5.p.3">If the Content-Length, ETag and Last-Modified values of a HEAD response (when present) are the same as that in a selected
-         GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>), the cache SHOULD update the remaining headers in the stored response using the following rules: 
+         GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules: 
       </p>
       <ul>
@@ -1338 +1338 @@
             stale responses.
          </li>
-         <li>If the no-cache response directive specifies one or more field-names, then a cache MAY use the response to satisfy a subsequent
-            request, subject to any other restrictions on caching. However, any header fields in the response that have the field-name(s)
-            listed <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin
+         <li>If the no-cache response directive specifies one or more field-names, then a cache <em class="bcp14">MAY</em> use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, any header fields
+            in the response that have the field-name(s) listed <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin
             server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
          </li>

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

@@ -986 +986 @@
    If the Content-Length, ETag and Last-Modified values of a HEAD response
    (when present) are the same as that in a selected GET response (as per
-   <xref target="caching.negotiated.responses"/>), the cache SHOULD update the
+   <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update the
    remaining headers in the stored response using the following rules:
    <list style="symbols">
@@ -1399 +1399 @@
       have been configured to return stale responses.</t>
       <t>If the no-cache response directive specifies one or more field-names,
-      then a cache MAY use the response to satisfy a subsequent request,
+      then a cache &MAY; use the response to satisfy a subsequent request,
       subject to any other restrictions on caching. However, any header fields
       in the response that have the field-name(s) listed &MUST-NOT; be sent