Changeset 2066 for draft-ietf-httpbis

Timestamp:

29/12/12 10:14:11 (9 years ago)

Author:

fielding@…

Message:

(editorial) rephrasing to better target the subject of requirements

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (6 diffs)
• p1-messaging.xml (modified) (2 diffs)
• p4-conditional.html (modified) (8 diffs)
• p4-conditional.xml (modified) (3 diffs)
• p5-range.html (modified) (10 diffs)
• p5-range.xml (modified) (6 diffs)
• p6-cache.html (modified) (6 diffs)
• p6-cache.xml (modified) (1 diff)
• p7-auth.html (modified) (6 diffs)
• p7-auth.xml (modified) (3 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires June 19, 2013"; 
+       content: "Expires July 2, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-12-16">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -520 +520 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">December 16, 2012</td>
+               <td class="right">December 29, 2012</td>
             </tr>
             <tr>
-               <td class="left">Expires: June 19, 2013</td>
+               <td class="left">Expires: July 2, 2013</td>
                <td class="right"></td>
             </tr>
@@ -551 +551 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on June 19, 2013.</p>
+      <p>This Internet-Draft will expire on July 2, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1478 +1478 @@
          entire request before processing.
       </p>
-      <p id="rfc.section.3.3.3.p.6">A client that sends a request containing a message body <em class="bcp14">MUST</em> include a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of
+      <p id="rfc.section.3.3.3.p.6">A user agent that sends a request containing a message body <em class="bcp14">MUST</em> send a valid <a href="#header.content-length" class="smpl">Content-Length</a> header field if it does not know the server will handle HTTP/1.1 (or later) requests; such knowledge can be in the form of
          specific user configuration or by remembering the version of a prior received response.
       </p>
@@ -1503 +1503 @@
       <p id="rfc.section.3.5.p.1">Older HTTP/1.0 user agent implementations might send an extra CRLF after a POST request as a lame workaround for some early
          server applications that failed to read message body content that was not terminated by a line-ending. An HTTP/1.1 user agent <em class="bcp14">MUST NOT</em> preface or follow a request with an extra CRLF. If terminating the request message body with a line-ending is desired, then
-         the user agent <em class="bcp14">MUST</em> include the terminating CRLF octets as part of the message body length.
+         the user agent <em class="bcp14">MUST</em> count the terminating CRLF octets as part of the message body length.
       </p>
       <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a request-line is expected. In other words, if a server is reading the protocol

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

@@ -1751 +1751 @@
 </t>
 <t>
-   A client that sends a request containing a message body &MUST; include a
+   A user agent that sends a request containing a message body &MUST; send a
    valid <x:ref>Content-Length</x:ref> header field if it does not know the
    server will handle HTTP/1.1 (or later) requests; such knowledge can be in
@@ -1810 +1810 @@
    preface or follow a request with an extra CRLF.  If terminating
    the request message body with a line-ending is desired, then the
-   user agent &MUST; include the terminating CRLF octets as part of the
+   user agent &MUST; count the terminating CRLF octets as part of the
    message body length. 
 </t>

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires June 18, 2013"; 
+       content: "Expires July 2, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-12-15">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
@@ -517 +517 @@
             </tr>
             <tr>
-               <td class="left">Expires: June 18, 2013</td>
-               <td class="right">December 15, 2012</td>
+               <td class="left">Expires: July 2, 2013</td>
+               <td class="right">December 29, 2012</td>
             </tr>
          </tbody>
@@ -545 +545 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on June 18, 2013.</p>
+      <p>This Internet-Draft will expire on July 2, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1056 +1056 @@
       <div id="rfc.iref.21"></div>
       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="status.304" href="#status.304">304 Not Modified</a></h2>
-      <p id="rfc.section.4.1.p.1">The 304 status code indicates that a conditional GET request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server
+      <p id="rfc.section.4.1.p.1">The <dfn>304 (Not Modified)</dfn> status code indicates that a conditional GET request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server
          to transfer a representation of the target resource because the request indicates that the client which made the request conditional
          already has a valid representation; the server is therefore redirecting that client to make use of that stored representation
          as if it were the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
       </p>
-      <p id="rfc.section.4.1.p.2">The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
-      </p>
-      <p id="rfc.section.4.1.p.3">A 304 response <em class="bcp14">MUST</em> include a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field (<a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200
-            (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
+      <p id="rfc.section.4.1.p.2">A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields.</p>
+      <p id="rfc.section.4.1.p.3">If a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a>, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p2-semantics.html#header.vary" class="smpl">Vary</a>, then the sender <em class="bcp14">MUST</em> generate those same header fields in a 304 response.
       </p>
       <p id="rfc.section.4.1.p.4">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,
-         the response <em class="bcp14">SHOULD NOT</em> include representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding
+         a sender <em class="bcp14">SHOULD NOT</em> generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding
          cache updates (e.g., future HTTP extensions).
       </p>
@@ -1078 +1076 @@
       <div id="rfc.iref.21"></div>
       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="status.412" href="#status.412">412 Precondition Failed</a></h2>
-      <p id="rfc.section.4.2.p.1">The 412 status code indicates that one or more preconditions given in the request header fields evaluated to false when tested
-         on the server. This response code allows the client to place preconditions on the current resource state (its current representations
+      <p id="rfc.section.4.2.p.1">The <dfn>412 (Precondition Failed)</dfn> status code indicates that one or more preconditions given in the request header fields evaluated to false when tested on
+         the server. This response code allows the client to place preconditions on the current resource state (its current representations
          and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state.
       </p>
@@ -1317 +1315 @@
   <a href="#imported.abnf" class="smpl">obs-text</a>      = &lt;obs-text, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#field.components" title="Field value components">Section 3.2.6</a>&gt;
 </pre><p id="rfc.section.B.p.4">The rules below are defined in other parts:</p>
-      <div id="rfc.figure.u.17"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>&gt;
+      <div id="rfc.figure.u.17"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>&gt;
 </pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
       <div id="rfc.figure.u.18"></div> <pre class="inline"><a href="#header.etag" class="smpl">ETag</a> = entity-tag
@@ -1441 +1439 @@
                      </ul>
                   </li>
-                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3.3</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#rfc.xref.Part2.4">4.1</a>, <a href="#Part2"><b>9.1</b></a>, <a href="#rfc.xref.Part2.5">B</a><ul>
+                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3.3</a>, <a href="#rfc.xref.Part2.3">2.3.3</a>, <a href="#Part2"><b>9.1</b></a>, <a href="#rfc.xref.Part2.4">B</a><ul>
                         <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3.3</a></li>
                         <li><em>Section 5.3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.3.3</a></li>
-                        <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">B</a></li>
-                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1</a></li>
+                        <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">B</a></li>
                      </ul>
                   </li>

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -928 +928 @@
   <x:anchor-alias value="304 (Not Modified)"/>
 <t>
-   The 304 status code indicates that a conditional GET request has been
+   The <x:dfn>304 (Not Modified)</x:dfn> status code indicates that a conditional GET request has been
    received and would have resulted in a <x:ref>200 (OK)</x:ref> response
    if it were not for the fact that the condition has evaluated to false.
@@ -939 +939 @@
 </t>
 <t>
-   The 304 response &MUST-NOT; contain a message-body, and thus is always
+   A 304 response cannot contain a message-body; it is always
    terminated by the first empty line after the header fields.
 </t>
 <t>
-   A 304 response &MUST; include a <x:ref>Date</x:ref> header field
-   (&header-date;) unless the origin server does not have a clock that can
-   provide a reasonable approximation of the current time.  If a <x:ref>200
-   (OK)</x:ref> response to the same request would have included any of the
-   header fields <x:ref>Cache-Control</x:ref>, <x:ref>Content-Location</x:ref>,
-   <x:ref>ETag</x:ref>, <x:ref>Expires</x:ref>, or <x:ref>Vary</x:ref>, then
-   those same header fields &MUST; be sent in a 304 response.
+   If a <x:ref>200 (OK)</x:ref> response to the same request would have
+   included any of the header fields
+   <x:ref>Cache-Control</x:ref>,
+   <x:ref>Content-Location</x:ref>,
+   <x:ref>ETag</x:ref>,
+   <x:ref>Expires</x:ref>, or
+   <x:ref>Vary</x:ref>, then
+   the sender &MUST; generate those same header fields in a 304 response.
 </t>
 <t>
    Since the goal of a 304 response is to minimize information transfer
    when the recipient already has one or more cached representations,
-   the response &SHOULD-NOT; include representation metadata other
+   a sender &SHOULD-NOT; generate representation metadata other
    than the above listed fields unless said metadata exists for the
    purpose of guiding cache updates (e.g., future HTTP extensions).
@@ -978 +979 @@
   <x:anchor-alias value="412 (Precondition Failed)"/>
 <t>
-   The 412 status code indicates that one or more preconditions given in
+   The <x:dfn>412 (Precondition Failed)</x:dfn> status code indicates that one or more preconditions given in
    the request header fields evaluated to false when tested on the server.
    This response code allows the client to place preconditions on the

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires June 19, 2013"; 
+       content: "Expires July 2, 2013"; 
   } 
   @bottom-right {
@@ -493 +493 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-12-16">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.">
@@ -519 +519 @@
             </tr>
             <tr>
-               <td class="left">Expires: June 19, 2013</td>
+               <td class="left">Expires: July 2, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -528 +528 @@
             <tr>
                <td class="left"></td>
-               <td class="right">December 16, 2012</td>
+               <td class="right">December 29, 2012</td>
             </tr>
          </tbody>
@@ -553 +553 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on June 19, 2013.</p>
+      <p>This Internet-Draft will expire on July 2, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -682 +682 @@
       <div id="rfc.iref.3"></div>
       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="status.206" href="#status.206">206 Partial Content</a></h2>
-      <p id="rfc.section.3.1.p.1">The server has fulfilled the partial GET request for the resource. The request <em class="bcp14">MUST</em> have included a <a href="#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.3" title="Range">Section&nbsp;5.4</a>) indicating the desired range, and <em class="bcp14">MAY</em> have included an <a href="#header.if-range" class="smpl">If-Range</a> header field (<a href="#header.if-range" id="rfc.xref.header.if-range.1" title="If-Range">Section&nbsp;5.3</a>) to make the request conditional.
-      </p>
-      <p id="rfc.section.3.1.p.2">The response <em class="bcp14">MUST</em> include the following header fields: 
+      <p id="rfc.section.3.1.p.1">The <dfn>206 (Partial Content)</dfn> status code indicates that the server has fulfilled the partial GET request for the resource. The request <em class="bcp14">MUST</em> have included a <a href="#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.3" title="Range">Section&nbsp;5.4</a>) indicating the desired range, and <em class="bcp14">MAY</em> have included an <a href="#header.if-range" class="smpl">If-Range</a> header field (<a href="#header.if-range" id="rfc.xref.header.if-range.1" title="If-Range">Section&nbsp;5.3</a>) to make the request conditional.
+      </p>
+      <p id="rfc.section.3.1.p.2">When a 206 response is generated, the sender <em class="bcp14">MUST</em> generate the following header fields: 
       </p>
       <ul>
@@ -693 +693 @@
          </li>
       </ul>
-      <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an <a href="#header.if-range" class="smpl">If-Range</a> header field, it <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been sent with a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
+      <p id="rfc.section.3.1.p.3">If a 206 is generated in response to a request with an <a href="#header.if-range" class="smpl">If-Range</a> header field, the sender <em class="bcp14">SHOULD NOT</em> generate other representation header fields beyond those described above. Otherwise, the sender <em class="bcp14">MUST</em> generate all of the same representation header fields that would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request.
       </p>
       <p id="rfc.section.3.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 206 responses.
@@ -699 +699 @@
       <div id="rfc.iref.3"></div>
       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="status.416" href="#status.416">416 Requested Range Not Satisfiable</a></h2>
-      <p id="rfc.section.3.2.p.1">A server <em class="bcp14">SHOULD</em> send a response with this status code if a request included a <a href="#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.4" title="Range">Section&nbsp;5.4</a>), and none of the ranges-specifier values in this field overlap the current extent of the selected resource, and the request
-         did not include an <a href="#header.if-range" class="smpl">If-Range</a> header field (<a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section&nbsp;5.3</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current
-         length of the selected resource.)
-      </p>
-      <p id="rfc.section.3.2.p.2">When this status code is sent in response to a byte-range request, the response <em class="bcp14">SHOULD</em> include a <a href="#header.content-range" class="smpl">Content-Range</a> header field specifying the current length of the representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section&nbsp;5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges media type.
+      <p id="rfc.section.3.2.p.1">The <dfn>416 (Requested Range Not Satisfiable)</dfn> status code indicates that none of the ranges-specifier values in the request's <a href="#range.retrieval.requests" class="smpl">Range</a> header field (<a href="#header.range" id="rfc.xref.header.range.4" title="Range">Section&nbsp;5.4</a>) overlap the current extent of the selected resource and the request did not include an <a href="#header.if-range" class="smpl">If-Range</a> header field (<a href="#header.if-range" id="rfc.xref.header.if-range.2" title="If-Range">Section&nbsp;5.3</a>). (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current
+         length of the selected representation.)
+      </p>
+      <p id="rfc.section.3.2.p.2">When this status code is sent in response to a byte-range request, the sender <em class="bcp14">SHOULD</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field specifying the current length of the selected representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section&nbsp;5.2</a>).
       </p>
       <div id="rfc.figure.u.2"></div> 
@@ -744 +743 @@
          defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
       </p>
-      <p id="rfc.section.4.2.p.2">When a client receives an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> or <a href="#status.206" class="smpl">206 (Partial Content)</a> response and already has one or more stored responses for the same method and effective request URI, all of the stored responses
-         with the same strong validator <em class="bcp14">MAY</em> be combined with the partial content in this new response. If none of the stored responses contain the same strong validator,
-         then this new response corresponds to a new representation and <em class="bcp14">MUST NOT</em> be combined with the existing stored responses.
+      <p id="rfc.section.4.2.p.2">When a client receives an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response or a <a href="#status.206" class="smpl">206 (Partial Content)</a> response, and already has one or more partial responses for the same method and effective request URI that have the same strong
+         validator as present in the new response, the recipient <em class="bcp14">MAY</em> combine some or all of those responses into a set of continuous ranges. A client <em class="bcp14">MUST NOT</em> combine responses that differ in the strong validator or that do not have a strong validator.
       </p>
       <p id="rfc.section.4.2.p.3">If the new response is an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, then the header fields of that new response are used for any combined response and replace those of the matching
@@ -756 +754 @@
       </p>
       <p id="rfc.section.4.2.p.5">The combined response message body consists of the union of partial content ranges in the new response and each of the selected
-         responses. If the union consists of the entire range of the representation, then the combined response <em class="bcp14">MUST</em> be recorded as a complete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response with a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header field that reflects the complete length. Otherwise, the combined response(s) <em class="bcp14">MUST</em> include a <a href="#header.content-range" class="smpl">Content-Range</a> header field describing the included range(s) and be recorded as incomplete. If the union consists of a discontinuous range
-         of the representation, then the client <em class="bcp14">MAY</em> store it as either a multipart range response or as multiple <a href="#status.206" class="smpl">206</a> responses with one continuous range each.
+         responses. If the union consists of the entire range of the representation, then the client <em class="bcp14">MUST</em> record the combined response as if it were a complete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, including a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> header field that reflects the complete length. Otherwise, the client <em class="bcp14">MUST</em> record the set of continuous ranges as one of the following: an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if the combined response is a prefix of the representation, a single <a href="#status.206" class="smpl">206 (Partial Content)</a> response containing a multipart/byteranges body, or multiple <a href="#status.206" class="smpl">206 (Partial Content)</a> responses, each with one continuous range that is indicated by a <a href="#header.content-range" class="smpl">Content-Range</a> header field.
       </p>
       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>

draft-ietf-httpbis/latest/p5-range.xml

@@ -240 +240 @@
   <x:anchor-alias value="206 (Partial Content)"/>
 <t>
-   The server has fulfilled the partial GET request for the resource.
+   The <x:dfn>206 (Partial Content)</x:dfn> status code indicates that the
+   server has fulfilled the partial GET request for the resource.
    The request &MUST; have included a <x:ref>Range</x:ref> header field
    (<xref target="header.range"/>) indicating the desired range, and &MAY; have
@@ -247 +248 @@
 </t>
 <t>
-   The response &MUST; include the following header fields:
+   When a 206 response is generated, the sender &MUST; generate the following
+   header fields:
   <list style="symbols">
     <t>
@@ -270 +272 @@
 </t>
 <t>
-   If a 206 is sent in response to a request with an <x:ref>If-Range</x:ref>
-   header field, it &SHOULD-NOT; include other representation header fields.
-   Otherwise, the response &MUST; include all of the representation header
-   fields that would have been sent with a <x:ref>200 (OK)</x:ref> response
+   If a 206 is generated in response to a request with an <x:ref>If-Range</x:ref>
+   header field, the sender &SHOULD-NOT; generate other representation header
+   fields beyond those described above.
+   Otherwise, the sender &MUST; generate all of the same representation header
+   fields that would have been sent in a <x:ref>200 (OK)</x:ref> response
    to the same request.
 </t>
@@ -286 +289 @@
   <x:anchor-alias value="416 (Requested Range Not Satisfiable)"/>
 <t>
-   A server &SHOULD; send a response with this status code if a request
-   included a <x:ref>Range</x:ref> header field (<xref target="header.range"/>),
-   and none of the ranges-specifier values in this field overlap the current
-   extent of the selected resource, and the request did not include an
+   The <x:dfn>416 (Requested Range Not Satisfiable)</x:dfn> status code
+   indicates that none of the ranges-specifier values in the request's
+   <x:ref>Range</x:ref> header field (<xref target="header.range"/>)
+   overlap the current
+   extent of the selected resource and the request did not include an
    <x:ref>If-Range</x:ref> header field (<xref target="header.if-range"/>).
    (For byte-ranges, this means that the first-byte-pos of all of the
    byte-range-spec values were greater than the current length of the selected
-   resource.)
+   representation.)
 </t>
 <t>
    When this status code is sent in response to a byte-range request, the
-   response &SHOULD; include a <x:ref>Content-Range</x:ref> header field
-   specifying the current length of the representation (see <xref target="header.content-range"/>).
-   This response &MUST-NOT; use the multipart/byteranges media type.
+   sender &SHOULD; generate a <x:ref>Content-Range</x:ref> header field
+   specifying the current length of the selected representation
+   (see <xref target="header.content-range"/>).
 </t>
 <figure>
@@ -377 +381 @@
 </t>
 <t>
-   When a client receives an incomplete <x:ref>200 (OK)</x:ref> or <x:ref>206 (Partial Content)</x:ref>
-   response and already has one or more stored responses for the same method
-   and effective request URI, all of the stored responses with the same
-   strong validator &MAY; be combined with the partial content in this new
-   response.  If none of the stored responses contain the same strong
-   validator, then this new response corresponds to a new representation
-   and &MUST-NOT; be combined with the existing stored responses.
-</t>
-<t>
-   If the new response is an incomplete <x:ref>200 (OK)</x:ref> response, then the header
-   fields of that new response are used for any combined response and replace
-   those of the matching stored responses.
-</t>
-<t>
-   If the new response is a <x:ref>206 (Partial Content)</x:ref> response and at least one
-   of the matching stored responses is a <x:ref>200 (OK)</x:ref>, then the combined response
-   header fields consist of the most recent 200 response's header fields.
-   If all of the matching stored responses are 206 responses, then the
-   stored response with the most recent header fields is used as the source of
-   header fields for the combined response, except that the client &MUST;
-   use other header fields provided in the new response, aside from
-   <x:ref>Content-Range</x:ref>, to replace all instances of the corresponding
-   header fields in the stored response.
+   When a client receives an incomplete <x:ref>200 (OK)</x:ref> response or a
+   <x:ref>206 (Partial Content)</x:ref> response, and already has one or more
+   partial responses for the same method and effective request URI that have
+   the same strong validator as present in the new response,
+   the recipient &MAY; combine some or all of those responses into a set of
+   continuous ranges. A client &MUST-NOT; combine responses that differ in the
+   strong validator or that do not have a strong validator.
+</t>
+<t>
+   If the new response is an incomplete <x:ref>200 (OK)</x:ref> response, then
+   the header fields of that new response are used for any combined response
+   and replace those of the matching stored responses.
+</t>
+<t>
+   If the new response is a <x:ref>206 (Partial Content)</x:ref> response and
+   at least one of the matching stored responses is a <x:ref>200 (OK)</x:ref>,
+   then the combined response header fields consist of the most recent 200
+   response's header fields. If all of the matching stored responses are 206
+   responses, then the stored response with the most recent header fields is
+   used as the source of header fields for the combined response, except that
+   the client &MUST; use other header fields provided in the new response,
+   aside from <x:ref>Content-Range</x:ref>, to replace all instances of the
+   corresponding header fields in the stored response.
 </t>
 <t>
@@ -405 +409 @@
    content ranges in the new response and each of the selected responses.
    If the union consists of the entire range of the representation, then the
-   combined response &MUST; be recorded as a complete <x:ref>200 (OK)</x:ref>
-   response with a <x:ref>Content-Length</x:ref> header field that reflects the
-   complete length. Otherwise, the combined response(s) &MUST; include a
-   <x:ref>Content-Range</x:ref> header field describing the included range(s)
-   and be recorded as incomplete.  If the union consists of a discontinuous
-   range of the representation, then the client &MAY; store it as either a
-   multipart range response or as multiple <x:ref>206</x:ref> responses with
-   one continuous range each.
+   client &MUST; record the combined response as if it were a complete
+   <x:ref>200 (OK)</x:ref> response, including a <x:ref>Content-Length</x:ref>
+   header field that reflects the complete length.
+   Otherwise, the client &MUST; record the set of continuous ranges as one of
+   the following:
+   an incomplete <x:ref>200 (OK)</x:ref> response if the combined response is
+   a prefix of the representation,
+   a single <x:ref>206 (Partial Content)</x:ref> response containing a
+   multipart/byteranges body, or
+   multiple <x:ref>206 (Partial Content)</x:ref> responses, each with one
+   continuous range that is indicated by a <x:ref>Content-Range</x:ref> header
+   field.
 </t>
 </section>

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

@@ -452 +452 @@
   } 
   @bottom-center {
-       content: "Expires June 19, 2013"; 
+       content: "Expires July 2, 2013"; 
   } 
   @bottom-right {
@@ -498 +498 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-12-16">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
@@ -524 +524 @@
             </tr>
             <tr>
-               <td class="left">Expires: June 19, 2013</td>
+               <td class="left">Expires: July 2, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -533 +533 @@
             <tr>
                <td class="left"></td>
-               <td class="right">December 16, 2012</td>
+               <td class="right">December 29, 2012</td>
             </tr>
          </tbody>
@@ -559 +559 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on June 19, 2013.</p>
+      <p>This Internet-Draft will expire on July 2, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -884 +884 @@
       <p id="rfc.section.4.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;7.2.3</a>.
       </p>
-      <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;7.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>.
+      <p id="rfc.section.4.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> send a single <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;7.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;4.1.3</a>.
       </p>
       <p id="rfc.section.4.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request

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

@@ -505 +505 @@
 <t>
    When a stored response is used to satisfy a request without validation,
-   a cache &MUST; include a single <x:ref>Age</x:ref> header field
+   a cache &MUST; send a single <x:ref>Age</x:ref> header field
    (<xref target="header.age"/>) in the response with a value equal to the
    stored response's current_age; see <xref target="age.calculations" />.

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires June 18, 2013"; 
+       content: "Expires July 2, 2013"; 
   } 
   @bottom-right {
@@ -489 +489 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-12-15">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-12-29">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.">
@@ -517 +517 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">December 15, 2012</td>
+               <td class="right">December 29, 2012</td>
             </tr>
             <tr>
-               <td class="left">Expires: June 18, 2013</td>
+               <td class="left">Expires: July 2, 2013</td>
                <td class="right"></td>
             </tr>
@@ -546 +546 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on June 18, 2013.</p>
+      <p>This Internet-Draft will expire on July 2, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -679 +679 @@
       <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  <a href="#challenge.and.response" class="smpl">credentials</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#imported.abnf" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">token68</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ]
 </pre><p id="rfc.section.2.1.p.14">Upon a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial
-         credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> send a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field containing at least one (possibly new) challenge applicable to the requested resource.
+         credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> send a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response that contains a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field with at least one (possibly new) challenge applicable to the requested resource.
       </p>
       <p id="rfc.section.2.1.p.15">Likewise, upon a request that requires authentication by proxies that omit credentials or contain invalid or partial credentials,
-         a proxy <em class="bcp14">SHOULD</em> send a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field containing a (possibly new) challenge applicable to the proxy.
+         a proxy <em class="bcp14">SHOULD</em> send a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response that contains a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field with a (possibly new) challenge applicable to the proxy.
       </p>
       <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the <a href="p2-semantics.html#status.403" class="smpl">403 (Forbidden)</a> status code (<a href="p2-semantics.html#status.403" title="403 Forbidden">Section 6.5.3</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
@@ -778 +778 @@
       <div id="rfc.iref.8"></div>
       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="status.401" href="#status.401">401 Unauthorized</a></h2>
-      <p id="rfc.section.3.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been
-         refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has
-         already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the representation that was given in the response, since that representation might include relevant diagnostic
-         information.
+      <p id="rfc.section.3.1.p.1">The <dfn>401 (Unauthorized)</dfn> status code indicates that the request has not been applied because it lacks valid authentication credentials for the target
+         resource. The origin server <em class="bcp14">MUST</em> send a <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a> header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;4.4</a>) containing at least one challenge applicable to the target resource. If the request included authentication credentials,
+         then the 401 response indicates that authorization has been refused for those credentials. The client <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.authorization" class="smpl">Authorization</a> header field (<a href="#header.authorization" id="rfc.xref.header.authorization.2" title="Authorization">Section&nbsp;4.1</a>). If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication
+         at least once, then the user agent <em class="bcp14">SHOULD</em> present the enclosed representation to the user, since it usually contains relevant diagnostic information.
       </p>
       <div id="rfc.iref.8"></div>
       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2>
-      <p id="rfc.section.3.2.p.1">This code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client ought to first authenticate itself with the proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.3</a>).
+      <p id="rfc.section.3.2.p.1">The <dfn>407 (Proxy Authentication Required)</dfn> status code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client needs to authenticate itself in order to use a proxy. The proxy <em class="bcp14">MUST</em> send a <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.2</a>) containing a challenge applicable to that proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a new or replaced <a href="#header.proxy-authorization" class="smpl">Proxy-Authorization</a> header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.3</a>).
       </p>
       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>

draft-ietf-httpbis/latest/p7-auth.xml

@@ -242 +242 @@
    invalid credentials (e.g., a bad password) or partial credentials (e.g.,
    when the authentication scheme requires more than one round trip), an origin
-   server &SHOULD; send a <x:ref>401 (Unauthorized)</x:ref> response. Such
-   responses &MUST; include a <x:ref>WWW-Authenticate</x:ref> header field
-   containing at least one (possibly new) challenge applicable to the
-   requested resource.
+   server &SHOULD; send a <x:ref>401 (Unauthorized)</x:ref> response that
+   contains a <x:ref>WWW-Authenticate</x:ref> header field with at least one
+   (possibly new) challenge applicable to the requested resource.
 </t>
 <t>
    Likewise, upon a request that requires authentication by proxies that omit
    credentials or contain invalid or partial credentials, a proxy &SHOULD;
-   send a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses
-   &MUST; include a <x:ref>Proxy-Authenticate</x:ref> header field containing a (possibly
+   send a <x:ref>407 (Proxy Authentication Required)</x:ref> response that
+   contains a <x:ref>Proxy-Authenticate</x:ref> header field with a (possibly
    new) challenge applicable to the proxy.
 </t>
@@ -427 +426 @@
   <x:anchor-alias value="401 (Unauthorized)"/>
 <t>
-   The request requires user authentication. The response &MUST; include a
+   The <x:dfn>401 (Unauthorized)</x:dfn> status code indicates that the
+   request has not been applied because it lacks valid authentication
+   credentials for the target resource. The origin server &MUST; send a
    <x:ref>WWW-Authenticate</x:ref> header field (<xref target="header.www-authenticate"/>)
-   containing a challenge applicable to the target resource. The client &MAY;
-   repeat the request with a suitable <x:ref>Authorization</x:ref> header field
-   (<xref target="header.authorization"/>). If the request already included
-   Authorization credentials, then the 401 response indicates that authorization
-   has been refused for those credentials. If the 401 response contains the
-   same challenge as the prior response, and the user agent has already attempted
-   authentication at least once, then the user &SHOULD; be presented the
-   representation that was given in the response, since that representation might
-   include relevant diagnostic information.
+   containing at least one challenge applicable to the target resource.
+   If the request included authentication credentials, then the 401 response
+   indicates that authorization has been refused for those credentials.
+   The client &MAY; repeat the request with a new or replaced
+   <x:ref>Authorization</x:ref> header field (<xref target="header.authorization"/>).
+   If the 401 response contains the same challenge as the prior response, and
+   the user agent has already attempted authentication at least once, then the
+   user agent &SHOULD; present the enclosed representation to the user, since
+   it usually contains relevant diagnostic information.
 </t>
 </section>
@@ -444 +445 @@
   <x:anchor-alias value="407 (Proxy Authentication Required)"/>
 <t>
-   This code is similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the
-   client ought to first authenticate itself with the proxy. The proxy &MUST;
-   send a <x:ref>Proxy-Authenticate</x:ref> header field (<xref target="header.proxy-authenticate"/>) containing a
-   challenge applicable to the proxy for the target resource. The
-   client &MAY; repeat the request with a suitable <x:ref>Proxy-Authorization</x:ref>
+   The <x:dfn>407 (Proxy Authentication Required)</x:dfn> status code is
+   similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the client
+   needs to authenticate itself in order to use a proxy.
+   The proxy &MUST; send a <x:ref>Proxy-Authenticate</x:ref> header field
+   (<xref target="header.proxy-authenticate"/>) containing a challenge
+   applicable to that proxy for the target resource. The client &MAY; repeat
+   the request with a new or replaced <x:ref>Proxy-Authorization</x:ref>
    header field (<xref target="header.proxy-authorization"/>).
 </t>