Changeset 500 for draft-ietf-httpbis

Timestamp:

04/03/09 07:40:49 (13 years ago)

Author:

julian.reschke@…

Message:

sync P1-P5/P7 from latest, re-gen HTML

Location:

draft-ietf-httpbis/latest-roy

Files:

• p1-messaging.html (modified) (5 diffs)
• p1-messaging.xml (modified) (3 diffs)
• p2-semantics.html (modified) (9 diffs)
• p2-semantics.xml (modified) (6 diffs)
• p3-payload.html (modified) (2 diffs)
• p3-payload.xml (modified) (1 diff)
• p4-conditional.html (modified) (1 diff)
• p5-range.html (modified) (1 diff)
• p6-cache.html (modified) (19 diffs)
• p7-auth.html (modified) (1 diff)

draft-ietf-httpbis/latest-roy/p1-messaging.html

@@ -471 +471 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">March 2, 2009</td>
+            <td class="header right">March 4, 2009</td>
          </tr>
       </table>
@@ -1378 +1378 @@
       </dl>
       <p id="rfc.section.5.1.2.p.18">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status if the received request-target
-         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 Request-target Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
       <p id="rfc.section.5.1.2.p.19">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more OCTETs.
@@ -2649 +2649 @@
       <div id="rfc.figure.u.65"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
 
-<a href="#abnf.dependencies" class="smpl">Cache-Control</a> = &lt;Cache-Control, defined in [Part6], Section 3.4&gt;
+<a href="#abnf.dependencies" class="smpl">Cache-Control</a> = &lt;Cache-Control, defined in [Part6], Section 15.4&gt;
 <a href="#chunked.transfer.encoding" class="smpl">Chunked-Body</a> = *chunk last-chunk trailer-part CRLF
 <a href="#header.connection" class="smpl">Connection</a> = "Connection:" OWS Connection-v
@@ -2673 +2673 @@
 <a href="#rule.whitespace" class="smpl">OWS</a> = *( [ obs-fold ] WSP )
 
-<a href="#abnf.dependencies" class="smpl">Pragma</a> = &lt;Pragma, defined in [Part6], Section 3.4&gt;
+<a href="#abnf.dependencies" class="smpl">Pragma</a> = &lt;Pragma, defined in [Part6], Section 15.4&gt;
 
 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( [ obs-fold ] WSP )
@@ -2704 +2704 @@
  ] )
 
-<a href="#abnf.dependencies" class="smpl">Warning</a> = &lt;Warning, defined in [Part6], Section 3.6&gt;
+<a href="#abnf.dependencies" class="smpl">Warning</a> = &lt;Warning, defined in [Part6], Section 15.6&gt;
 
 <a href="#uri" class="smpl">absolute-URI</a> = &lt;absolute-URI, defined in [RFC3986], Section 4.3&gt;

draft-ietf-httpbis/latest-roy/p1-messaging.xml

@@ -4436 +4436 @@
 <x:ref>BWS</x:ref> = OWS
 
-<x:ref>Cache-Control</x:ref> = &lt;Cache-Control, defined in [Part6], Section 3.4&gt;
+<x:ref>Cache-Control</x:ref> = &lt;Cache-Control, defined in [Part6], Section 15.4&gt;
 <x:ref>Chunked-Body</x:ref> = *chunk last-chunk trailer-part CRLF
 <x:ref>Connection</x:ref> = "Connection:" OWS Connection-v
@@ -4460 +4460 @@
 <x:ref>OWS</x:ref> = *( [ obs-fold ] WSP )
 
-<x:ref>Pragma</x:ref> = &lt;Pragma, defined in [Part6], Section 3.4&gt;
+<x:ref>Pragma</x:ref> = &lt;Pragma, defined in [Part6], Section 15.4&gt;
 
 <x:ref>RWS</x:ref> = 1*( [ obs-fold ] WSP )
@@ -4491 +4491 @@
  ] )
 
-<x:ref>Warning</x:ref> = &lt;Warning, defined in [Part6], Section 3.6&gt;
+<x:ref>Warning</x:ref> = &lt;Warning, defined in [Part6], Section 15.6&gt;
 
 <x:ref>absolute-URI</x:ref> = &lt;absolute-URI, defined in [RFC3986], Section 4.3&gt;

draft-ietf-httpbis/latest-roy/p2-semantics.html

@@ -468 +468 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">March 2, 2009</td>
+            <td class="header right">March 4, 2009</td>
          </tr>
       </table>
@@ -592 +592 @@
                      <li class="tocline1">8.4.13&nbsp;&nbsp;&nbsp;<a href="#status.412">412 Precondition Failed</a></li>
                      <li class="tocline1">8.4.14&nbsp;&nbsp;&nbsp;<a href="#status.413">413 Request Entity Too Large</a></li>
-                     <li class="tocline1">8.4.15&nbsp;&nbsp;&nbsp;<a href="#status.414">414 Request-target Too Long</a></li>
+                     <li class="tocline1">8.4.15&nbsp;&nbsp;&nbsp;<a href="#status.414">414 URI Too Long</a></li>
                      <li class="tocline1">8.4.16&nbsp;&nbsp;&nbsp;<a href="#status.415">415 Unsupported Media Type</a></li>
                      <li class="tocline1">8.4.17&nbsp;&nbsp;&nbsp;<a href="#status.416">416 Requested Range Not Satisfiable</a></li>
@@ -825 +825 @@
        / "412"  ; <a href="#status.412" id="rfc.xref.status.412.1" title="412 Precondition Failed">Section&nbsp;8.4.13</a>: Precondition Failed
        / "413"  ; <a href="#status.413" id="rfc.xref.status.413.1" title="413 Request Entity Too Large">Section&nbsp;8.4.14</a>: Request Entity Too Large
-       / "414"  ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 Request-target Too Long">Section&nbsp;8.4.15</a>: Request-target Too Long
+       / "414"  ; <a href="#status.414" id="rfc.xref.status.414.1" title="414 URI Too Long">Section&nbsp;8.4.15</a>: URI Too Long
        / "415"  ; <a href="#status.415" id="rfc.xref.status.415.1" title="415 Unsupported Media Type">Section&nbsp;8.4.16</a>: Unsupported Media Type
        / "416"  ; <a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section&nbsp;8.4.17</a>: Requested range not satisfiable
@@ -1386 +1386 @@
       <div id="rfc.iref.56"></div>
       <div id="rfc.iref.s.33"></div>
-      <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a>&nbsp;<a id="status.414" href="#status.414">414 Request-target Too Long</a></h3>
+      <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h3>
       <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the request-target is longer than the server is willing to interpret.
          This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long
@@ -1904 +1904 @@
                <tr>
                   <td>414</td>
-                  <td>Request-target Too Long</td>
-                  <td> <a href="#status.414" id="rfc.xref.status.414.2" title="414 Request-target Too Long">Section&nbsp;8.4.15</a> 
+                  <td>URI Too Long</td>
+                  <td> <a href="#status.414" id="rfc.xref.status.414.2" title="414 URI Too Long">Section&nbsp;8.4.15</a> 
                   </td>
                </tr>
@@ -2251 +2251 @@
 <a href="#abnf.dependencies" class="smpl">Accept-Language</a> = &lt;Accept-Language, defined in [Part3], Section 5.4&gt;
 <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a> = &lt;Accept-Ranges, defined in [Part5], Section 5.1&gt;
-<a href="#abnf.dependencies" class="smpl">Age</a> = &lt;Age, defined in [Part6], Section 3.1&gt;
+<a href="#abnf.dependencies" class="smpl">Age</a> = &lt;Age, defined in [Part6], Section 15.1&gt;
 <a href="#header.allow" class="smpl">Allow</a> = "Allow:" OWS Allow-v
 <a href="#header.allow" class="smpl">Allow-v</a> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
@@ -2312 +2312 @@
 <a href="#header.user-agent" class="smpl">User-Agent-v</a> = product *( RWS ( product / comment ) )
 
-<a href="#abnf.dependencies" class="smpl">Vary</a> = &lt;Vary, defined in [Part6], Section 3.5&gt;
+<a href="#abnf.dependencies" class="smpl">Vary</a> = &lt;Vary, defined in [Part6], Section 15.5&gt;
 
 WWW-Authenticate =
@@ -2519 +2519 @@
                   <li class="indline1">412 Precondition Failed (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.412.1">4</a>, <a class="iref" href="#rfc.iref.54"><b>8.4.13</b></a>, <a class="iref" href="#rfc.xref.status.412.2">10.2</a></li>
                   <li class="indline1">413 Request Entity Too Large (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.413.1">4</a>, <a class="iref" href="#rfc.iref.55"><b>8.4.14</b></a>, <a class="iref" href="#rfc.xref.status.413.2">10.2</a></li>
-                  <li class="indline1">414 Request-target Too Long (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.56"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li>
+                  <li class="indline1">414 URI Too Long (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.56"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li>
                   <li class="indline1">415 Unsupported Media Type (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.415.1">4</a>, <a class="iref" href="#rfc.iref.57"><b>8.4.16</b></a>, <a class="iref" href="#rfc.xref.status.415.2">10.2</a></li>
                   <li class="indline1">416 Requested Range Not Satisfiable (status code)&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.416.1">4</a>, <a class="iref" href="#rfc.iref.58"><b>8.4.17</b></a>, <a class="iref" href="#rfc.xref.status.416.2">10.2</a></li>
@@ -2761 +2761 @@
                         <li class="indline1">412 Precondition Failed&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.412.1">4</a>, <a class="iref" href="#rfc.iref.s.31"><b>8.4.13</b></a>, <a class="iref" href="#rfc.xref.status.412.2">10.2</a></li>
                         <li class="indline1">413 Request Entity Too Large&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.413.1">4</a>, <a class="iref" href="#rfc.iref.s.32"><b>8.4.14</b></a>, <a class="iref" href="#rfc.xref.status.413.2">10.2</a></li>
-                        <li class="indline1">414 Request-target Too Long&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.s.33"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li>
+                        <li class="indline1">414 URI Too Long&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.414.1">4</a>, <a class="iref" href="#rfc.iref.s.33"><b>8.4.15</b></a>, <a class="iref" href="#rfc.xref.status.414.2">10.2</a></li>
                         <li class="indline1">415 Unsupported Media Type&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.415.1">4</a>, <a class="iref" href="#rfc.iref.s.34"><b>8.4.16</b></a>, <a class="iref" href="#rfc.xref.status.415.2">10.2</a></li>
                         <li class="indline1">416 Requested Range Not Satisfiable&nbsp;&nbsp;<a class="iref" href="#rfc.xref.status.416.1">4</a>, <a class="iref" href="#rfc.iref.s.35"><b>8.4.17</b></a>, <a class="iref" href="#rfc.xref.status.416.2">10.2</a></li>

draft-ietf-httpbis/latest-roy/p2-semantics.xml

@@ -556 +556 @@
        / "412"  ; <xref target="status.412"/>: Precondition Failed
        / "413"  ; <xref target="status.413"/>: Request Entity Too Large
-       / "414"  ; <xref target="status.414"/>: Request-target Too Long
+       / "414"  ; <xref target="status.414"/>: URI Too Long
        / "415"  ; <xref target="status.415"/>: Unsupported Media Type
        / "416"  ; <xref target="status.416"/>: Requested range not satisfiable
@@ -1662 +1662 @@
 </section>
 
-<section title="414 Request-target Too Long" anchor="status.414">
-  <iref primary="true" item="414 Request-target Too Long (status code)" x:for-anchor=""/>
-  <iref primary="true" item="Status Codes" subitem="414 Request-target Too Long" x:for-anchor=""/>
+<section title="414 URI Too Long" anchor="status.414">
+  <iref primary="true" item="414 URI Too Long (status code)" x:for-anchor=""/>
+  <iref primary="true" item="Status Codes" subitem="414 URI Too Long" x:for-anchor=""/>
 <t>
    The server is refusing to service the request because the request-target
@@ -2402 +2402 @@
    </c>
    <c>414</c>
-   <c>Request-target Too Long</c>
+   <c>URI Too Long</c>
    <c>
       <xref target="status.414"/>
@@ -3213 +3213 @@
 <x:ref>Accept-Language</x:ref> = &lt;Accept-Language, defined in [Part3], Section 5.4&gt;
 <x:ref>Accept-Ranges</x:ref> = &lt;Accept-Ranges, defined in [Part5], Section 5.1&gt;
-<x:ref>Age</x:ref> = &lt;Age, defined in [Part6], Section 3.1&gt;
+<x:ref>Age</x:ref> = &lt;Age, defined in [Part6], Section 15.1&gt;
 <x:ref>Allow</x:ref> = "Allow:" OWS Allow-v
 <x:ref>Allow-v</x:ref> = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
@@ -3274 +3274 @@
 <x:ref>User-Agent-v</x:ref> = product *( RWS ( product / comment ) )
 
-<x:ref>Vary</x:ref> = &lt;Vary, defined in [Part6], Section 3.5&gt;
+<x:ref>Vary</x:ref> = &lt;Vary, defined in [Part6], Section 15.5&gt;
 
 WWW-Authenticate =
@@ -3322 +3322 @@
 </artwork></figure></section>
 
-
 <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
 

draft-ietf-httpbis/latest-roy/p3-payload.html

@@ -475 +475 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">March 2, 2009</td>
+            <td class="header right">March 4, 2009</td>
          </tr>
       </table>
@@ -1749 +1749 @@
 <a href="#header.content-type" class="smpl">Content-Type-v</a> = media-type
 
-<a href="#abnf.dependencies" class="smpl">Expires</a> = &lt;Expires, defined in [Part6], Section 3.3&gt;
+<a href="#abnf.dependencies" class="smpl">Expires</a> = &lt;Expires, defined in [Part6], Section 15.3&gt;
 
 <a href="#abnf.dependencies" class="smpl">Last-Modified</a> = &lt;Last-Modified, defined in [Part4], Section 6.6&gt;

draft-ietf-httpbis/latest-roy/p3-payload.xml

@@ -2667 +2667 @@
 <x:ref>Content-Type-v</x:ref> = media-type
 
-<x:ref>Expires</x:ref> = &lt;Expires, defined in [Part6], Section 3.3&gt;
+<x:ref>Expires</x:ref> = &lt;Expires, defined in [Part6], Section 15.3&gt;
 
 <x:ref>Last-Modified</x:ref> = &lt;Last-Modified, defined in [Part4], Section 6.6&gt;

draft-ietf-httpbis/latest-roy/p4-conditional.html

@@ -464 +464 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">March 2, 2009</td>
+            <td class="header right">March 4, 2009</td>
          </tr>
       </table>

draft-ietf-httpbis/latest-roy/p5-range.html

@@ -464 +464 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">March 2, 2009</td>
+            <td class="header right">March 4, 2009</td>
          </tr>
       </table>

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

@@ -465 +465 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">March 2, 2009</td>
+            <td class="header right">March 4, 2009</td>
          </tr>
       </table>
@@ -523 +523 @@
          <li class="tocline0">2.&nbsp;&nbsp;&nbsp;<a href="#caching.overview">Cache Operation</a><ul class="toc">
                <li class="tocline1">2.1&nbsp;&nbsp;&nbsp;<a href="#response.cacheability">Response Cacheability</a><ul class="toc">
-                     <li class="tocline1">2.1.1&nbsp;&nbsp;&nbsp;<a href="#errors.or.incomplete.response.cache.behavior">Storing Incomplete Responses</a></li>
+                     <li class="tocline1">2.1.1&nbsp;&nbsp;&nbsp;<a href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></li>
                   </ul>
                </li>
@@ -529 +529 @@
                <li class="tocline1">2.3&nbsp;&nbsp;&nbsp;<a href="#expiration.model">Freshness Model</a><ul class="toc">
                      <li class="tocline1">2.3.1&nbsp;&nbsp;&nbsp;<a href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a><ul class="toc">
-                           <li class="tocline1">2.3.1.1&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Using Heuristic Freshness</a></li>
+                           <li class="tocline1">2.3.1.1&nbsp;&nbsp;&nbsp;<a href="#heuristic.freshness">Calculating Heuristic Freshness</a></li>
                         </ul>
                      </li>
@@ -645 +645 @@
       </p>
       <dl class="empty">
-         <dd>A response is stale if its age has passed its freshness lifetime.</dd>
+         <dd>A response is stale if its age has passed its freshness lifetime (either explicit or heuristic).</dd>
       </dl>
       <p id="rfc.section.1.2.p.10"> <span id="rfc.iref.v.1"></span>  <dfn>validator</dfn>  
@@ -688 +688 @@
       </p>
       <ul>
-         <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>) does not appear in request or response headers.
-         </li>
-         <li>the cache understands partial responses, if the response is partial or incomplete (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Incomplete Responses">Section&nbsp;2.1.1</a>).
+         <li>The request method is defined as being cacheable, and</li>
+         <li>the "no-store" cache directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>) does not appear in request or response headers, and
+         </li>
+         <li>the "private" cache response directive (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a> does not appear in the response, if the cache is a shared cache, and
+         </li>
+         <li>the cache understands partial responses, if the response is partial or incomplete (see <a href="#errors.or.incomplete.response.cache.behavior" title="Storing Partial and Incomplete Responses">Section&nbsp;2.1.1</a>).
          </li>
       </ul>
@@ -696 +699 @@
          time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
       </p>
-      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Storing Incomplete Responses</a></h3>
-      <p id="rfc.section.2.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response <span class="comment">[rfc.comment.1: Indeed? Is this new? --JRE]</span>. However, the cache <em class="bcp14">MUST</em> treat this as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
+      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="errors.or.incomplete.response.cache.behavior" href="#errors.or.incomplete.response.cache.behavior">Storing Partial and Incomplete Responses</a></h3>
+      <p id="rfc.section.2.1.1.p.1">A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) <em class="bcp14">MAY</em> store the response. However, the cache <em class="bcp14">MUST</em> treat this as a partial response <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. Partial responses <em class="bcp14">MAY</em> be combined as described in <a href="p5-range.html#combining.byte.ranges" title="Combining Ranges">Section 4</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>; the result might be a full response or might still be partial. A cache <em class="bcp14">MUST NOT</em> return a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
       </p>
       <p id="rfc.section.2.1.1.p.2">A cache that does not support the Range and Content-Range headers <em class="bcp14">MUST NOT</em> store incomplete or partial responses.
       </p>
       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2>
-      <p id="rfc.section.2.2.p.1">For a given request, a non-shared cache <em class="bcp14">MAY</em> return a stored response, provided that: 
+      <p id="rfc.section.2.2.p.1">For a presented request, a non-shared cache <em class="bcp14">MAY</em> return a stored response, provided that: 
       </p>
       <ul>
-         <li>the presented request-URI and that of the stored response match (see <span class="comment">[rfc.comment.2: TBD]</span>), and
-         </li>
-         <li>selecting headers nominated by the stored response (if any) match (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>), and
-         </li>
-         <li>the stored response is either fresh (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>) or allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>), and
-         </li>
-         <li>the presented request and stored response are free from directives that would prevent it (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>).
+         <li>The presented Request-URI and that of the stored response match (see <span class="comment">[rfc.comment.1: TBD]</span>), and
+         </li>
+         <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
+         <li>selecting request-headers nominated by the stored response (if any) match those presented (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.6</a>), and
+         </li>
+         <li>the stored response is either: 
+            <ul>
+               <li>fresh (see <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>), or
+               </li>
+               <li>allowed to be served stale (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>), or
+               </li>
+               <li>successfully validated (see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>).
+               </li>
+            </ul>and
+         </li>
+         <li>the presented request and stored response are free from directives that would prevent its use (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;3.2</a> and <a href="#header.pragma" id="rfc.xref.header.pragma.1" title="Pragma">Section&nbsp;3.4</a>).
          </li>
       </ul>
-      <p id="rfc.section.2.2.p.2"> <span class="comment">[rfc.comment.3: ISSUE: This doesn't specify whether the request method is part of the cache key.]</span> 
-      </p>
-      <p id="rfc.section.2.2.p.3">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that: 
+      <p id="rfc.section.2.2.p.2">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that: 
       </p>
       <ul>
-         <li>the criteria for non-shared caches above are met (including directives for shared caches; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.3" title="Cache-Control">Section&nbsp;3.2</a>), and
-         </li>
-         <li>the stored response was not associated with an authenticated request (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>), unless explicitly allowed (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section&nbsp;3.2</a>).
+         <li>The criteria for non-shared caches above are met (taking into account directives specific to shared caches; see <a href="#header.cache-control" id="rfc.xref.header.cache-control.4" title="Cache-Control">Section&nbsp;3.2</a>), and
+         </li>
+         <li>the stored response was not associated with an authenticated request (see <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> of <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>), unless explicitly allowed (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section&nbsp;3.2</a>).
          </li>
       </ul>
-      <p id="rfc.section.2.2.p.4">All responses satisfied from cache <em class="bcp14">MUST</em> include an appropriate Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>).
-      </p>
-      <p id="rfc.section.2.2.p.5">All request methods other than GET and HEAD <em class="bcp14">MUST</em> be written through the cache to the origin server. Note that such requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>.
-      </p>
-      <p id="rfc.section.2.2.p.6">Caches <em class="bcp14">SHOULD</em> use the most recent response (as determined by the Date header) when more than one applicable response is stored. They <em class="bcp14">MAY</em> also send a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
-      </p>
-      <p id="rfc.section.2.2.p.7">In the process of determining whether a stored response is fresh or not, a cache <em class="bcp14">MAY</em> validate that response (see <a href="#validation.model" title="Validation Model">Section&nbsp;2.4</a>).
+      <p id="rfc.section.2.2.p.3"><span class="comment">[rfc.comment.2: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span></p>
+      <p id="rfc.section.2.2.p.4">All responses satisfied from cache include an appropriate Age header field; see <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>. <span class="comment">[rfc.comment.3: DISCUSS: this currently includes successfully validated responses.]</span></p>
+      <p id="rfc.section.2.2.p.5">Request methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) <em class="bcp14">MUST</em> be written through the cache to the origin server; i.e., A cache must not reply to such a request before having forwarded
+         the request and having received a corresponding response.
+      </p>
+      <p id="rfc.section.2.2.p.6">Also, note that unsafe requests might invalidate already stored responses; see <a href="#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section&nbsp;2.5</a>.
+      </p>
+      <p id="rfc.section.2.2.p.7">Caches <em class="bcp14">SHOULD</em> use the most recent response (as determined by the Date header) when more than one suitable response is stored. They <em class="bcp14">MAY</em> also forward a request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.
       </p>
       <p id="rfc.section.2.2.p.8"> <span class="comment">[rfc.comment.4: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span> 
       </p>
       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
-      <p id="rfc.section.2.3.p.1">HTTP caching works best when caches can entirely avoid making requests to the origin server. When a response is "fresh" in
-         the cache, it can be used to satisfy subsequent requests without contacting the origin server. This is also referred to as
-         "expiration."<span class="comment">[rfc.comment.5: What exactly is called 'expiration'? --JRE]</span>.
-      </p>
-      <p id="rfc.section.2.3.p.2">Expiration applies only to responses taken from a cache and not to first-hand responses. It cannot be used to force a user
-         agent to refresh its display or reload a resource; its semantics apply only to caches. See <a href="#history.lists" title="History Lists">Section&nbsp;4</a> for an explanation of the difference between caches and history mechanisms.
-      </p>
-      <p id="rfc.section.2.3.p.3">The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future,
+      <p id="rfc.section.2.3.p.1">When a response is "fresh" in the cache, it can be used to satisfy subsequent requests without contacting the origin server,
+         thereby improving efficiency.
+      </p>
+      <p id="rfc.section.2.3.p.2">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
          using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not
-         likely to change in a semantically significant way before the expiration time is reached. This normally preserves cache correctness,
-         as long as the server's expiration times are carefully chosen.
-      </p>
-      <p id="rfc.section.2.3.p.4">If an origin server wishes to force a cache to validate every request, it <em class="bcp14">MAY</em> assign an explicit expiration time in the past. This means that the response is always stale, so that caches should validate
-         it before using it for subsequent requests.
-      </p>
-      <p id="rfc.section.2.3.p.5">Since origin servers do not always provide explicit expiration times, HTTP caches may assign heuristic expiration times when
-         they are not specified, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible
-         expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on
-         their results.
-      </p>
-      <p id="rfc.section.2.3.p.6">The calculation to determine if a response has expired is:</p>
+         likely to change in a semantically significant way before the expiration time is reached.
+      </p>
+      <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it <em class="bcp14">MAY</em> assign an explicit expiration time in the past. This means that the response is always stale, so that caches should validate
+         it before using it for subsequent requests. <span class="comment">[rfc.comment.5: This wording may cause confusion, because the response may still be served stale.]</span></p>
+      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches may also assign heuristic expiration times
+         when they are not specified, employing algorithms that use other header values (such as the Last-Modified time) to estimate
+         a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints
+         on their results.
+      </p>
+      <p id="rfc.section.2.3.p.5">The calculation to determine if a response is fresh is:</p>
       <div id="rfc.figure.u.3"></div> <pre class="text">   response_is_fresh = (freshness_lifetime &gt; current_age)
-</pre> <p id="rfc.section.2.3.p.8">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
-      </p>
-      <p id="rfc.section.2.3.p.9">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,
+</pre> <p id="rfc.section.2.3.p.7">The freshness_lifetime is defined in <a href="#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section&nbsp;2.3.1</a>; the current_age is defined in <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
+      </p>
+      <p id="rfc.section.2.3.p.8">Additionally, clients may need to influence freshness calculation. They can do this using several request cache directives,
          with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>.
+      </p>
+      <p id="rfc.section.2.3.p.9">Note that reshness applies only to cache operation; it cannot be used to force a user agent to refresh its display or reload
+         a resource. See <a href="#history.lists" title="History Lists">Section&nbsp;4</a> for an explanation of the difference between caches and history mechanisms.
       </p>
       <p id="rfc.section.2.3.p.10"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span> 
@@ -773 +781 @@
          <li>If the Expires response header (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) is present, use its value minus the value of the Date response header, or
          </li>
-         <li>Otherwise, no explicit expiration time is present in the response, but a heuristic may be used; see <a href="#heuristic.freshness" title="Using Heuristic Freshness">Section&nbsp;2.3.1.1</a>.
+         <li>Otherwise, no explicit expiration time is present in the response, but a heuristic may be used; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;2.3.1.1</a>.
          </li>
       </ul>
       <p id="rfc.section.2.3.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p>
-      <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Using Heuristic Freshness</a></h4>
+      <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4>
       <p id="rfc.section.2.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code of 200, 203, 206, 300, 301 or 410, a
          heuristic expiration time <em class="bcp14">MAY</em> be calculated. Heuristics <em class="bcp14">MUST NOT</em> be used for other response status codes.
@@ -794 +802 @@
          path from the origin server, plus the amount of time it has been in transit along network paths.
       </p>
-      <p id="rfc.section.2.3.2.p.2">When a response is generated from a stored response, the cache <em class="bcp14">MUST</em> include a single Age header field in the response with a value equal to the stored response's current_age, calculated using
+      <p id="rfc.section.2.3.2.p.2">When a stored response is used to satisfy a request, the cache <em class="bcp14">MUST</em> include a single Age header field in the response with a value equal to the stored response's current_age, calculated using
          the algorithm described in this section.
       </p>
@@ -848 +856 @@
          but is not fresh according to the calculations in <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a>.
       </p>
-      <p id="rfc.section.2.3.3.p.2">Caches <em class="bcp14">MUST NOT</em> return 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.2.3.3.p.2">Caches <em class="bcp14">MAY</em> return a stale response if disconnected or explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
+      </p>
+      <p id="rfc.section.2.3.3.p.3">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses.
+      </p>
+      <p id="rfc.section.2.3.3.p.4">Caches <em class="bcp14">MUST NOT</em> return 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;3.2.2</a>).
       </p>
-      <p id="rfc.section.2.3.3.p.3">Caches <em class="bcp14">MAY</em> return a stale response if disconnected or explicitly allowed (e.g., the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
-      </p>
-      <p id="rfc.section.2.3.3.p.4">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses.
-      </p>
       <p id="rfc.section.2.3.3.p.5">Stale responses <em class="bcp14">SHOULD</em> have a Warning header with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>).
       </p>
@@ -862 +870 @@
       </p>
       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
-      <p id="rfc.section.2.4.p.1">When a cache has a stale response that it would like to use, it <em class="bcp14">SHOULD</em> first check with the origin server (or possibly an intermediate cache with a fresh response) to see if it is still usable.
-         This is called "validating" or "revalidating" the stored response.
-      </p>
-      <p id="rfc.section.2.4.p.2">HTTP's conditional request mechanism, defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, is used to avoid retransmitting the response payload when the stored response is valid. When a stored response includes
-         one or more "cache validators", such as the field values of an ETag or Last-Modified header field, then a validating GET request <em class="bcp14">SHOULD</em> be made conditional to those field values. The server checks the conditional request's validator against the current state
-         of the requested resource and, if they match, the server responds with a 304 (Not Modified) status code to indicate that the
-         stored response can be refreshed and reused without retransmitting the response payload. If the validator does not match the
-         current state of the requested resource, then the server returns a full response, including payload, so that the request can
-         be satisfied and the stored response supplanted without the need for an additional network round-trip.
-      </p>
-      <p id="rfc.section.2.4.p.3">See <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a> regarding combining cached headers with those in a 304 response.
-      </p>
-      <p id="rfc.section.2.4.p.4">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously received response unless the stored response includes the "must-revalidate" cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>).
+      <p id="rfc.section.2.4.p.1">Checking with the origin server to see if a stale or otherwise unusable cached response can be reused is called "validating"
+         or "revalidating." Doing so potentially avoids the overhead of retransmitting the response body when the stored response is
+         valid.
+      </p>
+      <p id="rfc.section.2.4.p.2">HTTP's conditional request mechanism <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> is used for this purpose. When a stored response includes one or more validators, such as the field values of an ETag or Last-Modified
+         header field, then a validating request <em class="bcp14">SHOULD</em> be made conditional to those field values.
+      </p>
+      <p id="rfc.section.2.4.p.3">A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>.
+      </p>
+      <p id="rfc.section.2.4.p.4">If instead the cache receives a full response (i.e., one with a response body), it is used to satisfy the request and replace
+         the stored response. <span class="comment">[rfc.comment.8: Should there be a requirement here?]</span></p>
+      <p id="rfc.section.2.4.p.5">If a cache receives a 5xx response while attempting to validate a response, it <em class="bcp14">MAY</em> either forward this response to the requesting client, or act as if the server failed to respond. In the latter case, it <em class="bcp14">MAY</em> return a previously stored response unless the stored response includes the "must-revalidate" cache directive (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
       </p>
       <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h2>
-      <p id="rfc.section.2.5.p.1">Because unsafe methods <a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> have the potential for changing state on the origin server, intervening caches have the opportunity to use them to keep their
-         contents up-to-date.
+      <p id="rfc.section.2.5.p.1">Because unsafe methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 7.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) have the potential for changing state on the origin server, intervening caches can use them to keep their contents up-to-date.
       </p>
       <p id="rfc.section.2.5.p.2">The following HTTP methods <em class="bcp14">MUST</em> cause a cache to invalidate the Request-URI as well as the Location and Content-Location headers (if present): 
@@ -890 +896 @@
          attacks.
       </p>
-      <p id="rfc.section.2.5.p.4"> <span class="comment">[rfc.comment.8: TODO: "host part" needs to be specified better.]</span> 
+      <p id="rfc.section.2.5.p.4"> <span class="comment">[rfc.comment.9: TODO: "host part" needs to be specified better.]</span> 
       </p>
       <p id="rfc.section.2.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI.
@@ -900 +906 @@
          change at the origin server might not have gone through the cache where a response is stored.
       </p>
-      <p id="rfc.section.2.5.p.8"> <span class="comment">[rfc.comment.9: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span> 
+      <p id="rfc.section.2.5.p.8"> <span class="comment">[rfc.comment.10: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span> 
       </p>
       <h2 id="rfc.section.2.6"><a href="#rfc.section.2.6">2.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
-      <p id="rfc.section.2.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), as indicated by the presence of a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>) in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests.
-      </p>
-      <p id="rfc.section.2.6.p.2">When the cache receives a subsequent request which may be satisfied by a stored responses that include a Vary header field,
-         it <em class="bcp14">MUST NOT</em> use it to satisfy the request unless all of the selecting request-headers present in the new request match the corresponding
-         stored request-headers from the original request.
+      <p id="rfc.section.2.6.p.1">Use of server-driven content negotiation (<a href="p3-payload.html#server-driven.negotiation" title="Server-driven Negotiation">Section 4.1</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) alters the conditions and procedure by which a cache can use the response for subsequent requests.
+      </p>
+      <p id="rfc.section.2.6.p.2">When the cache receives a request which may be satisfied by a stored response that includes a Vary header field <a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>, it <em class="bcp14">MUST NOT</em> use the stored response to satisfy the request unless all of the selecting request-headers present in the new request match
+         the corresponding stored request-headers from the original request.
       </p>
       <p id="rfc.section.2.6.p.3">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first
-         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment">[rfc.comment.10: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
-         name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
-      </p>
-      <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests on that resource can only be properly interpreted
+         request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment">[rfc.comment.11: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
+         name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. <span class="comment">[rfc.comment.12: DISCUSS: header-specific canonicalisation]</span></p>
+      <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted
          by the origin server.
       </p>
-      <p id="rfc.section.2.6.p.5">If the selecting request header fields for the stored response do not match the selecting request header fields of the new
-         request, then the cache <em class="bcp14">MUST NOT</em> use the stored response to satisfy the request unless it first relays the new request to the origin server in a conditional
-         request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity
-         to be used.
-      </p>
-      <p id="rfc.section.2.6.p.6">If one or more applicable stored response has an entity tag, the forwarded request <em class="bcp14">SHOULD</em> be conditional and include all of these entity tags in an If-None-Match header field. This conveys to the server the set of
-         entities currently stored by the cache, so that if any one of these entities matches the requested entity, the server can
-         use the ETag header field in its 304 (Not Modified) response to tell the cache which stored response is appropriate. If the
-         entity-tag of the new response matches that of an existing stored resopnse, the new response <em class="bcp14">SHOULD</em> be used to update its header fields, and the result <em class="bcp14">MUST</em> be returned to the client.
-      </p>
-      <p id="rfc.section.2.6.p.7">If any of the existing stored responses contains only partial content for the associated entity, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored
+      <p id="rfc.section.2.6.p.5">If no stored response matches, the cache <em class="bcp14">MAY</em> forward the presented request to the origin server in a conditional request, which <em class="bcp14">SHOULD</em> include all ETags stored with potentially suitable responses in an If-None-Match request header. If the server responds with
+         304 (Not Modified) and includes an entity tag or Content-Location that indicates the entity to be used, that cached response <em class="bcp14">MUST</em> be used to satisfy the presented request, and <em class="bcp14">SHOULD</em> be used to update the corresponding stored response; see <a href="#combining.headers" title="Combining Responses">Section&nbsp;2.7</a>.
+      </p>
+      <p id="rfc.section.2.6.p.6">If any of the stored responses contains only partial content, its entity-tag <em class="bcp14">SHOULD NOT</em> be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that stored
          response.
       </p>
-      <p id="rfc.section.2.6.p.8">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the
+      <p id="rfc.section.2.6.p.7">If a cache receives a successful response whose Content-Location field matches that of an existing stored response for the
          same Request-URI, whose entity-tag differs from that of the existing stored response, and whose Date is more recent than that
-         of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.
-      </p>
-      <p id="rfc.section.2.6.p.9"> <span class="comment">[rfc.comment.11: TODO: this still needs work.]</span> 
-      </p>
+         of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.<span class="comment">[rfc.comment.13: DISCUSS: Not sure if this is necessary.]</span></p>
       <h2 id="rfc.section.2.7"><a href="#rfc.section.2.7">2.7</a>&nbsp;<a id="combining.headers" href="#combining.headers">Combining Responses</a></h2>
       <p id="rfc.section.2.7.p.1">When a cache receives a 304 (Not Modified) response or a 206 (Partial Content) response, it needs to update the stored response
@@ -956 +950 @@
          such old headers <em class="bcp14">MUST</em> be replaced. it <em class="bcp14">MAY</em> store the combined entity-body.
       </p>
-      <p id="rfc.section.2.7.p.5"><span class="comment">[rfc.comment.12: ISSUE: discuss how to handle HEAD updates]</span></p>
+      <p id="rfc.section.2.7.p.5"><span class="comment">[rfc.comment.14: ISSUE: discuss how to handle HEAD updates]</span></p>
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
       <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
@@ -1405 +1399 @@
                   <td>http</td>
                   <td>standard</td>
-                  <td> <a href="#header.cache-control" id="rfc.xref.header.cache-control.5" title="Cache-Control">Section&nbsp;3.2</a> 
+                  <td> <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">Section&nbsp;3.2</a> 
                   </td>
                </tr>
@@ -1542 +1536 @@
       <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a>&nbsp;<a id="compatibility" href="#compatibility">Compatibility with Previous Versions</a></h1>
       <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2>
-      <p id="rfc.section.A.1.p.1">A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections <a href="#response.cacheability" title="Response Cacheability">2.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">3.2</a>).
+      <p id="rfc.section.A.1.p.1">A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections <a href="#response.cacheability" title="Response Cacheability">2.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">3.2</a>).
       </p>
       <p id="rfc.section.A.1.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
@@ -1553 +1547 @@
       </p>
       <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses.</p>
-      <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.7" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.
+      <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. <a href="#expiration.model" title="Freshness Model">2.3</a>, <a href="#combining.headers" title="Combining Responses">2.7</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.8" title="Cache-Control">3.2</a>, and <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">3.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.
       </p>
       <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
@@ -1718 +1712 @@
                      </ul>
                   </li>
-                  <li class="indline1">Cache-Control header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.iref.c.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.5">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
+                  <li class="indline1">Cache-Control header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">2.2</a>, <a class="iref" href="#rfc.iref.c.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.6">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">A.1</a></li>
                   <li class="indline1">cacheable&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2">1.2</a></li>
                </ul>
@@ -1767 +1761 @@
                      <ul class="ind">
                         <li class="indline1">Age&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.age.1">2.2</a>, <a class="iref" href="#rfc.iref.h.2"><b>3.1</b></a>, <a class="iref" href="#rfc.xref.header.age.2">5.1</a></li>
-                        <li class="indline1">Cache-Control&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.5">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.6">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a></li>
+                        <li class="indline1">Cache-Control&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.cache-control.1">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.2">2.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.3">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.4">2.2</a>, <a class="iref" href="#rfc.xref.header.cache-control.5">2.2</a>, <a class="iref" href="#rfc.iref.h.3"><b>3.2</b></a>, <a class="iref" href="#rfc.xref.header.cache-control.6">5.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.7">A.1</a>, <a class="iref" href="#rfc.xref.header.cache-control.8">A.1</a></li>
                         <li class="indline1">Expires&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.expires.1">2.3</a>, <a class="iref" href="#rfc.xref.header.expires.2">2.3.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>3.3</b></a>, <a class="iref" href="#rfc.xref.header.expires.3">5.1</a></li>
                         <li class="indline1">Pragma&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.pragma.1">2.2</a>, <a class="iref" href="#rfc.xref.header.pragma.2">3.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>3.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.3">5.1</a></li>
@@ -1841 +1835 @@
                      </ul>
                   </li>
-                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.5</a>, <a class="iref" href="#Part2"><b>8.1</b></a><ul class="ind">
-                        <li class="indline1"><em>Section 7.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.5</a></li>
+                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.2</a>, <a class="iref" href="#rfc.xref.Part2.2">2.5</a>, <a class="iref" href="#Part2"><b>8.1</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 7.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">2.2</a>, <a class="iref" href="#rfc.xref.Part2.2">2.5</a></li>
                      </ul>
                   </li>

draft-ietf-httpbis/latest-roy/p7-auth.html

@@ -462 +462 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">March 2, 2009</td>
+            <td class="header right">March 4, 2009</td>
          </tr>
       </table>