Changeset 441

Timestamp:

Jan 31, 2009, 12:56:49 PM (11 years ago)

Author:

julian.reschke@…

Message:

re-generate HTML, P6: fix a few formatting issues, add a few crefs

Location:

draft-ietf-httpbis/latest-roy

Files:

• p1-messaging.html (modified) (4 diffs)
• p2-semantics.html (modified) (4 diffs)
• p3-payload.html (modified) (4 diffs)
• p4-conditional.html (modified) (4 diffs)
• p5-range.html (modified) (4 diffs)
• p6-cache.html (modified) (18 diffs)
• p6-cache.xml (modified) (9 diffs)
• p7-auth.html (modified) (4 diffs)

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

@@ -221 +221 @@
   margin-right: 0em;
   padding-left: 0em;
+  page-break-before: avoid;
 }
 li.indline0 {
@@ -381 +382 @@
       <link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D">
       <link rel="Appendix" title="E Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.E">
-      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.400, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.415, 2009-01-29 15:06:08, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
       <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
       <meta name="DC.Creator" content="Fielding, R.">
@@ -477 +478 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">December 11, 2008</td>
+            <td class="header right">December 2008</td>
          </tr>
       </table>
@@ -711 +712 @@
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
       <div id="core.rules">
-         <p id="rfc.section.1.2.p.1">                        This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
+         <p id="rfc.section.1.2.p.1">                        This specification uses the Augmented Backus-Naur Form (ABNF) notation of <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.2"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
             (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a> character), and WSP (whitespace).
          </p>

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

@@ -221 +221 @@
   margin-right: 0em;
   padding-left: 0em;
+  page-break-before: avoid;
 }
 li.indline0 {
@@ -380 +381 @@
       <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
       <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C">
-      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.400, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.415, 2009-01-29 15:06:08, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
       <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
       <meta name="DC.Creator" content="Fielding, R.">
@@ -477 +478 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">December 11, 2008</td>
+            <td class="header right">December 2008</td>
          </tr>
       </table>
@@ -678 +679 @@
       </p>
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
-      <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
+      <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
          (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
          and WSP (whitespace).

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

@@ -228 +228 @@
   margin-right: 0em;
   padding-left: 0em;
+  page-break-before: avoid;
 }
 li.indline0 {
@@ -388 +389 @@
       <link rel="Appendix" title="D Collected ABNF" href="#rfc.section.D">
       <link rel="Appendix" title="E Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.E">
-      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.400, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.415, 2009-01-29 15:06:08, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
       <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
       <meta name="DC.Creator" content="Fielding, R.">
@@ -484 +485 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">December 11, 2008</td>
+            <td class="header right">December 2008</td>
          </tr>
       </table>
@@ -638 +639 @@
       </p>
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
-      <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
+      <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
          (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
          and WSP (whitespace).

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

@@ -221 +221 @@
   margin-right: 0em;
   padding-left: 0em;
+  page-break-before: avoid;
 }
 li.indline0 {
@@ -377 +378 @@
       <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
       <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C">
-      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.400, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.415, 2009-01-29 15:06:08, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
       <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
       <meta name="DC.Creator" content="Fielding, R.">
@@ -473 +474 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">December 11, 2008</td>
+            <td class="header right">December 2008</td>
          </tr>
       </table>
@@ -586 +587 @@
       </p>
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
-      <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
+      <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
          (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
          and WSP (whitespace).

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

@@ -221 +221 @@
   margin-right: 0em;
   padding-left: 0em;
+  page-break-before: avoid;
 }
 li.indline0 {
@@ -377 +378 @@
       <link rel="Appendix" title="C Collected ABNF" href="#rfc.section.C">
       <link rel="Appendix" title="D Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.D">
-      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.400, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.415, 2009-01-29 15:06:08, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
       <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
       <meta name="DC.Creator" content="Fielding, R.">
@@ -473 +474 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">December 11, 2008</td>
+            <td class="header right">December 2008</td>
          </tr>
       </table>
@@ -590 +591 @@
       </p>
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
-      <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
+      <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
          (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
          and WSP (whitespace).

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

@@ -224 +224 @@
   margin-right: 0em;
   padding-left: 0em;
+  page-break-before: avoid;
 }
 li.indline0 {
@@ -378 +379 @@
       <link rel="Appendix" title="A Compatibility with Previous Versions" href="#rfc.section.A">
       <link rel="Appendix" title="B Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.B">
-      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.400, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.415, 2009-01-29 15:06:08, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
       <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
       <meta name="DC.Creator" content="Fielding, R.">
@@ -474 +475 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">December 11, 2008</td>
+            <td class="header right">December 2008</td>
          </tr>
       </table>
@@ -687 +688 @@
          </li>
       </ul>
-      <p id="rfc.section.3.1.p.2">Note that in normal operation, most caches will not store a response that has neither a cache validator nor an explicitly
-         expiration time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
+      <p id="rfc.section.3.1.p.2">Note that in normal operation, most caches will not store a response that has neither a cache validator nor an explicit expiration
+         time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
       </p>
       <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.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.3.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 id="rfc.section.3.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.
       </p>
       <p id="rfc.section.3.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.
@@ -699 +700 @@
       </p>
       <ul>
-         <li>the presented request-URI and that of the stored response match (see <span class="comment">[rfc.comment.1: TBD]</span>), and
+         <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;3.6</a>), and
@@ -708 +709 @@
          </li>
       </ul>
-      <p id="rfc.section.3.2.p.2"> <span class="comment">[rfc.comment.2: ISSUE: This doesn't specify whether the request method is part of the cache key.]</span> 
+      <p id="rfc.section.3.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.3.2.p.3">A shared cache <em class="bcp14">MAY</em> return a stored response, provided that: 
@@ -726 +727 @@
       <p id="rfc.section.3.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;3.4</a>).
       </p>
-      <p id="rfc.section.3.2.p.8"> <span class="comment">[rfc.comment.3: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span> 
+      <p id="rfc.section.3.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.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
       <p id="rfc.section.3.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."
+         "expiration."<span class="comment">[rfc.comment.5: What exactly is called 'expiration'? --JRE]</span>.
       </p>
       <p id="rfc.section.3.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
@@ -737 +738 @@
       </p>
       <p id="rfc.section.3.3.p.3">The primary mechanism for avoiding requests 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;4.3</a> or the max-age response cache directive <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.2.2</a>. Generally, origin servers will assign future explicit expiration times to responses in the belief that the entity is not
+         using either the Expires header (<a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;4.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;4.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.
@@ -756 +757 @@
          with the effect of either increasing or loosening constraints on freshness. See <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;4.2.1</a>.
       </p>
-      <p id="rfc.section.3.3.p.10"> <span class="comment">[rfc.comment.4: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span> 
+      <p id="rfc.section.3.3.p.10"> <span class="comment">[rfc.comment.6: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span> 
       </p>
       <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="calculating.freshness.lifetime" href="#calculating.freshness.lifetime">Calculating Freshness Lifetime</a></h3>
@@ -778 +779 @@
          not already present.
       </p>
-      <p id="rfc.section.3.3.1.1.p.3">Also, if the response has a Last-Modified header <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
-      </p>
-      <p id="rfc.section.3.3.1.1.p.4"> <span class="comment">[rfc.comment.5: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span> 
+      <p id="rfc.section.3.3.1.1.p.3">Also, if the response has a Last-Modified header (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), the heuristic expiration value <em class="bcp14">SHOULD</em> be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
+      </p>
+      <p id="rfc.section.3.3.1.1.p.4"> <span class="comment">[rfc.comment.7: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span> 
       </p>
       <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
@@ -850 +851 @@
       <p id="rfc.section.3.3.3.p.4">Otherwise, caches <em class="bcp14">SHOULD NOT</em> return stale responses.
       </p>
-      <p id="rfc.section.3.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">4.6</a>).
+      <p id="rfc.section.3.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;4.6</a>).
       </p>
       <p id="rfc.section.3.3.3.p.6">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally
@@ -860 +861 @@
       </p>
       <p id="rfc.section.3.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
+         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
@@ -884 +885 @@
          attacks.
       </p>
-      <p id="rfc.section.3.5.p.4"> <span class="comment">[rfc.comment.6: TODO: "host part" needs to be specified better.]</span> 
+      <p id="rfc.section.3.5.p.4"> <span class="comment">[rfc.comment.8: TODO: "host part" needs to be specified better.]</span> 
       </p>
       <p id="rfc.section.3.5.p.5">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Request-URI.
@@ -894 +895 @@
          change at the origin server might not have gone through the cache where a response is stored.
       </p>
-      <p id="rfc.section.3.5.p.8"> <span class="comment">[rfc.comment.7: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span> 
+      <p id="rfc.section.3.5.p.8"> <span class="comment">[rfc.comment.9: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span> 
       </p>
       <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
-      <p id="rfc.section.3.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;4.5</a> in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests.
+      <p id="rfc.section.3.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;4.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.3.6.p.2">When the cache receives a subsequent request which may be satisfied by a stored responses that include a Vary header field,
@@ -904 +905 @@
       </p>
       <p id="rfc.section.3.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.8: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
+         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.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>.
       </p>
@@ -927 +928 @@
          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.3.6.p.9"> <span class="comment">[rfc.comment.9: TODO: this still needs work.]</span> 
+      <p id="rfc.section.3.6.p.9"> <span class="comment">[rfc.comment.11: TODO: this still needs work.]</span> 
       </p>
       <h2 id="rfc.section.3.7"><a href="#rfc.section.3.7">3.7</a>&nbsp;<a id="combining.headers" href="#combining.headers">Combining Responses</a></h2>
@@ -950 +951 @@
          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.3.7.p.5"><span class="comment">[rfc.comment.10: ISSUE: discuss how to handle HEAD updates]</span></p>
+      <p id="rfc.section.3.7.p.5"><span class="comment">[rfc.comment.12: ISSUE: discuss how to handle HEAD updates]</span></p>
       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
       <p id="rfc.section.4.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
@@ -1529 +1530 @@
       <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">3.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">4.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">3.1</a>, <a href="#header.cache-control" id="rfc.xref.header.cache-control.6" title="Cache-Control">4.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

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

@@ -382 +382 @@
         </t>
         <t>Note that in normal operation, most caches will not store a response that has neither a
-          cache validator nor an explicitly expiration time, as such responses are not usually
+          cache validator nor an explicit expiration time, as such responses are not usually
           useful to store. However, caches are not prohibited from storing such responses.</t>
 
@@ -388 +388 @@
           title="Storing Incomplete Responses">
           <t>A cache that receives an incomplete response (for example, with fewer bytes of data
-            than specified in a Content-Length header) &MAY; store the response. However, the
+            than specified in a Content-Length header) &MAY; store the response <cref source="JRE">Indeed? Is this new?</cref>. However, the
             cache &MUST; treat this as a partial response &partial;. Partial responses
             &MAY; be combined as described in &combining-byte-ranges;; the result might be a
@@ -451 +451 @@
         <t>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."</t>
+          requests without contacting the origin server. This is also referred to as "expiration."<cref source="JRE">What exactly is called 'expiration'?</cref>.</t>
         <t>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
@@ -457 +457 @@
           the difference between caches and history mechanisms.</t>
         <t>The primary mechanism for avoiding requests is for an origin server to provide an
-          explicit expiration time in the future, using either the Expires header <xref
-            target="header.expires" /> or the max-age response cache directive <xref
-            target="cache-response-directive" />. Generally, origin servers will assign future
+          explicit expiration time in the future, using either the Expires header (<xref
+            target="header.expires" />) or the max-age response cache directive (<xref
+            target="cache-response-directive" />). 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
@@ -512 +512 @@
               attach a Warning header with a 113 warn-code to the response if its current_age is
               more than 24 hours and such a warning is not already present.</t>
-            <t>Also, if the response has a Last-Modified header &header-last-modified;, the
+            <t>Also, if the response has a Last-Modified header (&header-last-modified;), the
               heuristic expiration value &SHOULD; be no more than some fraction of the interval
               since that time. A typical setting of this fraction might be 10%.</t>
@@ -610 +610 @@
           <t>Otherwise, caches &SHOULD-NOT; return stale responses.</t>
           <t>Stale responses &SHOULD; have a Warning header with the 110 warn-code (see <xref
-              format="counter" target="header.warning" />).</t>
+              target="header.warning" />).</t>
           <t>If a cache receives a first-hand response (either an entire response, or a 304 (Not
             Modified) response) that it would normally forward to the requesting client, and the
@@ -627 +627 @@
         <t>HTTP's conditional request mechanism, defined in &conditional;, 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
+          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 &SHOULD; be made conditional
           to those field values. The server checks the conditional request's validator against the
@@ -682 +682 @@
       <section anchor="caching.negotiated.responses" title="Caching Negotiated Responses">
         <t>Use of server-driven content negotiation (&server-driven-negotiation;), as indicated
-          by the presence of a Vary header field <xref target="header.vary" /> in a response, alters
+          by the presence of a Vary header field (<xref target="header.vary" />) in a response, alters
           the conditions and procedure by which a cache can use the response for subsequent
           requests.</t>
@@ -1792 +1792 @@
         <t>A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add
           this missing case. (Sections <xref format="counter" target="response.cacheability" />,
-            <xref format="counter" target="header.cache-control" />.</t>
+            <xref format="counter" target="header.cache-control" />).</t>
         <t>Transfer-coding and message lengths all interact in ways that required fixing exactly
           when chunked encoding is used (to allow for transfer encoding that may not be self

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

@@ -221 +221 @@
   margin-right: 0em;
   padding-left: 0em;
+  page-break-before: avoid;
 }
 li.indline0 {
@@ -374 +375 @@
       <link rel="Appendix" title="B Collected ABNF" href="#rfc.section.B">
       <link rel="Appendix" title="C Change Log (to be removed by RFC Editor before publication)" href="#rfc.section.C">
-      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.400, 2008-10-10 14:04:14, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
+      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.415, 2009-01-29 15:06:08, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
       <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
       <meta name="DC.Creator" content="Fielding, R.">
@@ -471 +472 @@
          <tr>
             <td class="header left"></td>
-            <td class="header right">December 11, 2008</td>
+            <td class="header right">December 2008</td>
          </tr>
       </table>
@@ -577 +578 @@
       </p>
       <h2 id="rfc.section.1.2"><a href="#rfc.section.1.2">1.2</a>&nbsp;<a id="notation" href="#notation">Syntax Notation</a></h2>
-      <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#section-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
+      <p id="rfc.section.1.2.p.1">This specification uses the ABNF syntax defined in <a href="p1-messaging.html#notation" title="Syntax Notation">Section 1.2</a> of <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The following core rules are included by reference, as defined in <a href="#RFC5234" id="rfc.xref.RFC5234.1"><cite title="Augmented BNF for Syntax Specifications: ABNF">[RFC5234]</cite></a>, <a href="http://tools.ietf.org/html/rfc5234#appendix-B.1">Appendix B.1</a>: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG
          (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), VCHAR (any visible USASCII character),
          and WSP (whitespace).