Changeset 1907

Timestamp:

18/09/12 23:52:32 (8 years ago)

Author:

fielding@…

Message:

Rewrite the "identifying a representation" and considerations for
new status codes to be more concise and consistent.

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (41 diffs)
• p2-semantics.xml (modified) (3 diffs)

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

@@ -585 +585 @@
          <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#resource">Resource</a></li>
          <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul>
-               <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#payload">Message Payload</a></li>
-               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#associating.representation.with.resource">Associating a Representation with its Resource</a></li>
-               <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a><ul>
-                     <li><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
-                     <li><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-encoding">Content-Encoding</a></li>
-                     <li><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-language">Content-Language</a></li>
-                     <li><a href="#rfc.section.3.3.4">3.3.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-location">Content-Location</a></li>
+               <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#payload">Message Payload</a><ul>
+                     <li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#payload.header.fields">Payload Header Fields</a></li>
+                     <li><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#identifying.payload">Identifying the Payload</a></li>
                   </ul>
                </li>
-               <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#selected.representation">Selected Representation Header Fields</a></li>
-               <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
-               <li><a href="#rfc.section.3.6">3.6</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul>
-                     <li><a href="#rfc.section.3.6.1">3.6.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li>
-                     <li><a href="#rfc.section.3.6.2">3.6.2</a>&nbsp;&nbsp;&nbsp;<a href="#reactive.negotiation">Reactive Negotiation</a></li>
+               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a><ul>
+                     <li><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
+                     <li><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-encoding">Content-Encoding</a></li>
+                     <li><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-language">Content-Language</a></li>
+                     <li><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;&nbsp;&nbsp;<a href="#header.content-location">Content-Location</a></li>
+                  </ul>
+               </li>
+               <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#selected.representation">Selected Representation Header Fields</a></li>
+               <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
+               <li><a href="#rfc.section.3.5">3.5</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul>
+                     <li><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li>
+                     <li><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;&nbsp;&nbsp;<a href="#reactive.negotiation">Reactive Negotiation</a></li>
                   </ul>
                </li>
@@ -897 +900 @@
          the error and what next steps are suggested for resolving it.
       </p>
-      <p id="rfc.section.3.1.p.5">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload
+      <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h3>
+      <p id="rfc.section.3.1.1.p.1">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload
          header fields". Payload header fields are defined in other parts of this specification, due to their impact on message parsing.
       </p>
@@ -924 +928 @@
          </table>
       </div>
-      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="associating.representation.with.resource" href="#associating.representation.with.resource">Associating a Representation with its Resource</a></h2>
-      <p id="rfc.section.3.2.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
-      <p id="rfc.section.3.2.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
-      <p id="rfc.section.3.2.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
-         rules are used (with the first applicable one being selected):
+      <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a>&nbsp;<a id="identifying.payload" href="#identifying.payload">Identifying the Payload</a></h3>
+      <p id="rfc.section.3.1.2.p.1">When a complete or partial representation is transferred in a message payload, it is often desirable for the sender to supply,
+         or the recipient to determine, an identifier for the resource corresponding to that representation.
+      </p>
+      <p id="rfc.section.3.1.2.p.2">The following rules are used to determine such a URI for the payload of a request message: </p>
+      <ul>
+         <li>If the request has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, then the sender asserts that the payload is a representation of the resource identified by the Content-Location
+            field-value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by HTTP).
+            The information might still be useful for revision history links.
+         </li>
+         <li>Otherwise, the payload is unidentified.</li>
+      </ul>
+      <p id="rfc.section.3.1.2.p.3">The following rules, to be applied in order until a match is found, are used to determine such a URI for the payload of a
+         response message: 
       </p>
       <ol>
-         <li>If the response status code is <a href="#status.200" class="smpl">200 (OK)</a> or <a href="#status.203" class="smpl">203
-               (Non-Authoritative Information)</a> and the request method was GET, the response payload is a representation of the target resource.
-         </li>
-         <li>If the response status code is <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> and the request method was GET or HEAD, the response payload is a partial representation of the target resource.
-         </li>
-         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, and that URI is the same as the effective request URI, the response payload is a representation of the target
-            resource.
-         </li>
-         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, and that URI is not the same as the effective request URI, then the response asserts that its payload is a representation
-            of the resource identified by the Content-Location URI. However, such an assertion cannot be trusted unless it can be verified
-            by other means (not defined by HTTP).
-         </li>
-         <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
+         <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload's identifier is 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.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
+         </li>
+         <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified representation of the target resource; as such, the effective request URI might only
+            act as an identifier for the payload's representation when a request is made via the same chain of intermediaries.
+         </li>
+         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload's identifier is
+            the effective request URI.
+         </li>
+         <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to a URI different from the effective request URI, then the sender asserts
+            that the payload is a representation of the resource identified by the Content-Location field-value. However, such an assertion
+            cannot be trusted unless it can be verified by other means (not defined by HTTP).
+         </li>
+         <li>Otherwise, the payload is unidentified.</li>
       </ol>
-      <p id="rfc.section.3.2.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like
-            cache invalidation.]</span> 
-      </p>
-      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
-      <p id="rfc.section.3.3.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message
+      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
+      <p id="rfc.section.3.2.p.1">Representation header fields define metadata about the representation data enclosed in the message body or, if no message
          body is present, about the representation that would have been transferred in a <a href="#status.200" class="smpl">200 (OK)</a> response to a simultaneous GET request with the same effective request URI.
       </p>
-      <p id="rfc.section.3.3.p.2">The following header fields are defined as representation metadata:</p>
+      <p id="rfc.section.3.2.p.2">The following header fields are defined as representation metadata:</p>
       <div id="rfc.table.u.2">
          <table class="tt full left" cellpadding="3" cellspacing="0">
@@ -964 +974 @@
                <tr>
                   <td class="left">Content-Type</td>
-                  <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;3.3.1</a></td>
+                  <td class="left"><a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;3.2.1</a></td>
                </tr>
                <tr>
                   <td class="left">Content-Encoding</td>
-                  <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;3.3.2</a></td>
+                  <td class="left"><a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;3.2.2</a></td>
                </tr>
                <tr>
                   <td class="left">Content-Language</td>
-                  <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;3.3.3</a></td>
+                  <td class="left"><a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;3.2.3</a></td>
                </tr>
                <tr>
                   <td class="left">Content-Location</td>
-                  <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;3.3.4</a></td>
+                  <td class="left"><a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;3.2.4</a></td>
                </tr>
                <tr>
@@ -986 +996 @@
       </div>
       <div id="rfc.iref.c.2"></div>
-      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h3>
-      <p id="rfc.section.3.3.1.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method,
+      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h3>
+      <p id="rfc.section.3.2.1.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method,
          the media type is that which would have been sent had the request been a GET.
       </p>
       <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.content-type" class="smpl">Content-Type</a> = <a href="#media.types" class="smpl">media-type</a>
-</pre><p id="rfc.section.3.3.1.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;8.5</a>. An example of the field is
+</pre><p id="rfc.section.3.2.1.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;8.5</a>. An example of the field is
       </p>
       <div id="rfc.figure.u.2"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
-</pre><p id="rfc.section.3.3.1.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;3.5</a>.
+</pre><p id="rfc.section.3.2.1.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;3.4</a>.
       </p>
       <div id="rfc.iref.c.3"></div>
-      <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h3>
-      <p id="rfc.section.3.3.2.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent
+      <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h3>
+      <p id="rfc.section.3.2.2.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation beyond those inherent
          in the media type, and thus what decoding mechanisms have to be applied in order to obtain the media-type referenced by the <a href="#header.content-type" class="smpl">Content-Type</a> header field. Content-Encoding is primarily used to allow a representation to be compressed without losing the identity of
          its underlying media type.
       </p>
       <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
-</pre><p id="rfc.section.3.3.2.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;8.4</a>. An example of its use is
+</pre><p id="rfc.section.3.2.2.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;8.4</a>. An example of its use is
       </p>
       <div id="rfc.figure.u.4"></div><pre class="text">  Content-Encoding: gzip
-</pre><p id="rfc.section.3.3.2.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
+</pre><p id="rfc.section.3.2.2.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
          and is only decoded before rendering or analogous usage. However, a transforming proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
          directive is present in the message.
       </p>
-      <p id="rfc.section.3.3.2.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would
+      <p id="rfc.section.3.2.2.p.6">If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would
          not be restated as a Content-Encoding even if it happens to be the same algorithm as one of the content-codings. Such a content-coding
          would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin
@@ -1017 +1027 @@
          as ..." dialog instead of automatic decompression and rendering of content).
       </p>
-      <p id="rfc.section.3.3.2.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field that lists the content-coding(s) applied.
-      </p>
-      <p id="rfc.section.3.3.2.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. 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.2.p.9">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
+      <p id="rfc.section.3.2.2.p.7">A representation that has a content-coding applied to it <em class="bcp14">MUST</em> include a Content-Encoding header field that lists the content-coding(s) applied.
+      </p>
+      <p id="rfc.section.3.2.2.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. 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.2.2.p.9">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
       </p>
       <div id="rfc.iref.c.4"></div>
-      <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h3>
-      <p id="rfc.section.3.3.3.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note
+      <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h3>
+      <p id="rfc.section.3.2.3.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note
          that this might not be equivalent to all the languages used within the representation.
       </p>
       <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
-</pre><p id="rfc.section.3.3.3.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;8.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
+</pre><p id="rfc.section.3.2.3.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;8.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
          user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate
          field is
       </p>
       <div id="rfc.figure.u.6"></div><pre class="text">  Content-Language: da
-</pre><p id="rfc.section.3.3.3.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
+</pre><p id="rfc.section.3.2.3.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
          that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language
          it is intended.
       </p>
-      <p id="rfc.section.3.3.3.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented
+      <p id="rfc.section.3.2.3.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented
          simultaneously in the original Maori and English versions, would call for
       </p>
       <div id="rfc.figure.u.7"></div><pre class="text">  Content-Language: mi, en
-</pre><p id="rfc.section.3.3.3.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
+</pre><p id="rfc.section.3.2.3.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
          linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly
          intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
       </p>
-      <p id="rfc.section.3.3.3.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents.
+      <p id="rfc.section.3.2.3.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents.
       </p>
       <div id="rfc.iref.c.5"></div>
-      <h3 id="rfc.section.3.3.4"><a href="#rfc.section.3.3.4">3.3.4</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h3>
-      <p id="rfc.section.3.3.4.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
+      <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h3>
+      <p id="rfc.section.3.2.4.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
          message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a <a href="#status.200" class="smpl">200 (OK)</a> response would contain the same representation that is enclosed as payload in this message.
       </p>
       <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.4"></span>  <a href="#header.content-location" class="smpl">Content-Location</a> = <a href="#imported.abnf" class="smpl">absolute-URI</a> / <a href="#imported.abnf" class="smpl">partial-URI</a>
-</pre><p id="rfc.section.3.3.4.p.3">The Content-Location value is not a replacement for 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.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
+</pre><p id="rfc.section.3.2.4.p.3">The Content-Location value is not a replacement for 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.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
          body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
       </p>
-      <p id="rfc.section.3.3.4.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response
+      <p id="rfc.section.3.2.4.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response
          payload <em class="bcp14">SHOULD</em> be considered a current representation of that resource. For a GET or HEAD request, this is the same as the default semantics
          when no Content-Location is provided by the server. For a state-changing request like PUT or POST, it implies that the server's
@@ -1064 +1074 @@
          need for a subsequent GET request.
       </p>
-      <p id="rfc.section.3.3.4.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin
+      <p id="rfc.section.3.2.4.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin
          server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD
          request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation
@@ -1072 +1082 @@
          the payload of the <a href="#status.200" class="smpl">200 (OK)</a> response; the Content-Location value provides an identifier for retrieving a copy of that same receipt in the future.
       </p>
-      <p id="rfc.section.3.3.4.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
+      <p id="rfc.section.3.2.4.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
          representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is
          providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated
@@ -1080 +1090 @@
          latter semantics, it would have applied the PUT directly to the Content-Location URI.
       </p>
-      <p id="rfc.section.3.3.4.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use
+      <p id="rfc.section.3.2.4.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use
          in other contexts, such as within source links or other metadata.
       </p>
-      <p id="rfc.section.3.3.4.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used
+      <p id="rfc.section.3.2.4.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used
          to respond to later requests on that Content-Location URI.
       </p>
-      <p id="rfc.section.3.3.4.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>
-      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2>
-      <p id="rfc.section.3.4.p.1"><span id="rfc.iref.s.1"></span> We use the term "<dfn>selected representation</dfn>" to refer to the the current representation of a target resource that would have been selected in a successful response if
+      <p id="rfc.section.3.2.4.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>
+      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2>
+      <p id="rfc.section.3.3.p.1"><span id="rfc.iref.s.1"></span> We use the term "<dfn>selected representation</dfn>" to refer to the the current representation of a target resource that would have been selected in a successful response if
          the same request had used the method GET and excluded any conditional request header fields.
       </p>
-      <p id="rfc.section.3.4.p.2">Additional header fields define metadata about the selected representation, which might differ from the representation included
+      <p id="rfc.section.3.3.p.2">Additional header fields define metadata about the selected representation, which might differ from the representation included
          in the message for responses to some state-changing methods. The following header fields are defined as selected representation
          metadata:
@@ -1115 +1125 @@
          </table>
       </div>
-      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
-      <p id="rfc.section.3.5.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
+      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
+      <p id="rfc.section.3.4.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
          to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by
          the representation metadata header fields.
       </p>
-      <p id="rfc.section.3.5.p.2">The data type of the representation data is determined via the header fields <a href="#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-encoding" class="smpl">Content-Encoding</a>. These define a two-layer, ordered encoding model:
+      <p id="rfc.section.3.4.p.2">The data type of the representation data is determined via the header fields <a href="#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-encoding" class="smpl">Content-Encoding</a>. These define a two-layer, ordered encoding model:
       </p>
       <div id="rfc.figure.u.9"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
-</pre><p id="rfc.section.3.5.p.4"> <a href="#header.content-type" class="smpl">Content-Type</a> specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload
+</pre><p id="rfc.section.3.4.p.4"> <a href="#header.content-type" class="smpl">Content-Type</a> specifies the media type of the underlying data, which defines both the data format and how that data <em class="bcp14">SHOULD</em> be processed by the recipient (within the scope of the request method semantics). Any HTTP/1.1 message containing a payload
          body <em class="bcp14">SHOULD</em> include a Content-Type header field defining the media type of the associated representation unless that metadata is unknown
          to the sender. If the Content-Type header field is not present, it indicates that the sender does not know the media type
          of the representation; recipients <em class="bcp14">MAY</em> either assume that the media type is "application/octet-stream" (<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-4.5.1">Section 4.5.1</a>) or examine the content to determine its type.
       </p>
-      <p id="rfc.section.3.5.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
+      <p id="rfc.section.3.4.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
          a given representation, with the result that some clients will examine a response body's content and override the specified
          type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege
@@ -1135 +1145 @@
          such "content sniffing" when it is used.
       </p>
-      <p id="rfc.section.3.5.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that
+      <p id="rfc.section.3.4.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that
          are a property of the representation. If Content-Encoding is not present, then there is no additional encoding beyond that
          defined by the <a href="#header.content-type" class="smpl">Content-Type</a> header field.
       </p>
-      <h2 id="rfc.section.3.6"><a href="#rfc.section.3.6">3.6</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2>
-      <p id="rfc.section.3.6.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
+      <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2>
+      <p id="rfc.section.3.5.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
          processing. Often, the server has different ways of representing the same information; for example, in different formats,
          languages, or using different character encodings.
       </p>
-      <p id="rfc.section.3.6.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
+      <p id="rfc.section.3.5.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
          which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP
          provides mechanisms for "content negotiation" — a process of allowing selection of a representation of a given resource, when
          more than one is available.
       </p>
-      <p id="rfc.section.3.6.p.3">This specification defines two patterns of content negotiation; "proactive", where the server selects the representation based
+      <p id="rfc.section.3.5.p.3">This specification defines two patterns of content negotiation; "proactive", where the server selects the representation based
          upon the client's stated preferences, and "reactive" negotiation, where the server provides a list of representations for
          the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an "active
@@ -1155 +1165 @@
          selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed.
       </p>
-      <p id="rfc.section.3.6.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
+      <p id="rfc.section.3.5.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
          of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by
          a user-agent), proactive negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations
          to choose from is very large, reactive negotiation might not be appropriate.
       </p>
-      <p id="rfc.section.3.6.p.5">Note that, in all cases, the supplier of representations has the responsibility for determining which representations might
+      <p id="rfc.section.3.5.p.5">Note that, in all cases, the supplier of representations has the responsibility for determining which representations might
          be considered to be the "same information".
       </p>
-      <h3 id="rfc.section.3.6.1"><a href="#rfc.section.3.6.1">3.6.1</a>&nbsp;<a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>
-      <p id="rfc.section.3.6.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called proactive
+      <h3 id="rfc.section.3.5.1"><a href="#rfc.section.3.5.1">3.5.1</a>&nbsp;<a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>
+      <p id="rfc.section.3.5.1.p.1">If the selection of the best representation for a response is made by an algorithm located at the server, it is called proactive
          negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g.,
          language, content-coding, etc.) and the contents of particular header fields in the request message or on other information
          pertaining to the request (such as the network address of the client).
       </p>
-      <p id="rfc.section.3.6.1.p.2">Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
+      <p id="rfc.section.3.5.1.p.2">Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
          to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response
          (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to
          improve the server's guess, the user agent <em class="bcp14">MAY</em> include request header fields (<a href="#header.accept" class="smpl">Accept</a>, <a href="#header.accept-language" class="smpl">Accept-Language</a>, <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>, etc.) which describe its preferences for such a response.
       </p>
-      <p id="rfc.section.3.6.1.p.3">Proactive negotiation has disadvantages: </p>
+      <p id="rfc.section.3.5.1.p.3">Proactive negotiation has disadvantages: </p>
       <ol>
          <li>It is impossible for the server to accurately determine what might be "best" for any given user, since that would require
@@ -1186 +1196 @@
          <li>It might limit a public cache's ability to use the same response for multiple user's requests.</li>
       </ol>
-      <p id="rfc.section.3.6.1.p.4">Proactive negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor them.
+      <p id="rfc.section.3.5.1.p.4">Proactive negotiation allows the user agent to specify its preferences, but it cannot expect responses to always honor them.
          For example, the origin server might not implement proactive negotiation, or it might decide that sending a response that
          doesn't conform to them is better than sending a <a href="#status.406" class="smpl">406
             (Not Acceptable)</a> response.
       </p>
-      <p id="rfc.section.3.6.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities
+      <p id="rfc.section.3.5.1.p.5">HTTP/1.1 includes the following header fields for enabling proactive negotiation through description of user agent capabilities
          and user preferences: <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;5.3.2</a>), <a href="#header.accept-charset" class="smpl">Accept-Charset</a> (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;5.3.3</a>), <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section&nbsp;5.3.4</a>), <a href="#header.accept-language" class="smpl">Accept-Language</a> (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;5.3.5</a>), and <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;5.5.3</a>). However, an origin server is not limited to these dimensions and <em class="bcp14">MAY</em> vary the response based on any aspect of the request, including aspects of the connection (e.g., IP address) or information
          within extension header fields not defined by this specification.
       </p>
-      <div class="note" id="rfc.section.3.6.1.p.6"> 
+      <div class="note" id="rfc.section.3.5.1.p.6"> 
          <p> <b>Note:</b> In practice, <a href="#header.user-agent" class="smpl">User-Agent</a> based negotiation is fragile, because new clients might not be recognized.
          </p> 
       </div>
-      <p id="rfc.section.3.6.1.p.7">The <a href="#header.vary" class="smpl">Vary</a> header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;7.2.2</a>) can be used to express the parameters the server uses to select a representation that is subject to proactive negotiation.
-      </p>
-      <h3 id="rfc.section.3.6.2"><a href="#rfc.section.3.6.2">3.6.2</a>&nbsp;<a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3>
-      <p id="rfc.section.3.6.2.p.1">With reactive negotiation, selection of the best representation for a response is performed by the user agent after receiving
+      <p id="rfc.section.3.5.1.p.7">The <a href="#header.vary" class="smpl">Vary</a> header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;7.2.2</a>) can be used to express the parameters the server uses to select a representation that is subject to proactive negotiation.
+      </p>
+      <h3 id="rfc.section.3.5.2"><a href="#rfc.section.3.5.2">3.5.2</a>&nbsp;<a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3>
+      <p id="rfc.section.3.5.2.p.1">With reactive negotiation, selection of the best representation for a response is performed by the user agent after receiving
          an initial response from the origin server. Selection is based on a list of the available representations of the response
          included within the header fields or body of the initial response, with each representation identified by its own URI. Selection
@@ -1208 +1218 @@
          user selecting from a generated (possibly hypertext) menu.
       </p>
-      <p id="rfc.section.3.6.2.p.2">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or
+      <p id="rfc.section.3.5.2.p.2">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or
          encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
          when public caches are used to distribute server load and reduce network usage.
       </p>
-      <p id="rfc.section.3.6.2.p.3">Reactive negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
+      <p id="rfc.section.3.5.2.p.3">Reactive negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
          This second request is only efficient when caching is used. In addition, this specification does not define any mechanism
          for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension
          and used within HTTP/1.1.
       </p>
-      <p id="rfc.section.3.6.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling reactive negotiation when the server is unwilling or unable to provide a varying response using
+      <p id="rfc.section.3.5.2.p.4">This specification defines the <a href="#status.300" class="smpl">300 (Multiple Choices)</a> and <a href="#status.406" class="smpl">406 (Not Acceptable)</a> status codes for enabling reactive negotiation when the server is unwilling or unable to provide a varying response using
          proactive negotiation.
       </p>
@@ -1403 +1413 @@
       <p id="rfc.section.4.3.3.p.4">If a resource has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a> and contain a representation which describes the status of the request and refers to the new resource, and a <a href="#header.location" class="smpl">Location</a> header field (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;7.1.1</a>).
       </p>
-      <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.3.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
+      <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.2.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
       </p>
       <p id="rfc.section.4.3.3.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.
@@ -2080 +2090 @@
          </li>
       </ul>
-      <p id="rfc.section.6.p.4">For most status codes the response can carry a payload, in which case a <a href="#header.content-type" class="smpl">Content-Type</a> header field indicates the payload's media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;3.3.1</a>).
+      <p id="rfc.section.6.p.4">For most status codes the response can carry a payload, in which case a <a href="#header.content-type" class="smpl">Content-Type</a> header field indicates the payload's media type (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;3.2.1</a>).
       </p>
       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="overview.of.status.codes" href="#overview.of.status.codes">Overview of Status Codes</a></h2>
@@ -2434 +2444 @@
          </li>
          <li>
-            <p>Redirection offering a choice of matching resources for use by reactive content negotiation (<a href="#reactive.negotiation" title="Reactive Negotiation">Section&nbsp;3.6.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.
+            <p>Redirection offering a choice of matching resources for use by reactive content negotiation (<a href="#reactive.negotiation" title="Reactive Negotiation">Section&nbsp;3.5.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.
             </p>
          </li>
@@ -2463 +2473 @@
       <h3 id="rfc.section.6.4.1"><a href="#rfc.section.6.4.1">6.4.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
       <p id="rfc.section.6.4.1.p.1">The target resource has more than one representation, each with its own specific location, and reactive negotiation information
-         (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.6</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
+         (<a href="#content.negotiation" title="Content Negotiation">Section&nbsp;3.5</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
          location.
       </p>
@@ -2761 +2771 @@
       </p>
       <div class="note" id="rfc.section.7.1.1.p.9"> 
-         <p> <b>Note:</b> The <a href="#header.content-location" class="smpl">Content-Location</a> header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;3.3.4</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
+         <p> <b>Note:</b> The <a href="#header.content-location" class="smpl">Content-Location</a> header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;3.2.4</a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
             It is therefore possible for a response to contain header fields for both Location and Content-Location.
          </p> 
@@ -3057 +3067 @@
       </p>
       <div id="rfc.figure.u.57"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#content.codings" class="smpl">content-coding</a>   = <a href="#imported.abnf" class="smpl">token</a>
-</pre><p id="rfc.section.8.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;5.3.4</a>) and <a href="#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;3.3.2</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
+</pre><p id="rfc.section.8.4.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;5.3.4</a>) and <a href="#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;3.2.2</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
          mechanism will be required to remove the encoding.
       </p>
@@ -3079 +3089 @@
       </ul>
       <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="media.types" href="#media.types">Media Types</a></h2>
-      <p id="rfc.section.8.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;3.3.1</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;5.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation.
+      <p id="rfc.section.8.5.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;3.2.1</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;5.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation.
       </p>
       <div id="rfc.figure.u.58"></div><pre class="inline"><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span>  <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#imported.abnf" class="smpl">OWS</a> ";" <a href="#imported.abnf" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
@@ -3257 +3267 @@
       </p>
       <h3 id="rfc.section.9.2.2"><a href="#rfc.section.9.2.2">9.2.2</a>&nbsp;<a id="considerations.for.new.status.codes" href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></h3>
-      <p id="rfc.section.9.2.2.p.1">When it is necessary to express new semantics for a HTTP response that aren't specific to a single application or media type,
-         and currently defined status codes are inadequate, a new status code can be registered.
-      </p>
-      <p id="rfc.section.9.2.2.p.2">HTTP status codes are generic; that is, they are potentially applicable to any resource, not just one particular media type,
-         "type" of resource, or application. As such, it is preferred that new HTTP status codes be registered in a document that isn't
-         specific to a single application, so that this is clear.
-      </p>
-      <p id="rfc.section.9.2.2.p.3">Definitions of new HTTP status codes typically explain the request conditions that produce a response containing the status
-         code (e.g., combinations of request header fields and/or method(s)), along with any interactions with response header fields
-         (e.g., those that are required, those that modify the semantics of the response).
-      </p>
-      <p id="rfc.section.9.2.2.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate
-         a zero-length response body. They can require the presence of one or more particular HTTP response header field(s).
-      </p>
-      <p id="rfc.section.9.2.2.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#associating.representation.with.resource" title="Associating a Representation with its Resource">Section&nbsp;3.2</a>; by default, it is anonymous).
+      <p id="rfc.section.9.2.2.p.1">When it is necessary to express semantics for a response that are not defined by current status codes, a new status code can
+         be registered. HTTP status codes are generic; they are potentially applicable to any resource, not just one particular media
+         type, "type" of resource, or application. As such, it is preferred that new status codes be registered in a document that
+         isn't specific to a single application.
+      </p>
+      <p id="rfc.section.9.2.2.p.2">New status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate
+         a zero-length response body.
+      </p>
+      <p id="rfc.section.9.2.2.p.3">A definition for a new status code ought to explain the request conditions that produce a response containing that status
+         code (e.g., combinations of request header fields and/or method(s)) along with any dependencies on response header fields
+         (e.g., what fields are required and what fields can modify the semantics). A response that can transfer a payload ought to
+         specify expected cache behavior (e.g., cacheability and freshness criteria, as described in <a href="#Part6" id="rfc.xref.Part6.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) and whether the payload has any implied association with an identified resource (<a href="#identifying.payload" title="Identifying the Payload">Section&nbsp;3.1.2</a>).
       </p>
       <h3 id="rfc.section.9.2.3"><a href="#rfc.section.9.2.3">9.2.3</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Registrations</a></h3>
@@ -3531 +3538 @@
          double-quotes will likely cause unnecessary confusion.
       </p>
-      <p id="rfc.section.9.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section&nbsp;3.3.1</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
+      <p id="rfc.section.9.3.1.p.8">Many header fields use a format including (case-insensitively) named parameters (for instance, <a href="#header.content-type" class="smpl">Content-Type</a>, defined in <a href="#header.content-type" id="rfc.xref.header.content-type.4" title="Content-Type">Section&nbsp;3.2.1</a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing
          parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for
          it (for an example, see the notes on parameter handling for media types in <a href="#media.types" title="Media Types">Section&nbsp;8.5</a>).
@@ -3625 +3632 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;3.3.2</a> 
+                  <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;3.2.2</a> 
                   </td>
                </tr>
@@ -3632 +3639 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;3.3.3</a> 
+                  <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;3.2.3</a> 
                   </td>
                </tr>
@@ -3639 +3646 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section&nbsp;3.3.4</a> 
+                  <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.4" title="Content-Location">Section&nbsp;3.2.4</a> 
                   </td>
                </tr>
@@ -3646 +3653 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section&nbsp;3.3.1</a> 
+                  <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.5" title="Content-Type">Section&nbsp;3.2.1</a> 
                   </td>
                </tr>
@@ -4139 +4146 @@
       <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
       <p id="rfc.section.C.p.1">Remove base URI setting semantics for "<a href="#header.content-location" class="smpl">Content-Location</a>" due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields,
-         and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.3.4</a>)
+         and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.2.4</a>)
       </p>
       <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section&nbsp;4.3.3</a>)
@@ -5000 +5007 @@
             </li>
             <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul>
-                  <li>Accept header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept.1">3.6.1</a>, <a href="#rfc.xref.header.accept.2">5.3</a>, <a href="#rfc.iref.a.1"><b>5.3.2</b></a>, <a href="#rfc.xref.header.accept.3">8.5</a>, <a href="#rfc.xref.header.accept.4">9.3.2</a></li>
-                  <li>Accept-Charset header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-charset.1">3.6.1</a>, <a href="#rfc.xref.header.accept-charset.2">5.3</a>, <a href="#rfc.iref.a.2"><b>5.3.3</b></a>, <a href="#rfc.xref.header.accept-charset.3">9.3.2</a>, <a href="#rfc.xref.header.accept-charset.4">C</a></li>
-                  <li>Accept-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-encoding.1">3.6.1</a>, <a href="#rfc.xref.header.accept-encoding.2">5.3</a>, <a href="#rfc.iref.a.3"><b>5.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.3">8.4</a>, <a href="#rfc.xref.header.accept-encoding.4">9.3.2</a>, <a href="#rfc.xref.header.accept-encoding.5">9.4.2</a></li>
-                  <li>Accept-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-language.1">3.6.1</a>, <a href="#rfc.xref.header.accept-language.2">5.3</a>, <a href="#rfc.iref.a.4"><b>5.3.5</b></a>, <a href="#rfc.xref.header.accept-language.3">9.3.2</a></li>
+                  <li>Accept header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept.1">3.5.1</a>, <a href="#rfc.xref.header.accept.2">5.3</a>, <a href="#rfc.iref.a.1"><b>5.3.2</b></a>, <a href="#rfc.xref.header.accept.3">8.5</a>, <a href="#rfc.xref.header.accept.4">9.3.2</a></li>
+                  <li>Accept-Charset header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-charset.1">3.5.1</a>, <a href="#rfc.xref.header.accept-charset.2">5.3</a>, <a href="#rfc.iref.a.2"><b>5.3.3</b></a>, <a href="#rfc.xref.header.accept-charset.3">9.3.2</a>, <a href="#rfc.xref.header.accept-charset.4">C</a></li>
+                  <li>Accept-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-encoding.1">3.5.1</a>, <a href="#rfc.xref.header.accept-encoding.2">5.3</a>, <a href="#rfc.iref.a.3"><b>5.3.4</b></a>, <a href="#rfc.xref.header.accept-encoding.3">8.4</a>, <a href="#rfc.xref.header.accept-encoding.4">9.3.2</a>, <a href="#rfc.xref.header.accept-encoding.5">9.4.2</a></li>
+                  <li>Accept-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept-language.1">3.5.1</a>, <a href="#rfc.xref.header.accept-language.2">5.3</a>, <a href="#rfc.iref.a.4"><b>5.3.5</b></a>, <a href="#rfc.xref.header.accept-language.3">9.3.2</a></li>
                   <li>Allow header field&nbsp;&nbsp;<a href="#rfc.xref.header.allow.1">4.1</a>, <a href="#rfc.xref.header.allow.2">7.4</a>, <a href="#rfc.iref.a.5"><b>7.4.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3.2</a>, <a href="#rfc.xref.header.allow.4">C</a></li>
                </ul>
@@ -5012 +5019 @@
                   <li>CONNECT method&nbsp;&nbsp;<a href="#rfc.xref.CONNECT.1">4.1</a>, <a href="#rfc.iref.c.7"><b>4.3.6</b></a>, <a href="#rfc.xref.CONNECT.2">9.1.3</a>, <a href="#rfc.xref.CONNECT.3">C</a></li>
                   <li>content negotiation&nbsp;&nbsp;<a href="#rfc.iref.c.1">1</a></li>
-                  <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">3.3</a>, <a href="#rfc.iref.c.3"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-encoding.2">8.4</a>, <a href="#rfc.xref.header.content-encoding.3">9.3.2</a></li>
-                  <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">3.3</a>, <a href="#rfc.iref.c.4"><b>3.3.3</b></a>, <a href="#rfc.xref.header.content-language.2">9.3.2</a></li>
-                  <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.3</a>, <a href="#rfc.iref.c.5"><b>3.3.4</b></a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.xref.header.content-location.3">7.1.1</a>, <a href="#rfc.xref.header.content-location.4">9.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>
+                  <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">3.2</a>, <a href="#rfc.iref.c.3"><b>3.2.2</b></a>, <a href="#rfc.xref.header.content-encoding.2">8.4</a>, <a href="#rfc.xref.header.content-encoding.3">9.3.2</a></li>
+                  <li>Content-Language header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-language.1">3.2</a>, <a href="#rfc.iref.c.4"><b>3.2.3</b></a>, <a href="#rfc.xref.header.content-language.2">9.3.2</a></li>
+                  <li>Content-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.2</a>, <a href="#rfc.iref.c.5"><b>3.2.4</b></a>, <a href="#rfc.xref.header.content-location.2">4.3.3</a>, <a href="#rfc.xref.header.content-location.3">7.1.1</a>, <a href="#rfc.xref.header.content-location.4">9.3.2</a>, <a href="#rfc.xref.header.content-location.5">C</a></li>
                   <li>Content-Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.iref.c.9">A.5</a>, <a href="#rfc.xref.no.content-transfer-encoding.1">C</a></li>
-                  <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.3</a>, <a href="#rfc.iref.c.2"><b>3.3.1</b></a>, <a href="#rfc.xref.header.content-type.2">6</a>, <a href="#rfc.xref.header.content-type.3">8.5</a>, <a href="#rfc.xref.header.content-type.4">9.3.1</a>, <a href="#rfc.xref.header.content-type.5">9.3.2</a></li>
+                  <li>Content-Type header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-type.1">3.2</a>, <a href="#rfc.iref.c.2"><b>3.2.1</b></a>, <a href="#rfc.xref.header.content-type.2">6</a>, <a href="#rfc.xref.header.content-type.3">8.5</a>, <a href="#rfc.xref.header.content-type.4">9.3.1</a>, <a href="#rfc.xref.header.content-type.5">9.3.2</a></li>
                </ul>
             </li>
@@ -5054 +5061 @@
                         <li><tt>codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.21"><b>5.3.4</b></a></li>
                         <li><tt>content-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>8.4</b></a></li>
-                        <li><tt>Content-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>3.3.2</b></a></li>
-                        <li><tt>Content-Language</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>3.3.3</b></a></li>
-                        <li><tt>Content-Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>3.3.4</b></a></li>
-                        <li><tt>Content-Type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>3.3.1</b></a></li>
+                        <li><tt>Content-Encoding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.2"><b>3.2.2</b></a></li>
+                        <li><tt>Content-Language</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.3"><b>3.2.3</b></a></li>
+                        <li><tt>Content-Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>3.2.4</b></a></li>
+                        <li><tt>Content-Type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>3.2.1</b></a></li>
                         <li><tt>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>7.2.1</b></a></li>
                         <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>8.1</b></a></li>
@@ -5129 +5136 @@
             </li>
             <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul>
-                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1</a>, <a href="#rfc.xref.Part1.8">3.1</a>, <a href="#rfc.xref.Part1.9">3.2</a>, <a href="#rfc.xref.Part1.10">3.3.4</a>, <a href="#rfc.xref.Part1.11">4.3.6</a>, <a href="#rfc.xref.Part1.12">4.3.7</a>, <a href="#rfc.xref.Part1.13">4.3.8</a>, <a href="#rfc.xref.Part1.14">4.3.8</a>, <a href="#rfc.xref.Part1.15">5.1</a>, <a href="#rfc.xref.Part1.16">5.5</a>, <a href="#rfc.xref.Part1.17">5.5.3</a>, <a href="#rfc.xref.Part1.18">6.2.2</a>, <a href="#rfc.xref.Part1.19">6.3.4</a>, <a href="#rfc.xref.Part1.20">6.3.6</a>, <a href="#rfc.xref.Part1.21">6.5.15</a>, <a href="#rfc.xref.Part1.22">6.6.6</a>, <a href="#rfc.xref.Part1.23">7</a>, <a href="#rfc.xref.Part1.24">7.4.2</a>, <a href="#rfc.xref.Part1.25">7.4.2</a>, <a href="#rfc.xref.Part1.26">8.4</a>, <a href="#rfc.xref.Part1.27">8.4</a>, <a href="#rfc.xref.Part1.28">8.4</a>, <a href="#rfc.xref.Part1.29">9.1.2</a>, <a href="#rfc.xref.Part1.30">9.3.1</a>, <a href="#rfc.xref.Part1.31">9.3.1</a>, <a href="#rfc.xref.Part1.32">9.3.1</a>, <a href="#rfc.xref.Part1.33">9.3.1</a>, <a href="#rfc.xref.Part1.34">9.3.1</a>, <a href="#rfc.xref.Part1.35">9.3.1</a>, <a href="#rfc.xref.Part1.36">9.4</a>, <a href="#rfc.xref.Part1.37">9.4.1</a>, <a href="#rfc.xref.Part1.38">9.4.1</a>, <a href="#rfc.xref.Part1.39">9.4.2</a>, <a href="#rfc.xref.Part1.40">9.4.2</a>, <a href="#rfc.xref.Part1.41">9.4.2</a>, <a href="#rfc.xref.Part1.42">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.43">C</a>, <a href="#rfc.xref.Part1.44">D</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a><ul>
+                  <li><em>Part1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.1">1</a>, <a href="#rfc.xref.Part1.2">1.1</a>, <a href="#rfc.xref.Part1.3">1.2</a>, <a href="#rfc.xref.Part1.4">2</a>, <a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.7">3.1.1</a>, <a href="#rfc.xref.Part1.8">3.1.1</a>, <a href="#rfc.xref.Part1.9">3.1.2</a>, <a href="#rfc.xref.Part1.10">3.2.4</a>, <a href="#rfc.xref.Part1.11">4.3.6</a>, <a href="#rfc.xref.Part1.12">4.3.7</a>, <a href="#rfc.xref.Part1.13">4.3.8</a>, <a href="#rfc.xref.Part1.14">4.3.8</a>, <a href="#rfc.xref.Part1.15">5.1</a>, <a href="#rfc.xref.Part1.16">5.5</a>, <a href="#rfc.xref.Part1.17">5.5.3</a>, <a href="#rfc.xref.Part1.18">6.2.2</a>, <a href="#rfc.xref.Part1.19">6.3.4</a>, <a href="#rfc.xref.Part1.20">6.3.6</a>, <a href="#rfc.xref.Part1.21">6.5.15</a>, <a href="#rfc.xref.Part1.22">6.6.6</a>, <a href="#rfc.xref.Part1.23">7</a>, <a href="#rfc.xref.Part1.24">7.4.2</a>, <a href="#rfc.xref.Part1.25">7.4.2</a>, <a href="#rfc.xref.Part1.26">8.4</a>, <a href="#rfc.xref.Part1.27">8.4</a>, <a href="#rfc.xref.Part1.28">8.4</a>, <a href="#rfc.xref.Part1.29">9.1.2</a>, <a href="#rfc.xref.Part1.30">9.3.1</a>, <a href="#rfc.xref.Part1.31">9.3.1</a>, <a href="#rfc.xref.Part1.32">9.3.1</a>, <a href="#rfc.xref.Part1.33">9.3.1</a>, <a href="#rfc.xref.Part1.34">9.3.1</a>, <a href="#rfc.xref.Part1.35">9.3.1</a>, <a href="#rfc.xref.Part1.36">9.4</a>, <a href="#rfc.xref.Part1.37">9.4.1</a>, <a href="#rfc.xref.Part1.38">9.4.1</a>, <a href="#rfc.xref.Part1.39">9.4.2</a>, <a href="#rfc.xref.Part1.40">9.4.2</a>, <a href="#rfc.xref.Part1.41">9.4.2</a>, <a href="#rfc.xref.Part1.42">11</a>, <a href="#Part1"><b>12.1</b></a>, <a href="#rfc.xref.Part1.43">C</a>, <a href="#rfc.xref.Part1.44">D</a>, <a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a>, <a href="#rfc.xref.Part1.48">D</a>, <a href="#rfc.xref.Part1.49">D</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.51">D</a>, <a href="#rfc.xref.Part1.52">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a><ul>
                         <li><em>Section 1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.3">1.2</a></li>
                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.19">6.3.4</a></li>
@@ -5138 +5145 @@
                         <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.45">D</a>, <a href="#rfc.xref.Part1.46">D</a>, <a href="#rfc.xref.Part1.47">D</a></li>
                         <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">9.3.1</a>, <a href="#rfc.xref.Part1.50">D</a>, <a href="#rfc.xref.Part1.53">D</a>, <a href="#rfc.xref.Part1.54">D</a>, <a href="#rfc.xref.Part1.55">D</a></li>
-                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">3.1</a></li>
+                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">3.1.1</a></li>
                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.20">6.3.6</a>, <a href="#rfc.xref.Part1.29">9.1.2</a></li>
-                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">3.1</a></li>
+                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.7">3.1.1</a></li>
                         <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.37">9.4.1</a></li>
                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.35">9.3.1</a></li>
@@ -5150 +5157 @@
                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.5">2</a>, <a href="#rfc.xref.Part1.11">4.3.6</a>, <a href="#rfc.xref.Part1.12">4.3.7</a></li>
                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">5.1</a></li>
-                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.9">3.2</a>, <a href="#rfc.xref.Part1.10">3.3.4</a>, <a href="#rfc.xref.Part1.23">7</a></li>
+                        <li><em>Section 5.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.6">2</a>, <a href="#rfc.xref.Part1.9">3.1.2</a>, <a href="#rfc.xref.Part1.10">3.2.4</a>, <a href="#rfc.xref.Part1.23">7</a></li>
                         <li><em>Section 5.7</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.13">4.3.8</a>, <a href="#rfc.xref.Part1.25">7.4.2</a>, <a href="#rfc.xref.Part1.43">C</a></li>
                         <li><em>Section 6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.34">9.3.1</a></li>
@@ -5159 +5166 @@
                      </ul>
                   </li>
-                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.4</a>, <a href="#rfc.xref.Part4.2">3.4</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">5.2</a>, <a href="#rfc.xref.Part4.8">5.2</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.1</a>, <a href="#rfc.xref.Part4.11">6.1</a>, <a href="#rfc.xref.Part4.12">6.3.2</a>, <a href="#rfc.xref.Part4.13">6.4</a>, <a href="#Part4"><b>12.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul>
-                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">3.4</a></li>
-                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.4</a>, <a href="#rfc.xref.Part4.12">6.3.2</a></li>
+                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.2">3.3</a>, <a href="#rfc.xref.Part4.3">4.3.1</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">5.2</a>, <a href="#rfc.xref.Part4.8">5.2</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.1</a>, <a href="#rfc.xref.Part4.11">6.1</a>, <a href="#rfc.xref.Part4.12">6.3.2</a>, <a href="#rfc.xref.Part4.13">6.4</a>, <a href="#Part4"><b>12.1</b></a>, <a href="#rfc.xref.Part4.14">F.2</a><ul>
+                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.2">3.3</a></li>
+                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.3</a>, <a href="#rfc.xref.Part4.12">6.3.2</a></li>
                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">5.2</a></li>
                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">5.2</a></li>
@@ -5171 +5178 @@
                      </ul>
                   </li>
-                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1</a>, <a href="#rfc.xref.Part5.2">4.3.1</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a>, <a href="#rfc.xref.Part5.5">5.1</a>, <a href="#rfc.xref.Part5.6">5.2</a>, <a href="#rfc.xref.Part5.7">6.1</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">7.4</a>, <a href="#Part5"><b>12.1</b></a><ul>
+                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1.1</a>, <a href="#rfc.xref.Part5.2">4.3.1</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a>, <a href="#rfc.xref.Part5.5">5.1</a>, <a href="#rfc.xref.Part5.6">5.2</a>, <a href="#rfc.xref.Part5.7">6.1</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">7.4</a>, <a href="#Part5"><b>12.1</b></a><ul>
                         <li><em>Section 3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.7">6.1</a></li>
                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.8">6.1</a></li>
                         <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.9">6.1</a></li>
                         <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.10">7.4</a></li>
-                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a></li>
+                        <li><em>Section 5.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.1.1</a>, <a href="#rfc.xref.Part5.4">4.3.4</a></li>
                         <li><em>Section 5.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.6">5.2</a></li>
                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.5">5.1</a></li>
                      </ul>
                   </li>
-                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.3</a>, <a href="#rfc.xref.Part6.2">4.2.3</a>, <a href="#rfc.xref.Part6.3">4.3.1</a>, <a href="#rfc.xref.Part6.4">4.3.2</a>, <a href="#rfc.xref.Part6.5">4.3.3</a>, <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a>, <a href="#rfc.xref.Part6.8">6.3.1</a>, <a href="#rfc.xref.Part6.9">6.3.4</a>, <a href="#rfc.xref.Part6.10">6.3.4</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.4.1</a>, <a href="#rfc.xref.Part6.13">6.4.2</a>, <a href="#rfc.xref.Part6.14">6.5.9</a>, <a href="#rfc.xref.Part6.15">7.2</a>, <a href="#rfc.xref.Part6.16">7.2.2</a>, <a href="#rfc.xref.Part6.17">9.2.2</a>, <a href="#rfc.xref.Part6.18">9.3.1</a>, <a href="#Part6"><b>12.1</b></a><ul>
+                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.2</a>, <a href="#rfc.xref.Part6.2">4.2.3</a>, <a href="#rfc.xref.Part6.3">4.3.1</a>, <a href="#rfc.xref.Part6.4">4.3.2</a>, <a href="#rfc.xref.Part6.5">4.3.3</a>, <a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a>, <a href="#rfc.xref.Part6.8">6.3.1</a>, <a href="#rfc.xref.Part6.9">6.3.4</a>, <a href="#rfc.xref.Part6.10">6.3.4</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.4.1</a>, <a href="#rfc.xref.Part6.13">6.4.2</a>, <a href="#rfc.xref.Part6.14">6.5.9</a>, <a href="#rfc.xref.Part6.15">7.2</a>, <a href="#rfc.xref.Part6.16">7.2.2</a>, <a href="#rfc.xref.Part6.17">9.2.2</a>, <a href="#rfc.xref.Part6.18">9.3.1</a>, <a href="#Part6"><b>12.1</b></a><ul>
                         <li><em>Section 4.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.5">4.3.3</a></li>
                         <li><em>Section 4.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.8">6.3.1</a>, <a href="#rfc.xref.Part6.11">6.3.4</a>, <a href="#rfc.xref.Part6.12">6.4.1</a>, <a href="#rfc.xref.Part6.13">6.4.2</a>, <a href="#rfc.xref.Part6.14">6.5.9</a></li>
@@ -5189 +5196 @@
                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.15">7.2</a></li>
                         <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.9">6.3.4</a></li>
-                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.3</a></li>
+                        <li><em>Section 7.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">3.2</a></li>
                         <li><em>Section 7.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.10">6.3.4</a></li>
                      </ul>
@@ -5225 +5232 @@
                   <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">9.4.2</a>, <a href="#RFC1952"><b>12.1</b></a></li>
                   <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#RFC2045"><b>12.1</b></a>, <a href="#rfc.xref.RFC2045.1">A</a>, <a href="#rfc.xref.RFC2045.2">A.1</a></li>
-                  <li><em>RFC2046</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.5</a>, <a href="#rfc.xref.RFC2046.2">8.5</a>, <a href="#rfc.xref.RFC2046.3">8.5.2</a>, <a href="#RFC2046"><b>12.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul>
-                        <li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.5</a></li>
+                  <li><em>RFC2046</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.4</a>, <a href="#rfc.xref.RFC2046.2">8.5</a>, <a href="#rfc.xref.RFC2046.3">8.5.2</a>, <a href="#RFC2046"><b>12.1</b></a>, <a href="#rfc.xref.RFC2046.4">A.2</a><ul>
+                        <li><em>Section 4.5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.4</a></li>
                         <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.3">8.5.2</a></li>
                      </ul>
@@ -5242 +5249 @@
                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>12.1</b></a></li>
                   <li><em>RFC2277</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2277.1">8.3</a>, <a href="#RFC2277"><b>12.2</b></a></li>
-                  <li><em>RFC2295</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2295.1">3.6</a>, <a href="#RFC2295"><b>12.2</b></a></li>
+                  <li><em>RFC2295</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2295.1">3.5</a>, <a href="#RFC2295"><b>12.2</b></a></li>
                   <li><em>RFC2388</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2388.1">8.5.2</a>, <a href="#RFC2388"><b>12.2</b></a></li>
-                  <li><em>RFC2557</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.3.4</a>, <a href="#RFC2557"><b>12.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.6</a><ul>
-                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.3.4</a></li>
+                  <li><em>RFC2557</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.2.4</a>, <a href="#RFC2557"><b>12.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.6</a><ul>
+                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2557.1">3.2.4</a></li>
                      </ul>
                   </li>
@@ -5301 +5308 @@
             <li><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul>
                   <li>safe&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>4.2.1</b></a></li>
-                  <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3.4</b></a></li>
+                  <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>3.3</b></a></li>
                   <li>Server header field&nbsp;&nbsp;<a href="#rfc.xref.header.server.1">7.4</a>, <a href="#rfc.iref.s.8"><b>7.4.2</b></a>, <a href="#rfc.xref.header.server.2">9.3.2</a>, <a href="#rfc.xref.header.server.3">10.1</a>, <a href="#rfc.xref.header.server.4">C</a></li>
                   <li>Status Codes Classes&nbsp;&nbsp;
@@ -5320 +5327 @@
             </li>
             <li><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul>
-                  <li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.6.1</a>, <a href="#rfc.xref.header.user-agent.2">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.3">9.3.2</a>, <a href="#rfc.xref.header.user-agent.4">10.1</a></li>
+                  <li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.5.1</a>, <a href="#rfc.xref.header.user-agent.2">5.5</a>, <a href="#rfc.iref.u.1"><b>5.5.3</b></a>, <a href="#rfc.xref.header.user-agent.3">9.3.2</a>, <a href="#rfc.xref.header.user-agent.4">10.1</a></li>
                </ul>
             </li>
             <li><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul>
-                  <li>Vary header field&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">3.6.1</a>, <a href="#rfc.xref.header.vary.2">7.2</a>, <a href="#rfc.iref.v.1"><b>7.2.2</b></a>, <a href="#rfc.xref.header.vary.3">9.3.2</a></li>
+                  <li>Vary header field&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">3.5.1</a>, <a href="#rfc.xref.header.vary.2">7.2</a>, <a href="#rfc.iref.v.1"><b>7.2.2</b></a>, <a href="#rfc.xref.header.vary.3">9.3.2</a></li>
                </ul>
             </li>

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

@@ -339 +339 @@
    for resolving it.
 </t>
+
+<section title="Payload Header Fields" anchor="payload.header.fields">
 <t>
    Header fields that specifically describe the payload, rather than the
@@ -355 +357 @@
 </section>
 
-<section title="Associating a Representation with its Resource" anchor="associating.representation.with.resource">
-<t>
-   It is sometimes necessary to determine an identifier for the resource
-   associated with a representation.
-</t>
-<t>
-   An HTTP request representation, when present, is always associated with an
-   anonymous (i.e., unidentified) resource.
-</t>
-<t>
-   In the common case, an HTTP response is a representation of the target
-   resource (see &effective-request-uri;). However, this is not always the
-   case. To determine the URI of the resource a response is associated with,
-   the following rules are used (with the first applicable one being selected):
-</t>
-<t><list style="numbers">
-   <t>If the response status code is <x:ref>200 (OK)</x:ref> or <x:ref>203
-   (Non-Authoritative Information)</x:ref> and the request method was GET,
-   the response payload is a representation of the target resource.</t>
-   <t>If the response status code is <x:ref>204 (No Content)</x:ref>,
-   <x:ref>206 (Partial Content)</x:ref>, or <x:ref>304 (Not Modified)</x:ref>
-   and the request method was GET or HEAD, the response payload is a partial
-   representation of the target resource.</t>
-   <t>If the response has a <x:ref>Content-Location</x:ref> header field, and
-   that URI is the same as the effective request URI, the response payload is a
-   representation of the target resource.</t>
-   <t>If the response has a <x:ref>Content-Location</x:ref> header field, and
-   that URI is not the same as the effective request URI, then the response
-   asserts that its payload is a representation of the resource identified by
-   the Content-Location URI. However, such an assertion cannot be trusted unless
-   it can be verified by other means (not defined by HTTP).</t>
-   <t>Otherwise, the response is a representation of an anonymous (i.e.,
-   unidentified) resource.</t>
-</list></t>
-<t>
-  <cref anchor="TODO-req-uri">
-   The comparison function is going to have to be defined somewhere,
-   because we already need to compare URIs for things like cache invalidation.</cref>
-</t>
+<section title="Identifying the Payload" anchor="identifying.payload">
+<t>
+   When a complete or partial representation is transferred in a message
+   payload, it is often desirable for the sender to supply, or the recipient
+   to determine, an identifier for the resource corresponding to that
+   representation.
+</t>
+<t>
+   The following rules are used to determine such a URI for the payload of a
+   request message:
+   <list style="symbols">
+      <t>If the request has a <x:ref>Content-Location</x:ref> header field,
+         then the sender asserts that the payload is a representation of the
+         resource identified by the Content-Location field-value. However,
+         such an assertion cannot be trusted unless it can be verified by
+         other means (not defined by HTTP). The information might still be
+         useful for revision history links.</t>
+      <t>Otherwise, the payload is unidentified.</t>
+   </list>
+</t>
+<t>
+   The following rules, to be applied in order until a match is found, are
+   used to determine such a URI for the payload of a response message:
+   <list style="numbers">
+      <t>If the request is GET or HEAD and the response status code is
+         <x:ref>200 (OK)</x:ref>, 
+         <x:ref>204 (No Content)</x:ref>,
+         <x:ref>206 (Partial Content)</x:ref>, or
+         <x:ref>304 (Not Modified)</x:ref>,
+         the payload's identifier is the effective request URI
+         (&effective-request-uri;).</t>
+      <t>If the request is GET or HEAD and the response status code is
+         <x:ref>203 (Non-Authoritative Information)</x:ref>, the payload is a
+         potentially modified representation of the target resource; as such,
+         the effective request URI might only act as an identifier for the
+         payload's representation when a request is made via the same chain
+         of intermediaries.</t>
+      <t>If the response has a <x:ref>Content-Location</x:ref> header field
+         and its field-value is a reference to the same URI as the effective
+         request URI, the payload's identifier is the effective request URI.</t>
+      <t>If the response has a <x:ref>Content-Location</x:ref> header field
+         and its field-value is a reference to a URI different from the
+         effective request URI, then the sender asserts that the payload is a
+         representation of the resource identified by the Content-Location
+         field-value. However, such an assertion cannot be trusted unless
+         it can be verified by other means (not defined by HTTP).</t>
+      <t>Otherwise, the payload is unidentified.</t>
+   </list>
+</t>
+</section>
 </section>
 
@@ -4125 +4138 @@
 <section title="Considerations for New Status Codes" anchor="considerations.for.new.status.codes">
 <t>
-   When it is necessary to express new semantics for a HTTP response that
-   aren't specific to a single application or media type, and currently defined
-   status codes are inadequate, a new status code can be registered.
-</t>
-<t>
-   HTTP status codes are generic; that is, they are potentially applicable to
+   When it is necessary to express semantics for a response that are not
+   defined by current status codes, a new status code can be registered.
+   HTTP status codes are generic; they are potentially applicable to
    any resource, not just one particular media type, "type" of resource, or
-   application. As such, it is preferred that new HTTP status codes be
-   registered in a document that isn't specific to a single application, so
-   that this is clear.
-</t>
-<t>
-   Definitions of new HTTP status codes typically explain the request
-   conditions that produce a response containing the status code (e.g.,
-   combinations of request header fields and/or method(s)), along with any 
-   interactions with response header fields (e.g., those that are required,
-   those that modify the semantics of the response).
-</t>
-<t>
-   New HTTP status codes are required to fall under one of the categories
+   application. As such, it is preferred that new status codes be
+   registered in a document that isn't specific to a single application.
+</t>
+<t>
+   New status codes are required to fall under one of the categories
    defined in <xref target="status.codes"/>. To allow existing parsers to
    properly handle them, new status codes cannot disallow a response body,
-   although they can mandate a zero-length response body. They can require the
-   presence of one or more particular HTTP response header field(s).
-</t>
-<t>
-   Likewise, their definitions can specify that caches are allowed to use
-   heuristics to determine their freshness (see &caching;; by default, it is
-   not allowed), and can define how to determine the resource which they
-   carry a representation for (see <xref
-   target="associating.representation.with.resource"/>; by default,
-   it is anonymous).
+   although they can mandate a zero-length response body.
+</t>
+<t>
+   A definition for a new status code ought to explain the request
+   conditions that produce a response containing that status code (e.g.,
+   combinations of request header fields and/or method(s)) along with any 
+   dependencies on response header fields (e.g., what fields are required
+   and what fields can modify the semantics). A response that can transfer a
+   payload ought to specify expected cache behavior (e.g., cacheability and
+   freshness criteria, as described in &caching;) and whether the payload has
+   any implied association with an identified resource
+   (<xref target="identifying.payload"/>).
 </t>
 </section>