Changeset 1715

Timestamp:

04/07/12 19:54:55 (10 years ago)

Author:

julian.reschke@…

Message:

Work-in-progress: hyperlink status codes definitions (2xx range)

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (2 diffs)
• p1-messaging.xml (modified) (3 diffs)
• p2-semantics.html (modified) (11 diffs)
• p2-semantics.xml (modified) (18 diffs)
• p4-conditional.html (modified) (8 diffs)
• p4-conditional.xml (modified) (4 diffs)
• p5-range.html (modified) (11 diffs)
• p5-range.xml (modified) (11 diffs)
• p6-cache.html (modified) (3 diffs)
• p6-cache.xml (modified) (4 diffs)

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

@@ -1377 +1377 @@
          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.
-         Successful (2xx) responses to CONNECT switch to tunnel mode instead of having a message body. All 1xx (Informational), 204
-         (No Content), 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">[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>.)
+         Successful (2xx) responses to CONNECT switch to tunnel mode instead of having a message body. All 1xx (Informational), <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">[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>
@@ -1429 +1429 @@
 </pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential
          transfer-coding) that would have been sent had the request been a GET. In the case of a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response (<a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would
-         have been sent in a 200 (OK) response.
+         have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
       </p>
       <p id="rfc.section.3.3.2.p.6">HTTP's use of Content-Length is significantly different from how it is used in MIME, where it is an optional field used only

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

@@ -1484 +1484 @@
    Successful (2xx) responses to CONNECT switch to tunnel mode instead of
    having a message body.
-   All 1xx (Informational), 204 (No Content), and <x:ref>304 (Not Modified)</x:ref>
-   responses &MUST-NOT; include a message body.
+   All 1xx (Informational), <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;.)
@@ -1606 +1606 @@
    In the case of a <x:ref>304 (Not Modified)</x:ref> response (&status-304;)
    to a GET request, Content-Length indicates the size of the payload body (without
-   any potential transfer-coding) that would have been sent in a 200 (OK)
+   any potential transfer-coding) that would have been sent in a <x:ref>200 (OK)</x:ref>
    response.
 </t>
@@ -4109 +4109 @@
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
   <x:source href="p2-semantics.xml" basename="p2-semantics">
+    <x:defines>200 (OK)</x:defines>
+    <x:defines>204 (No Content)</x:defines>
     <x:defines>301 (Moved Permanently)</x:defines>
     <x:defines>400 (Bad Request)</x:defines>

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

@@ -1021 +1021 @@
          URI.
       </p>
-      <p id="rfc.section.2.3.4.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either
-         200 (OK) or 204 (No Content) is the appropriate response status code, depending on whether or not the response includes a
-         representation that describes the result.
-      </p>
-      <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be 201 (Created) and contain a representation which describes the status of the request and refers to the new resource, and
-         a Location header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;9.13</a>).
+      <p id="rfc.section.2.3.4.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> is the appropriate response status code, depending on whether or not the response includes a representation that describes
+         the result.
+      </p>
+      <p id="rfc.section.2.3.4.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a Location header
+         field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;9.13</a>).
       </p>
       <p id="rfc.section.2.3.4.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;9.8</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
@@ -1037 +1036 @@
       <p id="rfc.section.2.3.5.p.1">The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation
          enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on
-         that same target resource will result in an equivalent representation being returned in a 200 (OK) response. However, there
-         is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents
-         in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful
-         response only implies that the user agent's intent was achieved at the time of its processing by the origin server.
-      </p>
-      <p id="rfc.section.2.3.5.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that
-         representation is successfully modified in accordance with the state of the enclosed representation, then either a 200 (OK)
-         or 204 (No Content) response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
+         that same target resource will result in an equivalent representation being returned in a <a href="#status.200" class="smpl">200 (OK)</a> response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted
+         upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent
+         GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing
+         by the origin server.
+      </p>
+      <p id="rfc.section.2.3.5.p.2">If the target resource does not have a current representation and the PUT successfully creates one, then the origin server <em class="bcp14">MUST</em> inform the user agent by sending a <a href="#status.201" class="smpl">201 (Created)</a> response. If the target resource does have a current representation and that representation is successfully modified in accordance
+         with the state of the enclosed representation, then either a <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.204" class="smpl">204 (No Content)</a> response <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
       </p>
       <p id="rfc.section.2.3.5.p.3">Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored (i.e., not saved as part of the resource state).
@@ -1100 +1098 @@
          location.
       </p>
-      <p id="rfc.section.2.3.6.p.2">A successful response <em class="bcp14">SHOULD</em> be 200 (OK) if the response includes an representation describing the status, 202 (Accepted) if the action has not yet been
-         enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation.
+      <p id="rfc.section.2.3.6.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes an representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation.
       </p>
       <p id="rfc.section.2.3.6.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing
@@ -1112 +1109 @@
       <div id="rfc.iref.t.1"></div>
       <div id="rfc.iref.m.7"></div>
-      <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a 200 (OK) response. The final recipient is either
-         the origin server or the first proxy to receive a Max-Forwards value of zero (0) in the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
+      <p id="rfc.section.2.3.7.p.1">The TRACE method requests a remote, application-layer loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response. The final recipient is either the origin server or the first proxy to receive a Max-Forwards value of zero (0) in
+         the request (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;9.14</a>). A TRACE request <em class="bcp14">MUST NOT</em> include a message body.
       </p>
       <p id="rfc.section.2.3.7.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
@@ -1704 +1701 @@
          can be omitted (e.g., in the case of a response to a PUT request).
       </p>
-      <p id="rfc.section.4.4.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead.
+      <p id="rfc.section.4.4.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.
       </p>
       <p id="rfc.section.4.4.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource
@@ -1726 +1723 @@
       <p id="rfc.section.4.4.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
       </p>
-      <p id="rfc.section.4.4.4.p.2">This status code is only appropriate when the response status code would have been 200 (OK) otherwise. When the status code
-         before transformation would have been different, the 214 Transformation Applied warn-code (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate.
+      <p id="rfc.section.4.4.4.p.2">This status code is only appropriate when the response status code would have been <a href="#status.200" class="smpl">200 (OK)</a> otherwise. When the status code before transformation would have been different, the 214 Transformation Applied warn-code
+         (<a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) is appropriate.
       </p>
       <p id="rfc.section.4.4.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 203 responses.
@@ -2356 +2353 @@
          identified by the effective request URI). The precise semantics of a representation are determined by the type of message
          (request or response), the request method, the response status code, and the representation metadata. For example, the above
-         semantic is true for the representation in any 200 (OK) response to GET and for the representation in any PUT request. A 200
-         response to PUT, in contrast, contains either a representation that describes the successful action or a representation of
-         the target resource, with the latter indicated by a Content-Location header field with the same value as the effective request
-         URI. Likewise, response messages with an error status code usually contain a representation that describes the error and what
-         next steps are suggested for resolving it.
+         semantic is true for the representation in any <a href="#status.200" class="smpl">200 (OK)</a> response to GET and for the representation in any PUT request. A 200 response to PUT, in contrast, contains either a representation
+         that describes the successful action or a representation of the target resource, with the latter indicated by a Content-Location
+         header field with the same value as the effective request URI. Likewise, response messages with an error status code usually
+         contain a representation that describes the error and what next steps are suggested for resolving it.
       </p>
       <p id="rfc.section.7.p.3">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
@@ -2972 +2968 @@
       </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 201 (Created) responses, the Location is the URI of the new resource which was created by the request. For 3xx 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 3xx 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,
@@ -2990 +2985 @@
       </div>
       <p id="rfc.section.9.13.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears
-         in a 201 Created response, where the Location header field specifies the URI for the entire created resource.
+         in a <a href="#status.201" class="smpl">201
+            (Created)</a> response, where the Location header field specifies the URI for the entire created resource.
       </p>
       <div class="note" id="rfc.section.9.13.p.9"> 
@@ -3948 +3944 @@
       <p id="rfc.section.C.p.4">This document takes over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.2</a>)
       </p>
-      <p id="rfc.section.C.p.5">Broadened the definition of 203 (Non-Authoritative Information) 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 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" title="Redirection 3xx">Section&nbsp;4.5</a>)
@@ -3956 +3952 @@
          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>)
       </p>
-      <p id="rfc.section.C.p.8">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource
-         needs to be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient
-         was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;4.5.5</a>)
-      </p>
-      <p id="rfc.section.C.p.9">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;4.6.15</a>)
+      <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
+         the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient was expected to repeat
+         this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;4.5.5</a>)
+      </p>
+      <p id="rfc.section.C.p.9">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;4.6.15</a>)
       </p>
       <p id="rfc.section.C.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)

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

@@ -665 +665 @@
 </t>
 <t>
-   The action performed by the POST method might not result in a
-   resource that can be identified by a URI. In this case, either 200
-   (OK) or 204 (No Content) is the appropriate response status code,
-   depending on whether or not the response includes a representation that
-   describes the result.
+   The action performed by the POST method might not result in a resource that
+   can be identified by a URI. In this case, either <x:ref>200 (OK)</x:ref> or
+   <x:ref>204 (No Content)</x:ref> is the appropriate response status
+   code, depending on whether or not the response includes a representation
+   that describes the result.
 </t>
 <t>
    If a resource has been created on the origin server, the response
-   &SHOULD; be 201 (Created) and contain a representation which describes the
-   status of the request and refers to the new resource, and a Location
-   header field (see <xref target="header.location"/>).
+   &SHOULD; be <x:ref>201 (Created)</x:ref> and contain a representation which
+   describes the status of the request and refers to the new resource, and a
+   Location header field (see <xref target="header.location"/>).
 </t>
 <t>
@@ -700 +700 @@
    representation would suggest that a subsequent GET on that same target
    resource will result in an equivalent representation being returned in
-   a 200 (OK) response.  However, there is no guarantee that such a state
-   change will be observable, since the target resource might be acted
-   upon by other user agents in parallel, or might be subject to dynamic
+   a <x:ref>200 (OK)</x:ref> response.  However, there is no guarantee that
+   such a state change will be observable, since the target resource might be
+   acted upon by other user agents in parallel, or might be subject to dynamic
    processing by the origin server, before any subsequent GET is received.
    A successful response only implies that the user agent's intent was
@@ -710 +710 @@
    If the target resource does not have a current representation and
    the PUT successfully creates one, then the origin server &MUST; inform
-   the user agent by sending a 201 (Created) response.  If the target
-   resource does have a current representation and that representation is
+   the user agent by sending a <x:ref>201 (Created)</x:ref> response.  If the
+   target resource does have a current representation and that representation is
    successfully modified in accordance with the state of the enclosed
-   representation, then either a 200 (OK) or 204 (No Content) response
-   &SHOULD; be sent to indicate successful completion of the request.
+   representation, then either a <x:ref>200 (OK)</x:ref> or <x:ref>204 (No Content)</x:ref>
+   response &SHOULD; be sent to indicate successful completion of the request.
 </t>
 <t>
@@ -828 +828 @@
 </t>
 <t>
-   A successful response &SHOULD; be 200 (OK) if the response includes an
-   representation describing the status, 202 (Accepted) if the action has not
-   yet been enacted, or 204 (No Content) if the action has been enacted
-   but the response does not include a representation.
+   A successful response &SHOULD; be <x:ref>200 (OK)</x:ref> if the response
+   includes an representation describing the status, <x:ref>202 (Accepted)</x:ref>
+   if the action has not yet been enacted, or <x:ref>204 (No Content)</x:ref> if
+   the action has been enacted but the response does not include a representation.
 </t>
 <t>
@@ -855 +855 @@
    The TRACE method requests a remote, application-layer loop-back
    of the request message. The final recipient of the request
-   &SHOULD; reflect the message received back to the client as the
-   message body of a 200 (OK) response. The final recipient is either the
+   &SHOULD; reflect the message received back to the client as the message body
+   of a <x:ref>200 (OK)</x:ref> response. The final recipient is either the
    origin server or the first proxy to receive a Max-Forwards
    value of zero (0) in the request (see <xref target="header.max-forwards"/>).
@@ -1349 +1349 @@
   <iref primary="true" item="200 OK (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="200 OK" x:for-anchor=""/>
+  <x:anchor-alias value="200 (OK)"/>
 <t>
    The request has succeeded. The payload returned with the response
@@ -1377 +1378 @@
   <iref primary="true" item="201 Created (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="201 Created" x:for-anchor=""/>
+  <x:anchor-alias value="201 (Created)"/>
 <t>
    The request has been fulfilled and has resulted in one or more new resources
@@ -1391 +1393 @@
    The origin server &MUST; create the resource(s) before returning the 201 status
    code. If the action cannot be carried out immediately, the server &SHOULD;
-   respond with 202 (Accepted) response instead.
+   respond with <x:ref>202 (Accepted)</x:ref> response instead.
 </t>
 <t>
@@ -1404 +1406 @@
   <iref primary="true" item="202 Accepted (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="202 Accepted" x:for-anchor=""/>
+  <x:anchor-alias value="202 (Accepted)"/>
 <t>
    The request has been accepted for processing, but the processing has
@@ -1426 +1429 @@
   <iref primary="true" item="203 Non-Authoritative Information (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="203 Non-Authoritative Information" x:for-anchor=""/>
+  <x:anchor-alias value="203 (Non-Authoritative Information)"/>
 <t>
    The representation in the response has been transformed or otherwise
@@ -1434 +1438 @@
 <t>
    This status code is only appropriate when the response status code would
-   have been 200 (OK) otherwise. When the status code before transformation
-   would have been different, the 214 Transformation Applied warn-code
-   (&header-warning;) is appropriate.
+   have been <x:ref>200 (OK)</x:ref> otherwise. When the status code before
+   transformation would have been different, the 214 Transformation Applied
+   warn-code (&header-warning;) is appropriate.
 </t>
 <t>
@@ -1447 +1451 @@
   <iref primary="true" item="204 No Content (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="204 No Content" x:for-anchor=""/>
+  <x:anchor-alias value="204 (No Content)"/>
 <t>
    The 204 (No Content) status code indicates that the server has
@@ -1717 +1722 @@
   <iref primary="true" item="305 Use Proxy (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="305 Use Proxy" x:for-anchor=""/>
+  <x:anchor-alias value="305 (Use Proxy)"/>
 <t>
    The 305 status code was defined in a previous version of this specification
@@ -2623 +2629 @@
    by the effective request URI).  The precise semantics of a representation
    are determined by the type of message (request or response), the request
-   method, the response status code, and the representation metadata.
-   For example, the above semantic is true for the representation in any
-   200 (OK) response to GET and for the representation in any PUT request.
+   method, the response status code, and the representation metadata. For
+   example, the above semantic is true for the representation in any
+   <x:ref>200 (OK)</x:ref> response to GET and for the representation in any PUT request.
    A 200 response to PUT, in contrast, contains either a representation
    that describes the successful action or a representation of the target
@@ -3688 +3694 @@
 </artwork></figure>
 <t>
-   For 201 (Created) responses, the Location is the URI of the new resource
-   which was created by the request. For 3xx responses, the location &SHOULD;
-   indicate the server's preferred URI for automatic redirection to the
-   resource.
+   For <x:ref>201 (Created)</x:ref> responses, the Location is the URI of the
+   new resource which was created by the request. For 3xx responses, the
+   location &SHOULD; indicate the server's preferred URI for automatic
+   redirection to the resource.
 </t>
 <t>
@@ -3725 +3731 @@
 <t>
    There are circumstances in which a fragment identifier in a Location URI
-   would not be appropriate. For instance, when it appears in a 201 Created
-   response, where the Location header field specifies the URI for the entire
-   created resource.
+   would not be appropriate. For instance, when it appears in a <x:ref>201
+   (Created)</x:ref> response, where the Location header field specifies the
+   URI for the entire created resource.
 </t>
 <x:note>
@@ -5410 +5416 @@
 </t>
 <t>
-  Broadened the definition of 203 (Non-Authoritative Information) to include
-  cases of payload transformations as well.
+  Broadened the definition of <x:ref>203 (Non-Authoritative Information)</x:ref>
+  to include cases of payload transformations as well.
   (<xref target="status.203"/>)
 </t>
@@ -5430 +5436 @@
 </t>
 <t>
-  Deprecate 305 Use Proxy status code, because user agents did not implement it.
-  It used to indicate that the target resource needs to be accessed through the
-  proxy given by the Location field. The Location field gave the URI of the
-  proxy. The recipient was expected to repeat this single request via the proxy.
+  Deprecate <x:ref>305 (Use Proxy)</x:ref> status code, because user agents did
+  not implement it. It used to indicate that the target resource needs to be
+  accessed through the proxy given by the Location field. The Location field
+  gave the URI of the proxy. The recipient was expected to repeat this single
+  request via the proxy.
   (<xref target="status.305"/>)
 </t>
 <t>
-  Define status 426 (Upgrade Required) (this was incorporated from
-  <xref target="RFC2817"/>).
+  Define status <x:ref>426 (Upgrade Required)</x:ref> (this was incorporated
+  from <xref target="RFC2817"/>).
   (<xref target="status.426"/>)
 </t>

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 4, 2013"; 
+       content: "Expires January 5, 2013"; 
   } 
   @bottom-right {
@@ -490 +490 @@
       <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-07-03">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-04">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
@@ -516 +516 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 4, 2013</td>
+               <td class="left">Expires: January 5, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -525 +525 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 3, 2012</td>
+               <td class="right">July 4, 2012</td>
             </tr>
          </tbody>
@@ -555 +555 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 4, 2013.</p>
+      <p>This Internet-Draft will expire on January 5, 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>
@@ -692 +692 @@
       </p>
       <p id="rfc.section.2.1.p.2">A "strong validator" is a representation metadata value that <em class="bcp14">MUST</em> be changed to a new, previously unused or guaranteed unique, value whenever a change occurs to the representation data such
-         that a change would be observable in the payload body of a 200 response to GET. A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g.,
+         that a change would be observable in the payload body of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to GET. A strong validator <em class="bcp14">MAY</em> be changed for other reasons, such as when a semantically significant part of the representation metadata is changed (e.g.,
          Content-Type), but it is in the best interests of the origin server to only change the value when it is necessary to invalidate
          the stored responses held by remote caches and authoring tools. A strong validator <em class="bcp14">MUST</em> be unique across all representations of a given resource, such that no two representations of that resource share the same
@@ -1050 +1050 @@
       </p>
       <ol>
-         <li>If the request would normally result in anything other than a 200 (OK) status code, or if the passed If-Modified-Since date
-            is invalid, the response is exactly the same as for a normal GET. A date which is later than the server's current time is
-            invalid.
+         <li>If the request would normally result in anything other than a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> status code, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date
+            which is later than the server's current time is invalid.
          </li>
          <li>If the selected representation has been modified since the If-Modified-Since date, the response is exactly the same as for
@@ -1107 +1106 @@
       <div id="rfc.iref.s.2"></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 200 (OK) 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 client's request indicates that it already has a valid representation,
+      <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
+         to transfer a representation of the target resource because the client's request indicates that it already has a valid representation,
          as indicated by the 304 response header fields, and is therefore redirecting the client to make use of that stored representation
          as if it were the payload of a 200 response. 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.

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

@@ -271 +271 @@
    changed to a new, previously unused or guaranteed unique, value whenever
    a change occurs to the representation data such that a change would be
-   observable in the payload body of a 200 response to GET.  A strong
-   validator &MAY; be changed for other reasons, such as when a semantically
+   observable in the payload body of a <x:ref>200 (OK)</x:ref> response to GET.
+   A strong validator &MAY; be changed for other reasons, such as when a semantically
    significant part of the representation metadata is changed (e.g.,
    Content-Type), but it is in the best interests of the origin server to only
@@ -883 +883 @@
   <list style="numbers">
       <t>If the request would normally result in anything other than a
-         200 (OK) status code, or if the passed If-Modified-Since date is
+         <x:ref>200 (OK)</x:ref> status code, or if the passed If-Modified-Since date is
          invalid, the response is exactly the same as for a normal GET.
          A date which is later than the server's current time is
@@ -994 +994 @@
 <t>
    The 304 status code indicates that a conditional GET request has been
-   received and would have resulted in a 200 (OK) response if it were not
+   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.  In other words,
    there is no need for the server to transfer a representation of the
@@ -1193 +1193 @@
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
-  <x:source href="p2-semantics.xml" basename="p2-semantics"/>
+  <x:source href="p2-semantics.xml" basename="p2-semantics">
+    <x:defines>200 (OK)</x:defines>
+  </x:source>
 </reference>
 

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 4, 2013"; 
+       content: "Expires January 5, 2013"; 
   } 
   @bottom-right {
@@ -492 +492 @@
       <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-07-03">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-04">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests.">
@@ -518 +518 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 4, 2013</td>
+               <td class="left">Expires: January 5, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -527 +527 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 3, 2012</td>
+               <td class="right">July 4, 2012</td>
             </tr>
          </tbody>
@@ -555 +555 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 4, 2013.</p>
+      <p>This Internet-Draft will expire on January 5, 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>
@@ -742 +742 @@
          </li>
          <li>Date</li>
-         <li>Cache-Control, ETag, Expires, Content-Location and/or Vary, if the header field would have been sent in a 200 response to
-            the same request
-         </li>
-      </ul>
-      <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an If-Range 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 returned with a 200 (OK) response to the same request.
+         <li>Cache-Control, ETag, Expires, Content-Location and/or Vary, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request
+         </li>
+      </ul>
+      <p id="rfc.section.3.1.p.3">If a 206 is sent in response to a request with an If-Range 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 returned with 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 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 206 responses.
@@ -765 +764 @@
 </pre><div class="note" id="rfc.section.3.2.p.4"> 
          <p> <b>Note:</b> Clients cannot depend on servers to send a <a href="#status.416" class="smpl">416 (Requested
-               Range Not Satisfiable)</a> response instead of a 200 (OK) response for an unsatisfiable Range header field, since not all servers implement this header
-            field.
+               Range Not Satisfiable)</a> response instead of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response for an unsatisfiable Range header field, since not all servers implement this header field.
          </p> 
       </div>
@@ -799 +797 @@
          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.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified 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.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
       </p>
-      <p id="rfc.section.4.2.p.2">When a client receives an incomplete 200 (OK) 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
+      <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>
-      <p id="rfc.section.4.2.p.3">If the new response is an incomplete 200 (OK) response, then the header fields of that new response are used for any combined
-         response and replace those of the matching stored responses.
-      </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 200 (OK), 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 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
+      <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
+         stored responses.
+      </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 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>
       <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 200 (OK) response with a Content-Length header field that reflects the complete length. Otherwise,
-         the combined response(s) <em class="bcp14">MUST</em> include a Content-Range header field describing the included range(s) and be recorded as incomplete. If the union consists
+         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 Content-Length header field that reflects the complete length. Otherwise, the combined response(s) <em class="bcp14">MUST</em> include a Content-Range 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 206 responses with one continuous range each.
       </p>
@@ -887 +884 @@
       </ul>
       <p id="rfc.section.5.2.p.10">If the server ignores a byte-range-spec (for example if it is syntactically invalid, or if it might be seen as a denial-of-service
-         attack), the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing
-         the full representation).
+         attack), the server <em class="bcp14">SHOULD</em> treat the request as if the invalid Range header field did not exist. (Normally, this means return a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response containing the full representation).
       </p>
       <div id="rfc.iref.i.1"></div>
@@ -911 +907 @@
       </p>
       <p id="rfc.section.5.3.p.7">If the validator given in the If-Range header field matches the current validator for the selected representation of the target
-         resource, then the server <em class="bcp14">SHOULD</em> send the specified sub-range of the representation using a <a href="#status.206" class="smpl">206 (Partial Content)</a> response. If the validator does not match, then the server <em class="bcp14">SHOULD</em> send the entire representation using a 200 (OK) response.
+         resource, then the server <em class="bcp14">SHOULD</em> send the specified sub-range of the representation using a <a href="#status.206" class="smpl">206 (Partial Content)</a> response. If the validator does not match, then the server <em class="bcp14">SHOULD</em> send the entire representation using a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
       </p>
       <div id="rfc.iref.r.1"></div>
@@ -987 +983 @@
       <ul>
          <li>The presence of a Range header field in an unconditional GET modifies what is returned if the GET is otherwise successful.
-            In other words, the response carries a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> instead of 200 (OK).
+            In other words, the response carries a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> instead of <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>.
          </li>
          <li>The presence of a Range header field in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match,

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

@@ -335 +335 @@
     <t>
         Cache-Control, ETag, Expires, Content-Location and/or Vary, if
-        the header field would have been sent in a 200 response to the
+        the header field would have been sent in a <x:ref>200 (OK)</x:ref> response to the
         same request
     </t>
@@ -344 +344 @@
    &SHOULD-NOT; include other representation header fields. Otherwise, the response
    &MUST; include all of the representation header fields that would have been returned
-   with a 200 (OK) response to the same request.
+   with a <x:ref>200 (OK)</x:ref> response to the same request.
 </t>
 <t>
@@ -380 +380 @@
   <t>
     &Note; Clients cannot depend on servers to send a <x:ref>416 (Requested
-    Range Not Satisfiable)</x:ref> response instead of a 200 (OK) response for
-    an unsatisfiable Range header field, since not all servers
+    Range Not Satisfiable)</x:ref> response instead of a <x:ref>200 (OK)</x:ref>
+    response for an unsatisfiable Range header field, since not all servers
     implement this header field.
   </t>
@@ -444 +444 @@
 </t>
 <t>
-   When a client receives an incomplete 200 (OK) or <x:ref>206 (Partial Content)</x:ref>
+   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
@@ -453 +453 @@
 </t>
 <t>
-   If the new response is an incomplete 200 (OK) response, then the header
+   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.
@@ -459 +459 @@
 <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 200 (OK), then the combined response
+   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
@@ -472 +472 @@
    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 200 (OK) response
+   combined response &MUST; be recorded as a complete <x:ref>200 (OK)</x:ref> response
    with a Content-Length header field that reflects the complete length.
    Otherwise, the combined response(s) &MUST; include a Content-Range
@@ -626 +626 @@
    syntactically invalid, or if it might be seen as a denial-of-service
    attack), the server &SHOULD; treat the request as if the invalid Range
-   header field did not exist. (Normally, this means return a 200
+   header field did not exist. (Normally, this means return a <x:ref>200 (OK)</x:ref>
    response containing the full representation).
 </t>
@@ -681 +681 @@
    the server &SHOULD; send the specified sub-range of the representation
    using a <x:ref>206 (Partial Content)</x:ref> response. If the validator does not match,
-   then the server &SHOULD; send the entire representation using a 200 (OK)
+   then the server &SHOULD; send the entire representation using a <x:ref>200 (OK)</x:ref>
    response.
 </t>
@@ -833 +833 @@
         what is returned if the GET is otherwise successful. In other
         words, the response carries a status code of <x:ref>206 (Partial Content)</x:ref>
-        instead of 200 (OK).</t>
+        instead of <x:ref>200 (OK)</x:ref>.</t>
 
      <t>The presence of a Range header field in a conditional GET (a request
@@ -1020 +1020 @@
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;"/>
-  <x:source href="p2-semantics.xml" basename="p2-semantics"/>
+  <x:source href="p2-semantics.xml" basename="p2-semantics">
+    <x:defines>200 (OK)</x:defines>
+  </x:source>
 </reference>
 

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

@@ -832 +832 @@
       </p>
       <p id="rfc.section.2.p.2">Each <dfn>cache entry</dfn> consists of a cache key and one or more HTTP responses corresponding to prior requests that used the same key. The most common
-         form of cache entry is a successful result of a retrieval request: i.e., a 200 (OK) response containing a representation of
-         the resource identified by the request target. However, it is also possible to cache negative results (e.g., <a href="p2-semantics.html#status.404" class="smpl">404 (Not Found)</a>, incomplete results (e.g., <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>), and responses to safe methods other than GET if the method's definition allows such caching and defines something suitable
+         form of cache entry is a successful result of a retrieval request: i.e., a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response containing a representation of the resource identified by the request target. However, it is also possible to cache
+         negative results (e.g., <a href="p2-semantics.html#status.404" class="smpl">404 (Not Found)</a>, incomplete results (e.g., <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>), and responses to safe methods other than GET if the method's definition allows such caching and defines something suitable
          for use as a cache key.
       </p>
@@ -876 +876 @@
          time, as such responses are not usually useful to store. However, caches are not prohibited from storing such responses.
       </p>
-      <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is 200 (OK), and the entire
-         response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete 200 (OK) cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does
+      <p id="rfc.section.2.1.p.5">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) are received prior to the connection being closed. If the request is GET, the response status is <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the Range and Content-Range header fields or if it does
          not understand the range units used in those fields.
       </p>
@@ -1095 +1094 @@
       </ul>
       <h3 id="rfc.section.2.4.1"><a href="#rfc.section.2.4.1">2.4.1</a>&nbsp;<a id="freshening.responses" href="#freshening.responses">Freshening Responses with 304 Not Modified</a></h3>
-      <p id="rfc.section.2.4.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored 200 (OK) responses for the same cache key, the cache needs to identify which of
-         the stored responses are updated by this new response and then update the stored response(s) with the new information provided
-         in the 304 response. 
+      <p id="rfc.section.2.4.1.p.1">When a cache receives a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response and already has one or more stored <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses for the same cache key, the cache needs to identify which of the stored responses are updated by this new response
+         and then update the stored response(s) with the new information provided in the 304 response. 
       </p>
       <ul>

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

@@ -432 +432 @@
    HTTP responses corresponding to prior requests that used the same key.
    The most common form of cache entry is a successful result of a retrieval
-   request: i.e., a 200 (OK) response containing a representation of the
-   resource identified by the request target.  However, it is also possible
+   request: i.e., a <x:ref>200 (OK)</x:ref> response containing a representation
+   of the resource identified by the request target.  However, it is also possible
    to cache negative results (e.g., <x:ref>404 (Not Found)</x:ref>, incomplete results
    (e.g., <x:ref>206 (Partial Content)</x:ref>), and responses to safe methods other than
@@ -504 +504 @@
    A response message is considered complete when all of the octets
    indicated by the message framing (&messaging;) are received
-   prior to the connection being closed.
-   If the request is GET, the response status is 200 (OK), and the entire
+   prior to the connection being closed. If the request is GET, the response
+   status is <x:ref>200 (OK)</x:ref>, and the entire
    response header block has been received, a cache &MAY; store an incomplete
    response message body if the cache entry is recorded as incomplete.
    Likewise, a <x:ref>206 (Partial Content)</x:ref> response &MAY; be stored as if it were
-   an incomplete 200 (OK) cache entry.  However, a cache &MUST-NOT; store
+   an incomplete <x:ref>200 (OK)</x:ref> cache entry.  However, a cache &MUST-NOT; store
    incomplete or partial content responses if it does not support the Range
    and Content-Range header fields or if it does not understand the
@@ -929 +929 @@
 <t>
    When a cache receives a <x:ref>304 (Not Modified)</x:ref> response and already has one
-   or more stored 200 (OK) responses for the same cache key, the cache needs
+   or more stored <x:ref>200 (OK)</x:ref> responses for the same cache key, the cache needs
    to identify which of the stored responses are updated by this new response
    and then update the stored response(s) with the new information provided in
@@ -2288 +2288 @@
     <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p2-semantics-&ID-VERSION;" />
     <x:source basename="p2-semantics" href="p2-semantics.xml">
+      <x:defines>200 (OK)</x:defines>
       <x:defines>404 (Not Found)</x:defines>
       <x:defines>504 (Gateway Timeout)</x:defines>