Changeset 1735

Timestamp:

Jul 6, 2012, 7:48:51 AM (7 years ago)

Author:

julian.reschke@…

Message:

Work-in-progress: hyperlink status codes definitions (P2)

Location:

draft-ietf-httpbis/latest

Files:

• p0-introduction.html (modified) (5 diffs)
• p1-messaging.html (modified) (3 diffs)
• p1-messaging.xml (modified) (3 diffs)
• p2-semantics.html (modified) (9 diffs)
• p2-semantics.xml (modified) (13 diffs)
• p3-payload.html (modified) (5 diffs)
• p5-range.html (modified) (1 diff)
• p5-range.xml (modified) (2 diffs)
• p6-cache.html (modified) (3 diffs)
• p6-cache.xml (modified) (5 diffs)
• p7-auth.html (modified) (4 diffs)

draft-ietf-httpbis/latest/p0-introduction.html

@@ -393 +393 @@
   } 
   @bottom-center {
-       content: "Expires January 6, 2013"; 
+       content: "Expires January 7, 2013"; 
   } 
   @bottom-right {
@@ -426 +426 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-07-05">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
       <meta name="dct.abstract" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
       <meta name="description" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
@@ -446 +446 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 6, 2013</td>
+               <td class="left">Expires: January 7, 2013</td>
                <td class="right">W3C</td>
             </tr>
@@ -467 +467 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 5, 2012</td>
+               <td class="right">July 6, 2012</td>
             </tr>
          </tbody>
@@ -491 +491 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 6, 2013.</p>
+      <p>This Internet-Draft will expire on January 7, 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>

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

@@ -1376 +1376 @@
       <p id="rfc.section.3.3.p.5">The presence of a message body in a response depends on both the request method to which it is responding and the response
          status code (<a href="#status-code">Paragraph&nbsp;3</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g.,
-         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304
-            (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)
+         Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> responses to CONNECT switch to tunnel mode instead of having a message body. All <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, and <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. (See <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> and <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.)
       </p>
       <div id="rfc.iref.t.4"></div>
@@ -1445 +1444 @@
       <ol>
          <li>
-            <p>Any response to a HEAD request and any response with a status code of 100-199, 204, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> is always terminated by the first empty line after the header fields, regardless of the header fields present in the message,
-               and thus cannot contain a message body.
+            <p>Any response to a HEAD request and any response with a <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a>, <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> status code is always terminated by the first empty line after the header fields, regardless of the header fields present
+               in the message, and thus cannot contain a message body.
             </p>
          </li>
@@ -1971 +1970 @@
       <p id="rfc.section.5.7.p.1">HTTP does not include a request identifier for associating a given request message with its corresponding one or more response
          messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made
-         on the same connection. More than one response message per request only occurs when one or more informational responses (1xx,
-         see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.
+         on the same connection. More than one response message per request only occurs when one or more informational responses (<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>, see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) precede a final response to the same request.
       </p>
       <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-<a href="p2-semantics.html#status.1xx" class="smpl">1xx</a>) response.

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

@@ -1484 +1484 @@
    <x:ref>2xx (Successful)</x:ref> responses to CONNECT switch to tunnel mode instead of
    having a message body.
-   All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and <x:ref>304
-   (Not Modified)</x:ref> responses &MUST-NOT; include a message body.
+   All <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, and
+   <x:ref>304 (Not Modified)</x:ref> responses &MUST-NOT; include a message body.
    All other responses do include a message body, although the body
    &MAY; be of zero length. (See &status-codes; and &status-304;.)
@@ -1643 +1643 @@
   <list style="numbers">
     <x:lt><t>
-     Any response to a HEAD request and any response with a status
-     code of 100-199, 204, or <x:ref>304 (Not Modified)</x:ref> is always
+     Any response to a HEAD request and any response with a 
+     <x:ref>1xx (Informational)</x:ref>, <x:ref>204 (No Content)</x:ref>, or
+     <x:ref>304 (Not Modified)</x:ref> status code is always
      terminated by the first empty line after the header fields, regardless of
      the header fields present in the message, and thus cannot contain a
@@ -2662 +2663 @@
    to the order in which requests are made on the same connection.
    More than one response message per request only occurs when one or more
-   informational responses (1xx, see &status-1xx;) precede a final response
+   informational responses (<x:ref>1xx</x:ref>, see &status-1xx;) precede a final response
    to the same request.
 </t>

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

@@ -966 +966 @@
          with that resource.
       </p>
-      <p id="rfc.section.2.3.1.p.6">A 200 response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g.,
+      <p id="rfc.section.2.3.1.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g.,
          Allow), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
          but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a Content-Length field with a field-value of "0".
@@ -1801 +1801 @@
          <p> <b>Note:</b> In HTTP/1.0, only the status codes <a href="#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="#status.302" class="smpl">302 (Found)</a> were defined for the first type of redirect, and the second type did not exist at all (<a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, <a href="http://tools.ietf.org/html/rfc1945#section-9.3">Section 9.3</a>). However it turned out that web forms using POST expected redirects to change the operation for the subsequent request to
             retrieval (GET). To address this use case, HTTP/1.1 introduced the second type of redirect with the status code <a href="#status.303" class="smpl">303 (See Other)</a> (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3.4">Section 10.3.4</a>). As user agents did not change their behavior to maintain backwards compatibility, the first revision of HTTP/1.1 added
-            yet another status code, <a href="#status.307" class="smpl">307 (Temporary Redirect)</a>, for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes 301 and 302, therefore this specification
-            makes that behavior conformant in case the original request was POST.
+            yet another status code, <a href="#status.307" class="smpl">307 (Temporary Redirect)</a>, for which the backwards compatibility problems did not apply (<a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-10.3.8">Section 10.3.8</a>). Over 10 years later, most user agents still do method rewriting for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>, therefore this specification makes that behavior conformant in case the original request was POST.
          </p> 
       </div>
@@ -2084 +2083 @@
       </p>
       <div class="note" id="rfc.section.4.7.5.p.2"> 
-         <p> <b>Note</b> to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.
+         <p> <b>Note</b> to implementors: some deployed proxies are known to return <a href="#status.400" class="smpl">400 (Bad Request)</a> or <a href="#status.500" class="smpl">500 (Internal Server
+               Error)</a> when DNS lookups time out.
          </p> 
       </div>
@@ -2391 +2391 @@
                (Non-Authoritative Information)</a> and the request method was GET, the response payload is a representation of the target resource.
          </li>
-         <li>If the response status code is <a href="#status.204" class="smpl">204 (No Content)</a>, 206 (Partial Content, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> and the request method was GET or HEAD, the response payload is a partial representation of the target resource.
+         <li>If the response status code is <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> and the request method was GET or HEAD, the response payload is a partial representation of the target resource.
          </li>
          <li>If the response has a Content-Location header field, and that URI is the same as the effective request URI, the response payload
@@ -2407 +2407 @@
       <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
       <p id="rfc.section.7.2.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message
-         body is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request
-         with the same effective request URI.
+         body is present, about the representation that would have been transferred in a <a href="#status.200" class="smpl">200 (OK)</a> response to a simultaneous GET request with the same effective request URI.
       </p>
       <p id="rfc.section.7.2.p.2">The following header fields are defined as representation metadata:</p>
@@ -2850 +2849 @@
       <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
       <p id="rfc.section.9.8.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
-         message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response
-         would contain the same representation that is enclosed as payload in this message.
+         message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a <a href="#status.200" class="smpl">200 (OK)</a> response would contain the same representation that is enclosed as payload in this message.
       </p>
       <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.43"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
@@ -2870 +2868 @@
          indicates that this representation contains a report on the action's status and the same report is available (for future access
          with GET) at the given URI. For example, a purchase transaction made via a POST request might include a receipt document as
-         the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt
-         in the future.
+         the payload of the <a href="#status.200" class="smpl">200 (OK)</a> response; the Content-Location value provides an identifier for retrieving a copy of that same receipt in the future.
       </p>
       <p id="rfc.section.9.8.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
@@ -2984 +2981 @@
       </p>
       <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#abnf.dependencies" class="smpl">URI-reference</a>
-</pre><p id="rfc.section.9.13.p.3">For <a href="#status.201" class="smpl">201 (Created)</a> responses, the Location is the URI of the new resource which was created by the request. For <a href="#status.3xx" class="smpl">3xx</a> responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
+</pre><p id="rfc.section.9.13.p.3">For <a href="#status.201" class="smpl">201 (Created)</a> responses, the Location is the URI of the new resource which was created by the request. For <a href="#status.3xx" class="smpl">3xx (Redirection)</a> responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
       </p>
       <p id="rfc.section.9.13.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,
@@ -3970 +3967 @@
       <p id="rfc.section.C.p.5">Broadened the definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section&nbsp;4.4.4</a>)
       </p>
-      <p id="rfc.section.C.p.6">Status codes 301, 302, and 307: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section&nbsp;4.5</a>)
+      <p id="rfc.section.C.p.6">Status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a>: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section&nbsp;4.5</a>)
       </p>
       <p id="rfc.section.C.p.7">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the
          user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite
-         the method from POST to GET for status codes 301 and 302. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">4.5.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">4.5.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">4.5.7</a>)
+         the method from POST to GET for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">4.5.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">4.5.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">4.5.7</a>)
       </p>
       <p id="rfc.section.C.p.8">Deprecate <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code, because user agents did not implement it. It used to indicate that the target resource needs to be accessed through

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

@@ -542 +542 @@
 </t>
 <t>
-   A 200 response &SHOULD; include any header fields that indicate
-   optional features implemented by the server and applicable to that
+   A <x:ref>200 (OK)</x:ref> response &SHOULD; include any header fields that
+   indicate optional features implemented by the server and applicable to that
    resource (e.g., Allow), possibly including extensions not defined by
    this specification. The response body, if any, &SHOULD; also include
@@ -1587 +1587 @@
     <x:ref>307 (Temporary Redirect)</x:ref>, for which the backwards
     compatibility problems did not apply (<xref target="RFC2616" x:fmt="," x:sec="10.3.8"/>).
-    Over 10 years later, most user agents still do method rewriting for
-    status codes 301 and 302, therefore this specification makes that behavior
+    Over 10 years later, most user agents still do method rewriting for status codes
+    <x:ref>301</x:ref> and <x:ref>302</x:ref>, therefore this specification makes that behavior
     conformant in case the original request was POST.
   </t>
@@ -1650 +1650 @@
   <iref primary="true" item="301 Moved Permanently (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="301 Moved Permanently" x:for-anchor=""/>
+  <x:anchor-alias value="301"/>
   <x:anchor-alias value="301 (Moved Permanently)"/>
 <t>
@@ -1680 +1681 @@
   <iref primary="true" item="302 Found (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="302 Found" x:for-anchor=""/>
+  <x:anchor-alias value="302"/>
   <x:anchor-alias value="302 (Found)"/>
 <t>
@@ -1766 +1768 @@
   <iref primary="true" item="307 Temporary Redirect (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="307 Temporary Redirect" x:for-anchor=""/>
+  <x:anchor-alias value="307"/>
   <x:anchor-alias value="307 (Temporary Redirect)"/>
 <t>
@@ -2147 +2150 @@
   <t>
     <x:h>Note</x:h> to implementors: some deployed proxies are known to
-    return 400 or 500 when DNS lookups time out.
+    return <x:ref>400 (Bad Request)</x:ref> or <x:ref>500 (Internal Server
+    Error)</x:ref> when DNS lookups time out.
   </t>
 </x:note>
@@ -2708 +2712 @@
    the response payload is a representation of the target resource.</t>
    <t>If the response status code is <x:ref>204 (No Content)</x:ref>,
-   <x:ref>206 (Partial Content</x:ref>, or <x:ref>304 (Not Modified)</x:ref>
+   <x:ref>206 (Partial Content)</x:ref>, or <x:ref>304 (Not Modified)</x:ref>
    and the request method was GET or HEAD, the response payload is a partial
    representation of the target resource.</t>
@@ -2734 +2738 @@
    Representation header fields define metadata about the representation data
    enclosed in the message body or, if no message body is present, about
-   the representation that would have been transferred in a 200 response
-   to a simultaneous GET request with the same effective request URI.
+   the representation that would have been transferred in a <x:ref>200 (OK)</x:ref>
+   response to a simultaneous GET request with the same effective request URI.
 </t>
 <t>
@@ -3454 +3458 @@
    as a specific identifier for the representation in this message.
    In other words, if one were to perform a GET on this URI at the time
-   of this message's generation, then a 200 response would contain the
-   same representation that is enclosed as payload in this message.
+   of this message's generation, then a <x:ref>200 (OK)</x:ref> response would
+   contain the same representation that is enclosed as payload in this message.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
@@ -3492 +3496 @@
    available (for future access with GET) at the given URI.  For
    example, a purchase transaction made via a POST request might
-   include a receipt document as the payload of the 200 response;
-   the Content-Location value provides an identifier for retrieving
+   include a receipt document as the payload of the <x:ref>200 (OK)</x:ref>
+   response; the Content-Location value provides an identifier for retrieving
    a copy of that same receipt in the future.
 </t>
@@ -3732 +3736 @@
 <t>
    For <x:ref>201 (Created)</x:ref> responses, the Location is the URI of the
-   new resource which was created by the request. For <x:ref>3xx</x:ref> responses, the
-   location &SHOULD; indicate the server's preferred URI for automatic
-   redirection to the resource.
+   new resource which was created by the request. For <x:ref>3xx (Redirection)</x:ref>
+   responses, the location &SHOULD; indicate the server's preferred URI for
+   automatic redirection to the resource.
 </t>
 <t>
@@ -5470 +5474 @@
 </t>
 <t>
-  Status codes 301, 302, and 307: removed the normative requirements on both
-  response payloads and user interaction.
+  Status codes <x:ref>301</x:ref>, <x:ref>302</x:ref>, and <x:ref>307</x:ref>:
+  removed the normative requirements on both response payloads and user interaction.
   (<xref target="status.3xx"/>)
 </t>
@@ -5479 +5483 @@
   that determination based on the request method semantics.
   Furthermore, allow user agents to rewrite the method from POST to GET
-  for status codes 301 and 302.
+  for status codes <x:ref>301</x:ref> and <x:ref>302</x:ref>.
   (Sections <xref format="counter" target="status.301"/>,
   <xref format="counter" target="status.302"/> and

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

@@ -374 +374 @@
   } 
   @bottom-center {
-       content: "Expires January 2, 2013"; 
+       content: "Expires January 7, 2013"; 
   } 
   @bottom-right {
@@ -404 +404 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-07-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
       <meta name="dct.abstract" content="This part is now obsolete. Please see HTTPbis, Part 2.">
       <meta name="description" content="This part is now obsolete. Please see HTTPbis, Part 2.">
@@ -424 +424 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 2, 2013</td>
+               <td class="left">Expires: January 7, 2013</td>
                <td class="right">W3C</td>
             </tr>
@@ -437 +437 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 1, 2012</td>
+               <td class="right">July 6, 2012</td>
             </tr>
          </tbody>
@@ -453 +453 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 2, 2013.</p>
+      <p>This Internet-Draft will expire on January 7, 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>

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

@@ -805 +805 @@
       </p>
       <p id="rfc.section.4.2.p.4">If the new response is a <a href="#status.206" class="smpl">206 (Partial Content)</a> response and at least one of the matching stored responses is a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, then the combined response header fields consist of the most recent 200 response's header fields. If all of the matching
-         stored responses are <a href="#status.206" class="smpl">206</a> responses, then the stored response with the most header fields is used as the source of header fields for the combined response,
-         except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding
+         stored responses are 206 responses, then the stored response with the most header fields is used as the source of header fields
+         for the combined response, except that the client <em class="bcp14">MUST</em> use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding
          header fields in the stored response.
       </p>

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

@@ -462 +462 @@
    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 <x:ref>206</x:ref> responses, then the
+   If all of the matching stored responses are 206 responses, then the
    stored response with the most header fields is used as the source of
    header fields for the combined response, except that the client &MUST;
@@ -1023 +1023 @@
   <x:source href="p2-semantics.xml" basename="p2-semantics">
     <x:defines>200 (OK)</x:defines>
+    <x:defines>410 (Gone)</x:defines>
   </x:source>
 </reference>

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

@@ -965 +965 @@
       <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4>
       <p id="rfc.section.2.3.1.1.p.1">If no explicit expiration time is present in a stored response that has a status code whose definition allows heuristic freshness
-         to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>: 200, 203, <a href="p5-range.html#status.206" class="smpl">206</a>, 300, 301 and 410), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
+         to be used (including the following in <a href="p2-semantics.html#status.codes" title="Status Codes">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203
+            (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, <a href="p2-semantics.html#status.300" class="smpl">300 (Multiple Choices)</a>, <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="p2-semantics.html#status.410" class="smpl">410 (Gone)</a>), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
       </p>
       <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning
@@ -1092 +1093 @@
             request is suitable. Instead, the cache can use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
          </li>
-         <li>However, if a cache receives a 5xx response while attempting to validate a response, it can either forward this response to
-            the requesting client, or act as if the server failed to respond. In the latter case, it can return a previously stored response
-            (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
+         <li>However, if a cache receives a <a href="p2-semantics.html#status.5xx" class="smpl">5xx (Server Error)</a> response while attempting to validate a response, it can either forward this response to the requesting client, or act as
+            if the server failed to respond. In the latter case, it can return a previously stored response (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;2.3.3</a>).
          </li>
       </ul>
@@ -1152 +1152 @@
       <p id="rfc.section.2.6.p.4">A cache <em class="bcp14">MUST</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) when it receives a non-error response to a request with a method whose safety is unknown.
       </p>
-      <p id="rfc.section.2.6.p.5">Here, a "non-error response" is one with a <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> or <a href="p2-semantics.html#status.3xx" class="smpl">3xx</a> status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI,
+      <p id="rfc.section.2.6.p.5">Here, a "non-error response" is one with a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="p2-semantics.html#status.3xx" class="smpl">3xx (Redirection)</a> status code. "Invalidate" means that the cache will either remove all stored responses related to the effective request URI,
          or will mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent
          request.

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

@@ -683 +683 @@
    If no explicit expiration time is present in a stored response that has a
    status code whose definition allows heuristic freshness to be used
-   (including the following in &status-codes;: 200, 203, <x:ref>206</x:ref>, 300, 301 and
-   410), a cache &MAY; calculate a heuristic expiration time. A cache &MUST-NOT; 
+   (including the following in &status-codes;: <x:ref>200 (OK)</x:ref>, <x:ref>203
+   (Non-Authoritative Information)</x:ref>, <x:ref>206 (Partial Content)</x:ref>,
+   <x:ref>300 (Multiple Choices)</x:ref>, <x:ref>301 (Moved Permanently)</x:ref> and
+   <x:ref>410 (Gone)</x:ref>), a cache &MAY; calculate a heuristic expiration time. A cache &MUST-NOT; 
    use heuristics to determine freshness for responses with status codes that do 
    not explicitly allow it.
@@ -923 +925 @@
       </t>
       <t>
-         However, if a cache receives a 5xx response while attempting to
-         validate a response, it can either forward this response to the
-         requesting client, or act as if the server failed to respond. In the
-         latter case, it can return a previously stored response (see <xref
-         target="serving.stale.responses" />).
+         However, if a cache receives a <x:ref>5xx (Server Error)</x:ref>
+         response while attempting to validate a response, it can either
+         forward this response to the requesting client, or act as if the
+         server failed to respond. In the latter case, it can return a
+         previously stored response (see <xref target="serving.stale.responses" />).
       </t>
    </list>
@@ -1033 +1035 @@
 </t>
 <t>
-   Here, a "non-error response" is one with a <x:ref>2xx</x:ref> or <x:ref>3xx</x:ref> status code.
+   Here, a "non-error response" is one with a <x:ref>2xx (Successful)</x:ref> or
+   <x:ref>3xx (Redirection)</x:ref> status code.
    "Invalidate" means that the cache will either remove all stored
    responses related to the effective request URI, or will mark these as
@@ -2294 +2297 @@
     <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" />
     <x:source basename="p2-semantics" href="p2-semantics.xml">
-      <x:defines>2xx</x:defines>
+      <x:defines>2xx (Successful)</x:defines>
       <x:defines>200 (OK)</x:defines>
-      <x:defines>3xx</x:defines>
+      <x:defines>203 (Non-Authoritative Information)</x:defines>
+      <x:defines>3xx (Redirection)</x:defines>
+      <x:defines>300 (Multiple Choices)</x:defines>
+      <x:defines>301 (Moved Permanently)</x:defines>
       <x:defines>404 (Not Found)</x:defines>
+      <x:defines>410 (Gone)</x:defines>
+      <x:defines>5xx (Server Error)</x:defines>
       <x:defines>504 (Gateway Timeout)</x:defines>
     </x:source>
@@ -2345 +2353 @@
     <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;" />
     <x:source basename="p5-range" href="p5-range.xml">
-      <x:defines>206</x:defines>
       <x:defines>206 (Partial Content)</x:defines>
     </x:source>

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 6, 2013"; 
+       content: "Expires January 7, 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-07-05">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
       <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. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines the HTTP Authentication framework.">
@@ -520 +520 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 6, 2013</td>
+               <td class="left">Expires: January 7, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">July 5, 2012</td>
+               <td class="right">July 6, 2012</td>
             </tr>
          </tbody>
@@ -553 +553 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 6, 2013.</p>
+      <p>This Internet-Draft will expire on January 7, 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>