Changeset 1708

Timestamp:

Jul 3, 2012, 11:26:11 AM (7 years ago)

Author:

julian.reschke@…

Message:

Work-in-progress: hyperlink status codes definitions (for those defined in parts 4, 5, and 7)

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (19 diffs)
• p1-messaging.xml (modified) (5 diffs)
• p2-semantics.html (modified) (1 diff)
• p2-semantics.xml (modified) (2 diffs)
• p4-conditional.html (modified) (6 diffs)
• p4-conditional.xml (modified) (9 diffs)
• p5-range.html (modified) (13 diffs)
• p5-range.xml (modified) (10 diffs)
• p6-cache.html (modified) (4 diffs)
• p6-cache.xml (modified) (7 diffs)
• p7-auth.html (modified) (11 diffs)
• p7-auth.xml (modified) (11 diffs)

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

@@ -1380 +1380 @@
          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 304 (Not Modified) 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.
+         (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>.)
       </p>
       <div id="rfc.iref.t.4"></div>
@@ -1406 +1406 @@
       <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>, before determining the message body length.
       </p>
-      <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
-      </p>
-      <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a 304 response to a GET request, neither of which includes a message body, to
-         indicate that the origin server would have applied a transfer coding to the message body if the request had been an unconditional
-         GET. This indication is not required, however, because any recipient on the response chain (including the origin server) can
-         remove transfer codings when they are not needed.
+      <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
+      </p>
+      <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in 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.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) to a GET request, neither of which includes a message body, to indicate that the origin server would have applied a transfer
+         coding to the message body if the request had been an unconditional GET. This indication is not required, however, because
+         any recipient on the response chain (including the origin server) can remove transfer codings when they are not needed.
       </p>
       <p id="rfc.section.3.3.1.p.9">Transfer-Encoding was added in HTTP/1.1. It is generally assumed that implementations advertising only HTTP/1.0 support will
@@ -1431 +1430 @@
       <div id="rfc.figure.u.36"></div><pre class="text">  Content-Length: 3495
 </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 304 (Not Modified) response 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.
+         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.
       </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
@@ -1713 +1711 @@
       </p>
       <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h3>
-      <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
+      <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
          is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
          a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
@@ -1755 +1753 @@
       </p>
       <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which
-         are defined in <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order
+         are defined in <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order
          to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment
          identifiers are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>).
@@ -1814 +1812 @@
       </p>
       <div id="authority-form">
-         <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
+         <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,
          </p>
       </div>
       <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1
 </pre><div id="asterisk-form">
-         <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
+         <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,
             the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example,
          </p>
@@ -1974 +1972 @@
          </p> 
       </div>
-      <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
+      <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
       </p>
       <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
@@ -1980 +1978 @@
          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.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.
+         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">[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-1xx) response.
@@ -2128 +2126 @@
       <p id="rfc.section.6.3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
       </p>
-      <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
+      <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
          send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
       </p>
@@ -2158 +2156 @@
       <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3>
       <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
-         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
+         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
          of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
       </p>
@@ -2171 +2169 @@
       </p>
       <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
-      <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
+      <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
          to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
          either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
@@ -2178 +2176 @@
       <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p>
       <ul>
-         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
-         </li>
-         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
+         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
+         </li>
+         <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.11</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
          </li>
       </ul>
@@ -2224 +2222 @@
          <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include
             an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of
-            1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+            1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
          </li>
       </ul>
@@ -2261 +2259 @@
       </p>
       <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it
-         is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+         is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
       <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched
@@ -2525 +2523 @@
          <li>Pointer to specification text</li>
       </ul>
-      <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
+      <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 5.4</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
       </p>
       <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
@@ -2685 +2683 @@
          that most implementations will choose substantially higher limits.
       </p>
-      <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+      <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.26"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
       <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability.
@@ -2730 +2728 @@
       <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
       </h2>
-      <table>                    
+      <table>                      
          <tr>
             <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td>
@@ -2738 +2736 @@
             <td class="reference"><b id="Part2">[Part2]</b></td>
             <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">HTTP/1.1, part 2: Message Semantics</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p2-semantics-latest (work in progress), July&nbsp;2012.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="Part4">[Part4]</b></td>
+            <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), July&nbsp;2012.
             </td>
          </tr>
@@ -3742 +3745 @@
             <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
                   <li><em>Pad1995</em>&nbsp;&nbsp;<a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li>
-                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.10">4.3.1</a>, <a href="#rfc.xref.Part2.11">5.1</a>, <a href="#rfc.xref.Part2.12">5.3</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.6.2</a>, <a href="#rfc.xref.Part2.15">5.7</a>, <a href="#rfc.xref.Part2.16">6.3.2.2</a>, <a href="#rfc.xref.Part2.17">6.3.4</a>, <a href="#rfc.xref.Part2.18">6.4.3</a>, <a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.5</a>, <a href="#rfc.xref.Part2.23">7.4</a>, <a href="#rfc.xref.Part2.24">8.6</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
+                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3</a>, <a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.11">4.3.1</a>, <a href="#rfc.xref.Part2.12">5.1</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.3</a>, <a href="#rfc.xref.Part2.15">5.6.2</a>, <a href="#rfc.xref.Part2.16">5.7</a>, <a href="#rfc.xref.Part2.17">6.3.2.2</a>, <a href="#rfc.xref.Part2.18">6.3.4</a>, <a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.4.3</a>, <a href="#rfc.xref.Part2.23">6.5</a>, <a href="#rfc.xref.Part2.24">7.4</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#rfc.xref.Part2.26">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">3.1.1</a></li>
-                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">6.3.2.2</a>, <a href="#rfc.xref.Part2.17">6.3.4</a></li>
-                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
-                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.12">5.3</a></li>
+                        <li><em>Section 2.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.17">6.3.2.2</a>, <a href="#rfc.xref.Part2.18">6.3.4</a></li>
+                        <li><em>Section 2.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.14">5.3</a></li>
+                        <li><em>Section 2.3.8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.13">5.3</a></li>
                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">3.2</a></li>
-                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a></li>
-                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.15">5.7</a>, <a href="#rfc.xref.Part2.21">6.4.3</a></li>
-                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.18">6.4.3</a></li>
+                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.3</a></li>
+                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.16">5.7</a>, <a href="#rfc.xref.Part2.22">6.4.3</a></li>
+                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">6.4.3</a></li>
                         <li><em>Section 4.4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2.3</a></li>
-                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">6.5</a></li>
-                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">8.6</a></li>
-                        <li><em>Section 4.6.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.24">8.6</a></li>
-                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.23">7.4</a></li>
-                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">4.3.1</a></li>
+                        <li><em>Section 4.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.23">6.5</a></li>
+                        <li><em>Section 4.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.26">8.6</a></li>
+                        <li><em>Section 4.6.12</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.25">8.6</a></li>
+                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.10">3.3.1</a>, <a href="#rfc.xref.Part2.24">7.4</a></li>
+                        <li><em>Section 8</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.11">4.3.1</a></li>
                         <li><em>Section 9.10</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">3.2</a></li>
-                        <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a></li>
+                        <li><em>Section 9.11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a></li>
                         <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a></li>
+                     </ul>
+                  </li>
+                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a>, <a href="#Part4"><b>10.1</b></a><ul>
+                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.2">3.3.1</a>, <a href="#rfc.xref.Part4.3">3.3.2</a></li>
                      </ul>
                   </li>

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

@@ -40 +40 @@
   <!ENTITY status-203             "<xref target='Part2' x:rel='#status.203' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY status-3xx             "<xref target='Part2' x:rel='#status.3xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY status-304             "<xref target='Part4' x:rel='#status.304' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY status-4xx             "<xref target='Part2' x:rel='#status.4xx' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY status-414             "<xref target='Part2' x:rel='#status.414' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -1483 +1484 @@
    Successful (2xx) responses to CONNECT switch to tunnel mode instead of
    having a message body.
-   All 1xx (Informational), 204 (No Content), and 304 (Not Modified)
+   All 1xx (Informational), 204 (No Content), 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.
+   &MAY; be of zero length. (See &status-codes; and &status-304;.)
 </t>
 
@@ -1551 +1552 @@
 <t>
    Transfer-Encoding &MAY; be sent in a response to a HEAD request or in a
-   304 response to a GET request, neither of which includes a message body,
+   <x:ref>304 (Not Modified)</x:ref> response (&status-304;) to a GET request,
+   neither of which includes a message body,
    to indicate that the origin server would have applied a transfer coding
    to the message body if the request had been an unconditional GET.
@@ -1602 +1604 @@
    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 304 (Not Modified) response to a GET request,
-   Content-Length indicates the size of the payload body (without
+   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)
    response.
@@ -4109 +4111 @@
 </reference>
 
+<reference anchor="Part4">
+  <front>
+    <title abbrev="HTTP/1.1">HTTP/1.1, part 4: Conditional Requests</title>
+    <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
+      <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
+      <address><email>fielding@gbiv.com</email></address>
+    </author>
+    <author fullname="Yves Lafon" initials="Y." role="editor" surname="Lafon">
+      <organization abbrev="W3C">World Wide Web Consortium</organization>
+      <address><email>ylafon@w3.org</email></address>
+    </author>
+    <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
+      <organization abbrev="greenbytes">greenbytes GmbH</organization>
+      <address><email>julian.reschke@greenbytes.de</email></address>
+    </author>
+    <date month="&ID-MONTH;" year="&ID-YEAR;" />
+  </front>
+  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;" />
+  <x:source basename="p4-conditional" href="p4-conditional.xml">
+    <x:defines>304 (Not Modified)</x:defines>
+  </x:source>
+</reference>
+
 <reference anchor="Part6">
   <front>

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

@@ -1788 +1788 @@
          </li>
          <li>
-            <p>Other kinds of redirection, such as to a cached result (status code 304 (Not Modified), see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
+            <p>Other kinds of redirection, such as to a cached result (status code <a href="p4-conditional.html#status.304" class="smpl">304
+                  (Not Modified)</a>, see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
             </p>
          </li>

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

@@ -1535 +1535 @@
       <x:lt>
         <t>
-          Other kinds of redirection, such as to a cached result (status code 304
-          (Not Modified), see &status-304;). 
+          Other kinds of redirection, such as to a cached result (status code <x:ref>304
+          (Not Modified)</x:ref>, see &status-304;). 
         </t>
       </x:lt>
@@ -4565 +4565 @@
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;"/>
-  <x:source href="p4-conditional.xml" basename="p4-conditional"/>
+  <x:source basename="p4-conditional" href="p4-conditional.xml">
+    <x:defines>304 (Not Modified)</x:defines>
+  </x:source>
 </reference>
 

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

@@ -956 +956 @@
       <p id="rfc.section.2.4.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since
          or If-Unmodified-Since header field) and one or more entity-tags (e.g., in an If-Match, If-None-Match, or If-Range header
-         field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields
-         in the request.
+         field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of <a href="#status.304" class="smpl">304 (Not Modified)</a> unless doing so is consistent with all of the conditional header fields in the request.
       </p>
       <p id="rfc.section.2.4.p.6">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags
@@ -988 +987 @@
       </p>
       <p id="rfc.section.3.1.p.4">Origin servers <em class="bcp14">MUST NOT</em> perform the requested method if none of the entity-tags match, or if "*" is given and no current representation exists; instead
-         they <em class="bcp14">MUST</em> respond with the 412 (Precondition Failed) status code.
+         they <em class="bcp14">MUST</em> respond with the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code.
       </p>
       <p id="rfc.section.3.1.p.5">Proxy servers using a cached response as the selected representation <em class="bcp14">MUST NOT</em> perform the requested method if none of the entity-tags match, or if "*" is given and no current representation exists; instead,
@@ -1019 +1018 @@
       <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a>
 </pre><p id="rfc.section.3.2.p.4">If any of the entity-tags listed in the If-None-Match field-value match (as per <a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>) the entity-tag of the selected representation, or if "*" is given and any current representation exists for that resource,
-         then the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a 304 (Not Modified) status code, including the cache-related header fields (particularly ETag) of the selected
-         representation that has a matching entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a 412 (Precondition Failed) status code.
-      </p>
-      <p id="rfc.section.3.2.p.5">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a 304 (Not Modified) response.
+         then the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, including the cache-related header fields (particularly ETag) of the selected representation that has a matching
+         entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code.
+      </p>
+      <p id="rfc.section.3.2.p.5">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a <a href="#status.304" class="smpl">304 (Not Modified)</a> response.
       </p>
       <p id="rfc.section.3.2.p.6">If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status code, then
@@ -1058 +1057 @@
             a normal GET.
          </li>
-         <li>If the selected representation has not been modified since a valid If-Modified-Since date, the server <em class="bcp14">SHOULD</em> return a 304 (Not Modified) response.
+         <li>If the selected representation has not been modified since a valid If-Modified-Since date, the server <em class="bcp14">SHOULD</em> return a <a href="#status.304" class="smpl">304 (Not Modified)</a> response.
          </li>
       </ol>
@@ -1068 +1067 @@
          </li>
          <li> <b>Note:</b> When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than
-            function, for deciding whether to send a 304 (Not Modified) response. To get best results when sending an If-Modified-Since
-            header field for cache validation, clients are advised to use the exact date string received in a previous Last-Modified header
-            field whenever possible.
+            function, for deciding whether to send a <a href="#status.304" class="smpl">304 (Not Modified)</a> response. To get best results when sending an If-Modified-Since header field for cache validation, clients are advised to
+            use the exact date string received in a previous Last-Modified header field whenever possible.
          </li>
          <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header field instead of a date taken from the Last-Modified header
@@ -1088 +1086 @@
       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.if-unmodified-since" href="#header.if-unmodified-since">If-Unmodified-Since</a></h2>
       <p id="rfc.section.3.4.p.1">The "If-Unmodified-Since" header field can be used to make a request method conditional by modification date: if the selected
-         representation has been modified since the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the 412 (Precondition Failed) status code. If the selected representation has not been modified since
-         the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the request method as if the If-Unmodified-Since header field were not present.
+         representation has been modified since the time specified in this field, then the server <em class="bcp14">MUST NOT</em> perform the requested operation and <em class="bcp14">MUST</em> instead respond with the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code. If the selected representation has not been modified since the time specified in this field, the server <em class="bcp14">SHOULD</em> perform the request method as if the If-Unmodified-Since header field were not present.
       </p>
       <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> = <a href="#notation" class="smpl">HTTP-date</a>

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

@@ -696 +696 @@
    If-Unmodified-Since header field) and one or more entity-tags (e.g.,
    in an If-Match, If-None-Match, or If-Range header field) as cache
-   validators, &MUST-NOT; return a response status code of 304 (Not Modified)
+   validators, &MUST-NOT; return a response status code of <x:ref>304 (Not Modified)</x:ref>
    unless doing so is consistent with all of the conditional header
    fields in the request.
@@ -757 +757 @@
    Origin servers &MUST-NOT; perform the requested method if none of the
    entity-tags match, or if "*" is given and no current representation
-   exists; instead they &MUST; respond with the 412 (Precondition Failed)
+   exists; instead they &MUST; respond with the <x:ref>412 (Precondition Failed)</x:ref>
    status code.
 </t>
@@ -819 +819 @@
    server &MUST-NOT; perform the requested method.
    Instead, if the request method was GET or HEAD, the server &SHOULD;
-   respond with a 304 (Not Modified) status code, including the cache-related
+   respond with a <x:ref>304 (Not Modified)</x:ref> status code, including the cache-related
    header fields (particularly ETag) of the selected representation that has
    a matching entity-tag.  For all other request methods, the server &MUST;
-   respond with a 412 (Precondition Failed) status code.
+   respond with a <x:ref>412 (Precondition Failed)</x:ref> status code.
 </t>
 <t>
@@ -829 +829 @@
    but &MUST; also ignore any If-Modified-Since header field(s) in the
    request. That is, if no entity-tags match, then the server &MUST-NOT;
-   return a 304 (Not Modified) response.
+   return a <x:ref>304 (Not Modified)</x:ref> response.
 </t>
 <t>
@@ -894 +894 @@
       <t>If the selected representation has not been modified since a valid
          If-Modified-Since date, the server &SHOULD; return a
-         304 (Not Modified) response.</t>
+         <x:ref>304 (Not Modified)</x:ref> response.</t>
   </list>
 </t>
@@ -909 +909 @@
       &Note; When handling an If-Modified-Since header field, some
       servers will use an exact date comparison function, rather than a
-      less-than function, for deciding whether to send a 304 (Not
-      Modified) response. To get best results when sending an If-Modified-Since
+      less-than function, for deciding whether to send a <x:ref>304 (Not Modified)</x:ref>
+      response. To get best results when sending an If-Modified-Since
       header field for cache validation, clients are
       advised to use the exact date string received in a previous Last-Modified
@@ -948 +948 @@
    has been modified since the time specified in this field, then the
    server &MUST-NOT; perform the requested operation and &MUST; instead
-   respond with the 412 (Precondition Failed) status code.
+   respond with the <x:ref>412 (Precondition Failed)</x:ref> status code.
    If the selected representation has not been modified since the time
    specified in this field, the server &SHOULD; perform the request
@@ -991 +991 @@
   <iref primary="true" item="304 Not Modified (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="304 Not Modified" x:for-anchor=""/>
+  <x:anchor-alias value="304 (Not Modified)"/>
 <t>
    The 304 status code indicates that a conditional GET request has been
@@ -1038 +1039 @@
   <iref primary="true" item="412 Precondition Failed (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="412 Precondition Failed" x:for-anchor=""/>
+  <x:anchor-alias value="412 (Precondition Failed)"/>
 <t>
    The 412 status code indicates that one or more preconditions given in

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 2, 2013"; 
+       content: "Expires January 4, 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-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-03">
       <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 2, 2013</td>
+               <td class="left">Expires: January 4, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -527 +527 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 1, 2012</td>
+               <td class="right">July 3, 2012</td>
             </tr>
          </tbody>
@@ -555 +555 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 2, 2013.</p>
+      <p>This Internet-Draft will expire on January 4, 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>
@@ -764 +764 @@
 Content-Type: image/gif
 </pre><div class="note" id="rfc.section.3.2.p.4"> 
-         <p> <b>Note:</b> Clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for
-            an unsatisfiable Range header field, since not all servers implement this header field.
+         <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.
          </p> 
       </div>
@@ -798 +799 @@
          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 206 (Partial Content) 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,
+      <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
+         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>
@@ -805 +806 @@
          response and replace those of the matching stored responses.
       </p>
-      <p id="rfc.section.4.2.p.4">If the new response is a 206 (Partial Content) 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.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
          header fields in the stored response.
       </p>
@@ -864 +864 @@
          whose instance-length value is less than or equal to its last-byte-pos value, is invalid. The recipient of an invalid byte-content-range-spec <em class="bcp14">MUST</em> ignore it and any content transferred along with it.
       </p>
-      <p id="rfc.section.5.2.p.7">In the case of a byte range request: A server sending a response with status code 416 (Requested range not satisfiable) <em class="bcp14">SHOULD</em> include a Content-Range field with a byte-range-resp-spec of "*". The instance-length specifies the current length of the
-         selected resource. A response with status code 206 (Partial Content) <em class="bcp14">MUST NOT</em> include a Content-Range field with a byte-range-resp-spec of "*".
+      <p id="rfc.section.5.2.p.7">In the case of a byte range request: A server sending a response with status code <a href="#status.416" class="smpl">416 (Requested Range Not
+            Satisfiable)</a>  <em class="bcp14">SHOULD</em> include a Content-Range field with a byte-range-resp-spec of "*". The instance-length specifies the current length of the
+         selected resource. A response with status code <a href="#status.206" class="smpl">206 (Partial Content)</a>  <em class="bcp14">MUST NOT</em> include a Content-Range field with a byte-range-resp-spec of "*".
       </p>
       <p id="rfc.section.5.2.p.8">The "Content-Range" header field has no meaning for status codes that do not explicitly describe its semantic. Currently,
-         only status codes 206 (Partial Content) and 416 (Requested range not satisfiable) describe the meaning of this header field.
+         only status codes <a href="#status.206" class="smpl">206 (Partial Content)</a> and <a href="#status.416" class="smpl">416 (Requested Range Not Satisfiable)</a> describe the meaning of this header field.
       </p>
       <p id="rfc.section.5.2.p.9">Examples of byte-content-range-spec values, assuming that the representation contains a total of 1234 bytes: </p>
@@ -910 +911 @@
       </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 206 (Partial Content) 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 200 (OK) response.
       </p>
       <div id="rfc.iref.r.1"></div>
@@ -951 +951 @@
       <p id="rfc.section.5.4.1.p.11">If a syntactically valid byte-range-set includes at least one byte-range-spec whose first-byte-pos is less than the current
          length of the representation, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set
-         is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a 416 (Requested range not satisfiable) status code. Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a 206 (Partial Content) status code containing the satisfiable ranges of the representation.
+         is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server <em class="bcp14">SHOULD</em> return a response with a <a href="#status.416" class="smpl">416 (Requested Range Not Satisfiable)</a> status code. Otherwise, the server <em class="bcp14">SHOULD</em> return a response with a <a href="#status.206" class="smpl">206 (Partial Content)</a> status code containing the satisfiable ranges of the representation.
       </p>
       <p id="rfc.section.5.4.1.p.12">Examples of byte-ranges-specifier values (assuming a representation of length 10000): </p>
@@ -987 +987 @@
       <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 206 (Partial Content) 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 200 (OK).
          </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,
@@ -1193 +1193 @@
       <div id="rfc.iref.m.2"></div>
       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="internet.media.type.multipart.byteranges" href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></h1>
-      <p id="rfc.section.A.p.1">When an HTTP 206 (Partial Content) response message includes the content of multiple ranges (a response to a request for multiple
-         non-overlapping ranges), these are transmitted as a multipart message body (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>). The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.
+      <p id="rfc.section.A.p.1">When an HTTP <a href="#status.206" class="smpl">206 (Partial Content)</a> response message includes the content of multiple ranges (a response to a request for multiple non-overlapping ranges), these
+         are transmitted as a multipart message body (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>). The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.
       </p>
       <div class="note" id="rfc.section.A.p.2"> 

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

@@ -312 +312 @@
   <iref primary="true" item="206 Partial Content (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="206 Partial Content" x:for-anchor=""/>
+  <x:anchor-alias value="206 (Partial Content)"/>
 <t>
    The server has fulfilled the partial GET request for the resource.
@@ -354 +355 @@
   <iref primary="true" item="416 Requested Range Not Satisfiable (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="416 Requested Range Not Satisfiable" x:for-anchor=""/>
+  <x:anchor-alias value="416 (Requested Range Not Satisfiable)"/>
 <t>
    A server &SHOULD; return a response with this status code if a request
@@ -377 +379 @@
 <x:note>
   <t>
-    &Note; Clients cannot depend on servers to send a 416 (Requested
-    range not satisfiable) response instead of a 200 (OK) response for
+    &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
     implement this header field.
@@ -442 +444 @@
 </t>
 <t>
-   When a client receives an incomplete 200 (OK) or 206 (Partial Content)
+   When a client receives an incomplete 200 (OK) 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
@@ -456 +458 @@
 </t>
 <t>
-   If the new response is a 206 (Partial Content) response and at least one
+   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
    header fields consist of the most recent 200 response's header fields.
@@ -578 +580 @@
 <t>
    In the case of a byte range request:
-   A server sending a response with status code 416 (Requested range not
-   satisfiable) &SHOULD; include a Content-Range field with a byte-range-resp-spec
+   A server sending a response with status code <x:ref>416 (Requested Range Not
+   Satisfiable)</x:ref> &SHOULD; include a Content-Range field with a byte-range-resp-spec
    of "*". The instance-length specifies the current length of
-   the selected resource. A response with status code 206 (Partial
-   Content) &MUST-NOT; include a Content-Range field with a byte-range-resp-spec of "*".
+   the selected resource. A response with status code <x:ref>206 (Partial Content)</x:ref>
+   &MUST-NOT; include a Content-Range field with a byte-range-resp-spec of "*".
 </t>
 <t>
   The "Content-Range" header field has no meaning for status codes that do not 
   explicitly describe its semantic. Currently, only status codes
-  206 (Partial Content) and 416 (Requested range not satisfiable) describe
+  <x:ref>206 (Partial Content)</x:ref> and <x:ref>416 (Requested Range Not Satisfiable)</x:ref> describe
   the meaning of this header field.
 </t>
@@ -678 +680 @@
    validator for the selected representation of the target resource, then
    the server &SHOULD; send the specified sub-range of the representation
-   using a 206 (Partial Content) response. If the validator does not match,
+   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)
    response.
@@ -760 +762 @@
    Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
    is unsatisfiable, the server &SHOULD; return a response with a 
-   416 (Requested range not satisfiable) status code. Otherwise, the server
-   &SHOULD; return a response with a 206 (Partial Content) status code
+   <x:ref>416 (Requested Range Not Satisfiable)</x:ref> status code. Otherwise, the server
+   &SHOULD; return a response with a <x:ref>206 (Partial Content)</x:ref> status code
    containing the satisfiable ranges of the representation.
 </t>
@@ -830 +832 @@
      <t>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 206 (Partial
-        Content) instead of 200 (OK).</t>
+        words, the response carries a status code of <x:ref>206 (Partial Content)</x:ref>
+        instead of 200 (OK).</t>
 
      <t>The presence of a Range header field in a conditional GET (a request
@@ -1221 +1223 @@
 <iref item="multipart/byteranges Media Type" primary="true"/>
 <t>
-   When an HTTP 206 (Partial Content) response message includes the
+   When an HTTP <x:ref>206 (Partial Content)</x:ref> response message includes the
    content of multiple ranges (a response to a request for multiple
    non-overlapping ranges), these are transmitted as a multipart

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

@@ -878 +878 @@
       </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 206 (Partial Content)
-         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
+         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
          not understand the range units used in those fields.
       </p>
       <p id="rfc.section.2.1.p.6">A cache <em class="bcp14">MAY</em> complete a stored incomplete response by making a subsequent range request (<a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) and combining the successful response with the stored entry, as defined in <a href="#combining.responses" title="Combining Partial Content">Section&nbsp;2.9</a>. A cache <em class="bcp14">MUST NOT</em> use an incomplete response to answer requests unless the response has been made complete or the request is partial and specifies
-         a range that is wholly within the incomplete response. A cache <em class="bcp14">MUST NOT</em> send a partial response to a client without explicitly marking it as such using the 206 (Partial Content) status code.
+         a range that is wholly within the incomplete response. A cache <em class="bcp14">MUST NOT</em> send a partial response to a client without explicitly marking it as such using the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code.
       </p>
       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="constructing.responses.from.caches" href="#constructing.responses.from.caches">Constructing Responses from Caches</a></h2>
@@ -1066 +1065 @@
       <p id="rfc.section.2.3.3.p.4">A cache <em class="bcp14">SHOULD</em> append a Warning header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.
       </p>
-      <p id="rfc.section.2.3.3.p.5">If a cache receives a first-hand response (either an entire response, or a 304 (Not Modified) response) that it would normally
-         forward to the requesting client, and the received response is no longer fresh, the cache can forward it to the requesting
-         client without adding a new Warning (but without removing any existing Warning header fields). A cache shouldn't attempt to
-         validate a response simply because that response became stale in transit.
+      <p id="rfc.section.2.3.3.p.5">If a cache receives a first-hand response (either an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache
+         can forward it to the requesting client without adding a new Warning (but without removing any existing Warning header fields).
+         A cache shouldn't attempt to validate a response simply because that response became stale in transit.
       </p>
       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
@@ -1087 +1085 @@
       <p id="rfc.section.2.4.p.5"> </p>
       <ul>
-         <li>A 304 (Not Modified) response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Responses with 304 Not Modified">Section&nbsp;2.4.1</a>.
+         <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Responses with 304 Not Modified">Section&nbsp;2.4.1</a>.
          </li>
          <li>A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
@@ -1098 +1096 @@
       </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 304 (Not Modified) 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 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>
       <ul>

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

@@ -508 +508 @@
    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 206 (Partial Content) response &MAY; be stored as if it were
+   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
    incomplete or partial content responses if it does not support the Range
@@ -522 +522 @@
    specifies a range that is wholly within the incomplete response.
    A cache &MUST-NOT; send a partial response to a client without explicitly
-   marking it as such using the 206 (Partial Content) status code.
+   marking it as such using the <x:ref>206 (Partial Content)</x:ref> status code.
 </t>
 </section>
@@ -866 +866 @@
 <t>
    If a cache receives a first-hand response (either an entire response, or a
-   304 (Not Modified) response) that it would normally forward to the
+   <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward to the
    requesting client, and the received response is no longer fresh, the cache
    can forward it to the requesting client without adding a new Warning (but
@@ -906 +906 @@
    <list style="symbols">
       <t>
-         A 304 (Not Modified) response status code indicates that the stored
+         A <x:ref>304 (Not Modified)</x:ref> response status code indicates that the stored
          response can be updated and reused; see <xref
          target="freshening.responses"/>.
@@ -928 +928 @@
 <section anchor="freshening.responses" title="Freshening Responses with 304 Not Modified">
 <t>
-   When a cache receives a 304 (Not Modified) response and already has one
+   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
    to identify which of the stored responses are updated by this new response
@@ -2308 +2308 @@
     </front>
     <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p4-conditional-&ID-VERSION;" />
-    <x:source basename="p4-conditional" href="p4-conditional.xml" />
+    <x:source basename="p4-conditional" href="p4-conditional.xml">
+      <x:defines>304 (Not Modified)</x:defines>
+    </x:source>
   </reference>
 
@@ -2329 +2331 @@
     </front>
     <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p5-range-&ID-VERSION;" />
-    <x:source basename="p5-range" href="p5-range.xml" />
+    <x:source basename="p5-range" href="p5-range.xml">
+      <x:defines>206 (Partial Content)</x:defines>
+    </x:source>
   </reference>
 

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 2, 2013"; 
+       content: "Expires January 4, 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-01">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-03">
       <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 2, 2013</td>
+               <td class="left">Expires: January 4, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">July 1, 2012</td>
+               <td class="right">July 3, 2012</td>
             </tr>
          </tbody>
@@ -553 +553 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 2, 2013.</p>
+      <p>This Internet-Draft will expire on January 4, 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>
@@ -683 +683 @@
          with or without padding, but excluding whitespace (<a href="#RFC4648" id="rfc.xref.RFC4648.1"><cite title="The Base16, Base32, and Base64 Data Encodings">[RFC4648]</cite></a>).
       </p>
-      <p id="rfc.section.2.1.p.5">The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.
-      </p>
-      <p id="rfc.section.2.1.p.6">The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.
+      <p id="rfc.section.2.1.p.5">The <a href="#status.401" class="smpl">401 (Unauthorized)</a> response message is used by an origin server to challenge the authorization of a user agent. This response <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.
+      </p>
+      <p id="rfc.section.2.1.p.6">The <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response message is used by a proxy to challenge the authorization of a client and <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.
       </p>
       <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.c.1"></span><span id="rfc.iref.g.4"></span>  <a href="#challenge.and.response" class="smpl">challenge</a>   = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#notation" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">b64token</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ]
@@ -699 +699 @@
          </p> 
       </div>
-      <p id="rfc.section.2.1.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401
-         (Unauthorized) — can do so by including an Authorization header field with the request.
-      </p>
-      <p id="rfc.section.2.1.p.11">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a 407 (Proxy Authentication
-         Required) — can do so by including a Proxy-Authorization header field with the request.
+      <p id="rfc.section.2.1.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> — can do so by including an Authorization header field with the request.
+      </p>
+      <p id="rfc.section.2.1.p.11">A client that wishes to authenticate itself with a proxy — usually, but not necessarily, after receiving a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> — can do so by including a Proxy-Authorization header field with the request.
       </p>
       <p id="rfc.section.2.1.p.12">Both the Authorization field value and the Proxy-Authorization field value contain the client's credentials for the realm
@@ -712 +710 @@
       <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.c.2"></span><span id="rfc.iref.g.5"></span>  <a href="#challenge.and.response" class="smpl">credentials</a> = <a href="#challenge.and.response" class="smpl">auth-scheme</a> [ 1*<a href="#notation" class="smpl">SP</a> ( <a href="#challenge.and.response" class="smpl">b64token</a> / #<a href="#challenge.and.response" class="smpl">auth-param</a> ) ]
 </pre><p id="rfc.section.2.1.p.14">Upon a request for a protected resource that omits credentials, contains invalid credentials (e.g., a bad password) or partial
-         credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> return a 401 (Unauthorized) response. Such responses <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource.
+         credentials (e.g., when the authentication scheme requires more than one round trip), an origin server <em class="bcp14">SHOULD</em> return a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Such responses <em class="bcp14">MUST</em> include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource.
       </p>
       <p id="rfc.section.2.1.p.15">Likewise, upon a request that requires authentication by proxies that omit credentials or contain invalid or partial credentials,
-         a proxy <em class="bcp14">SHOULD</em> return a 407 (Proxy Authentication Required) response. Such responses <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy.
+         a proxy <em class="bcp14">SHOULD</em> return a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response. Such responses <em class="bcp14">MUST</em> include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy.
       </p>
       <p id="rfc.section.2.1.p.16">A server receiving credentials that are valid, but not adequate to gain access, ought to respond with the 403 (Forbidden)
@@ -823 +821 @@
       <div id="rfc.iref.s.2"></div>
       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2>
-      <p id="rfc.section.3.2.p.1">This code is similar to 401 (Unauthorized), but indicates that the client ought to first authenticate itself with the proxy.
-         The proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.3</a>).
+      <p id="rfc.section.3.2.p.1">This code is similar to <a href="#status.401" class="smpl">401 (Unauthorized)</a>, but indicates that the client ought to first authenticate itself with the proxy. The proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;4.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;4.3</a>).
       </p>
       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
@@ -832 +829 @@
       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="header.authorization" href="#header.authorization">Authorization</a></h2>
       <p id="rfc.section.4.1.p.1">The "Authorization" header field allows a user agent to authenticate itself with a server — usually, but not necessarily,
-         after receiving a 401 (Unauthorized) response. Its value consists of credentials containing information of the user agent
-         for the realm of the resource being requested.
+         after receiving a <a href="#status.401" class="smpl">401
+            (Unauthorized)</a> response. Its value consists of credentials containing information of the user agent for the realm of the resource being requested.
       </p>
       <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.6"></span>  <a href="#header.authorization" class="smpl">Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a>
@@ -856 +853 @@
       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
       <p id="rfc.section.4.2.p.1">The "Proxy-Authenticate" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters
-         applicable to the proxy for this 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.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
+         applicable to the proxy for this 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.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a <a href="#status.407" class="smpl">407 (Proxy Authentication Required)</a> response.
       </p>
       <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a> = 1#<a href="#challenge.and.response" class="smpl">challenge</a>
@@ -884 +881 @@
          applicable to 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.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
       </p>
-      <p id="rfc.section.4.4.p.2">It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages and <em class="bcp14">MAY</em> be included in other response messages to indicate that supplying credentials (or different credentials) might affect the
+      <p id="rfc.section.4.4.p.2">It <em class="bcp14">MUST</em> be included in <a href="#status.401" class="smpl">401 (Unauthorized)</a> response messages and <em class="bcp14">MAY</em> be included in other response messages to indicate that supplying credentials (or different credentials) might affect the
          response.
       </p>

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

@@ -258 +258 @@
 </t>
 <t>
-   The 401 (Unauthorized) response message is used by an origin server
+   The <x:ref>401 (Unauthorized)</x:ref> response message is used by an origin server
    to challenge the authorization of a user agent. This response &MUST;
    include a WWW-Authenticate header field containing at least one
@@ -264 +264 @@
 </t>
 <t>   
-   The 407 (Proxy Authentication Required) response message is used by a proxy to
+   The <x:ref>407 (Proxy Authentication Required)</x:ref> response message is used by a proxy to
    challenge the authorization of a client and &MUST; include a Proxy-Authenticate
    header field containing at least one challenge
@@ -290 +290 @@
 <t>
    A user agent that wishes to authenticate itself with an origin server
-   &mdash; usually, but not necessarily, after receiving a 401 (Unauthorized)
+   &mdash; usually, but not necessarily, after receiving a <x:ref>401 (Unauthorized)</x:ref>
    &mdash; can do so by including an Authorization header field with the
    request.
@@ -296 +296 @@
 <t>   
    A client that wishes to authenticate itself with a proxy &mdash; usually,
-   but not necessarily, after receiving a 407 (Proxy Authentication Required)
+   but not necessarily, after receiving a <x:ref>407 (Proxy Authentication Required)</x:ref>
    &mdash; can do so by including a Proxy-Authorization header field with the
    request.
@@ -316 +316 @@
    invalid credentials (e.g., a bad password) or partial credentials (e.g.,
    when the authentication scheme requires more than one round trip), an origin
-   server &SHOULD; return a 401 (Unauthorized) response. Such responses &MUST;
+   server &SHOULD; return a <x:ref>401 (Unauthorized)</x:ref> response. Such responses &MUST;
    include a WWW-Authenticate header field containing at least one (possibly
    new) challenge applicable to the requested resource.
@@ -323 +323 @@
    Likewise, upon a request that requires authentication by proxies that omit
    credentials or contain invalid or partial credentials, a proxy &SHOULD;
-   return a 407 (Proxy Authentication Required) response. Such responses
+   return a <x:ref>407 (Proxy Authentication Required)</x:ref> response. Such responses
    &MUST; include a Proxy-Authenticate header field containing a (possibly
    new) challenge applicable to the proxy.
@@ -498 +498 @@
   <iref primary="true" item="401 Unauthorized (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="401 Unauthorized" x:for-anchor=""/>
+  <x:anchor-alias value="401 (Unauthorized)"/>
 <t>
    The request requires user authentication. The response &MUST; include a
@@ -515 +516 @@
   <iref primary="true" item="407 Proxy Authentication Required (status code)" x:for-anchor=""/>
   <iref primary="true" item="Status Codes" subitem="407 Proxy Authentication Required" x:for-anchor=""/>
-<t>
-   This code is similar to 401 (Unauthorized), but indicates that the
+  <x:anchor-alias value="407 (Proxy Authentication Required)"/>
+<t>
+   This code is similar to <x:ref>401 (Unauthorized)</x:ref>, but indicates that the
    client ought to first authenticate itself with the proxy. The proxy &MUST;
    return a Proxy-Authenticate header field (<xref target="header.proxy-authenticate"/>) containing a
@@ -538 +540 @@
 <t>
    The "Authorization" header field allows a user agent to authenticate
-   itself with a server &mdash; usually, but not necessarily, after receiving a 401
-   (Unauthorized) response. Its value consists of credentials containing 
+   itself with a server &mdash; usually, but not necessarily, after receiving a <x:ref>401
+   (Unauthorized)</x:ref> response. Its value consists of credentials containing 
    information of the user agent for the realm of the resource being
    requested.
@@ -593 +595 @@
    challenge that indicates the authentication scheme(s) and parameters
    applicable to the proxy for this effective request URI (&effective-request-uri;).
-   It &MUST; be included as part of a 407 (Proxy Authentication Required) response.
+   It &MUST; be included as part of a <x:ref>407 (Proxy Authentication Required)</x:ref> response.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Proxy-Authenticate"/>
@@ -649 +651 @@
 </t>
 <t>   
-   It &MUST; be included in 401 (Unauthorized) response messages and &MAY; be
+   It &MUST; be included in <x:ref>401 (Unauthorized)</x:ref> response messages and &MAY; be
    included in other response messages to indicate that supplying credentials
    (or different credentials) might affect the response.