Changeset 1920

Timestamp:

01/10/12 01:14:48 (10 years ago)

Author:

fielding@…

Message:

(editorial) move selected representation fields to response header fields

Location:

draft-ietf-httpbis/latest

Files:

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

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

@@ -587 +587 @@
                   </ul>
                </li>
-               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#selected.representation">Selected Representation Header Fields</a></li>
-               <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
-               <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#payload">Message Payload</a><ul>
-                     <li><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#payload.header.fields">Payload Header Fields</a></li>
-                     <li><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#identifying.payload">Identifying the Payload</a></li>
+               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
+               <li><a href="#rfc.section.3.3">3.3</a>&nbsp;&nbsp;&nbsp;<a href="#payload">Message Payload</a><ul>
+                     <li><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#payload.header.fields">Payload Header Fields</a></li>
+                     <li><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#identifying.payload">Identifying the Payload</a></li>
                   </ul>
                </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>
+               <li><a href="#rfc.section.3.4">3.4</a>&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul>
+                     <li><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;&nbsp;&nbsp;<a href="#proactive.negotiation">Proactive Negotiation</a></li>
+                     <li><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;&nbsp;&nbsp;<a href="#reactive.negotiation">Reactive Negotiation</a></li>
                   </ul>
                </li>
@@ -706 +705 @@
          <li><a href="#rfc.section.7">7.</a>&nbsp;&nbsp;&nbsp;<a href="#response.header.fields">Response Header Fields</a><ul>
                <li><a href="#rfc.section.7.1">7.1</a>&nbsp;&nbsp;&nbsp;<a href="#response.control.data">Control Data</a><ul>
-                     <li><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.location">Location</a></li>
-                     <li><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.retry-after">Retry-After</a></li>
+                     <li><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.date">Date</a></li>
+                     <li><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.location">Location</a></li>
+                     <li><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;&nbsp;&nbsp;<a href="#header.retry-after">Retry-After</a></li>
                   </ul>
                </li>
-               <li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#response.cache.related">Cache-related</a><ul>
-                     <li><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.date">Date</a></li>
-                     <li><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#header.vary">Vary</a></li>
+               <li><a href="#rfc.section.7.2">7.2</a>&nbsp;&nbsp;&nbsp;<a href="#selected.representation">Selected Representation Header Fields</a><ul>
+                     <li><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#header.vary">Vary</a></li>
                   </ul>
                </li>
@@ -926 +925 @@
       </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.1.1.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;3.3</a>.
+</pre><p id="rfc.section.3.1.1.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;3.2</a>.
       </p>
       <div id="rfc.iref.c.3"></div>
@@ -1019 +1018 @@
       </p>
       <p id="rfc.section.3.1.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.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2>
-      <p id="rfc.section.3.2.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.2.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:
-      </p>
-      <div id="rfc.table.u.2">
-         <table class="tt full left" cellpadding="3" cellspacing="0">
-            <thead>
-               <tr>
-                  <th>Header Field Name</th>
-                  <th>Defined in...</th>
-               </tr>
-            </thead>
-            <tbody>
-               <tr>
-                  <td class="left">ETag</td>
-                  <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
-               </tr>
-               <tr>
-                  <td class="left">Last-Modified</td>
-                  <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
-               </tr>
-            </tbody>
-         </table>
-      </div>
-      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
-      <p id="rfc.section.3.3.p.1">The representation data associated with an HTTP message is either provided as the payload body of the message or referred
+      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
+      <p id="rfc.section.3.2.p.1">The representation data 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.3.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.2.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.3.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.2.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.3.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.2.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 payload's content and override the specified type.
          Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation").
@@ -1067 +1038 @@
          sniffing" when it is used.
       </p>
-      <p id="rfc.section.3.3.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.2.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>
       <div id="rfc.iref.p.1"></div>
-      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="payload" href="#payload">Message Payload</a></h2>
-      <p id="rfc.section.3.4.p.1">Some HTTP messages transfer a complete or partial representation as the message "<dfn>payload</dfn>". In some cases, a payload might only contain the associated representation's header fields (e.g., responses to HEAD) or
+      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="payload" href="#payload">Message Payload</a></h2>
+      <p id="rfc.section.3.3.p.1">Some HTTP messages transfer a complete or partial representation as the message "<dfn>payload</dfn>". In some cases, a payload might only contain the associated representation's header fields (e.g., responses to HEAD) or
          only some part(s) of the representation data (e.g., the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code).
       </p>
-      <p id="rfc.section.3.4.p.2">The purpose of a payload in a request is defined by the method semantics. In a response, the payload's purpose is defined
+      <p id="rfc.section.3.3.p.2">The purpose of a payload in a request is defined by the method semantics. In a response, the payload's purpose is defined
          by both the request method and the response status code.
       </p>
-      <p id="rfc.section.3.4.p.3">For example, a representation in the payload of a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the target resource if the request is successfully applied, whereas a representation in
+      <p id="rfc.section.3.3.p.3">For example, a representation in the payload of a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the target resource if the request is successfully applied, whereas a representation in
          the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>) represents an anonymous resource for providing data to be processed, such as the information that a user entered within
          an HTML form.
       </p>
-      <p id="rfc.section.3.4.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) contains a representation of the target resource, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.2.1</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a
+      <p id="rfc.section.3.3.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) contains a representation of the target resource, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.1.1</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a
          current representation of the target resource after applying the processing. Response messages with an error status code usually
          contain a representation that describes the error and what next steps are suggested for resolving it.
       </p>
-      <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h3>
-      <p id="rfc.section.3.4.1.p.1">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload
+      <h3 id="rfc.section.3.3.1"><a href="#rfc.section.3.3.1">3.3.1</a>&nbsp;<a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h3>
+      <p id="rfc.section.3.3.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>
-      <div id="rfc.table.u.3">
+      <div id="rfc.table.u.2">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -1115 +1086 @@
          </table>
       </div>
-      <h3 id="rfc.section.3.4.2"><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;<a id="identifying.payload" href="#identifying.payload">Identifying the Payload</a></h3>
-      <p id="rfc.section.3.4.2.p.1">When a complete or partial representation is transferred in a message payload, it is often desirable for the sender to supply,
+      <h3 id="rfc.section.3.3.2"><a href="#rfc.section.3.3.2">3.3.2</a>&nbsp;<a id="identifying.payload" href="#identifying.payload">Identifying the Payload</a></h3>
+      <p id="rfc.section.3.3.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.4.2.p.2">The following rules are used to determine such a URI for the payload of a request message: </p>
+      <p id="rfc.section.3.3.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
@@ -1127 +1098 @@
          <li>Otherwise, the payload is unidentified.</li>
       </ul>
-      <p id="rfc.section.3.4.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
+      <p id="rfc.section.3.3.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>
@@ -1145 +1116 @@
          <li>Otherwise, the payload is unidentified.</li>
       </ol>
-      <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
+      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2>
+      <p id="rfc.section.3.4.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.5.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
+      <p id="rfc.section.3.4.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.5.p.3">This specification defines two patterns of content negotiation; "proactive", where the server selects the representation based
+      <p id="rfc.section.3.4.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
@@ -1161 +1132 @@
          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.5.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.4.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.5.p.5">Note that, in all cases, the supplier of representations has the responsibility for determining which representations might
+      <p id="rfc.section.3.4.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.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
+      <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>
+      <p id="rfc.section.3.4.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.5.1.p.2">Proactive negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
+      <p id="rfc.section.3.4.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.5.1.p.3">Proactive negotiation has disadvantages: </p>
+      <p id="rfc.section.3.4.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
@@ -1192 +1163 @@
          <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.5.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.4.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.5.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.4.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.5.1.p.6"> 
+      <div class="note" id="rfc.section.3.4.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.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
+      <p id="rfc.section.3.4.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.1</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.4.2"><a href="#rfc.section.3.4.2">3.4.2</a>&nbsp;<a id="reactive.negotiation" href="#reactive.negotiation">Reactive Negotiation</a></h3>
+      <p id="rfc.section.3.4.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
@@ -1214 +1185 @@
          user selecting from a generated (possibly hypertext) menu.
       </p>
-      <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
+      <p id="rfc.section.3.4.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.5.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.4.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.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
+      <p id="rfc.section.3.4.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>
@@ -1308 +1279 @@
       </p>
       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="method.properties" href="#method.properties">Common Method Properties</a></h2>
-      <div id="rfc.iref.s.2"></div>
+      <div id="rfc.iref.s.1"></div>
       <h3 id="rfc.section.4.2.1"><a href="#rfc.section.4.2.1">4.2.1</a>&nbsp;<a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
       <p id="rfc.section.4.2.1.p.1">Request methods are considered "<dfn id="safe">safe</dfn>" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state
@@ -1365 +1336 @@
          in the response and not the source text of the process, unless that text happens to be the output of the process.
       </p>
-      <p id="rfc.section.4.3.1.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
+      <p id="rfc.section.4.3.1.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
          header field(s). The conditional GET request is intended to reduce unnecessary network usage by allowing cached representations
          to be refreshed without requiring multiple requests or transferring data already held by the client.
@@ -1407 +1378 @@
          the result.
       </p>
-      <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 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.2</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.1.4</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD (not POST) requests.
@@ -1572 +1543 @@
       <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="request.controls" href="#request.controls">Controls</a></h2>
       <p id="rfc.section.5.1.p.1">Controls are request header fields that direct specific handling of the request.</p>
-      <div id="rfc.table.u.4">
+      <div id="rfc.table.u.3">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -1626 +1597 @@
       </p>
       <p id="rfc.section.5.1.2.p.4">The only expectation defined by this specification is:</p>
-      <p id="rfc.section.5.1.2.p.5"><span id="rfc.iref.32"></span><span id="rfc.iref.e.2"></span> 100-continue 
+      <p id="rfc.section.5.1.2.p.5"><span id="rfc.iref.31"></span><span id="rfc.iref.e.2"></span> 100-continue 
       </p>
       <ul class="empty">
@@ -1688 +1659 @@
       <p id="rfc.section.5.2.p.1">Conditionals are request header fields that indicate a precondition to be tested before applying the method semantics to the
          target resource. Each precondition is based on metadata that is expected to change if the selected representation of the target
-         resource is changed. The HTTP/1.1 conditional request mechanisms are defined in <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
-      </p>
-      <div id="rfc.table.u.5">
+         resource is changed. The HTTP/1.1 conditional request mechanisms are defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
+      </p>
+      <div id="rfc.table.u.4">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -1701 +1672 @@
                <tr>
                   <td class="left">If-Match</td>
-                  <td class="left"><a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
+                  <td class="left"><a href="p4-conditional.html#header.if-match" title="If-Match">Section 3.1</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
                </tr>
                <tr>
                   <td class="left">If-None-Match</td>
-                  <td class="left"><a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
+                  <td class="left"><a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 3.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
                </tr>
                <tr>
                   <td class="left">If-Modified-Since</td>
-                  <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
+                  <td class="left"><a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 3.3</a> of <a href="#Part4" id="rfc.xref.Part4.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
                </tr>
                <tr>
                   <td class="left">If-Unmodified-Since</td>
-                  <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
+                  <td class="left"><a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 3.4</a> of <a href="#Part4" id="rfc.xref.Part4.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
                </tr>
                <tr>
@@ -1723 +1694 @@
       </div>
       <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="request.conneg" href="#request.conneg">Content Negotiation</a></h2>
-      <div id="rfc.table.u.6">
+      <div id="rfc.table.u.5">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -1824 +1795 @@
           text/html;level=2;q=0.4, */*;q=0.5
 </pre><p id="rfc.section.5.3.2.p.18">would cause the following values to be associated:</p>
-      <div id="rfc.table.u.7">
+      <div id="rfc.table.u.6">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -1955 +1926 @@
       </div>
       <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="request.auth" href="#request.auth">Authentication</a></h2>
-      <div id="rfc.table.u.8">
+      <div id="rfc.table.u.7">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -1976 +1947 @@
       </div>
       <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="request.context" href="#request.context">Context</a></h2>
-      <div id="rfc.table.u.9">
+      <div id="rfc.table.u.8">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -2089 +2060 @@
       </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>
-      <p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
+      <p id="rfc.section.6.1.p.1">The status codes listed below are defined in this specification, <a href="p4-conditional.html#status.code.definitions" title="Status Code Definitions">Section 4</a> of <a href="#Part4" id="rfc.xref.Part4.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>, <a href="p5-range.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part5" id="rfc.xref.Part5.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>, and <a href="p7-auth.html#status.code.definitions" title="Status Code Definitions">Section 3</a> of <a href="#Part7" id="rfc.xref.Part7.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a>. The reason phrases listed here are only recommendations — they can be replaced by local equivalents without affecting the
          protocol.
       </p>
-      <div id="rfc.table.u.10">
+      <div id="rfc.table.u.9">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -2170 +2141 @@
                   <td class="left">304</td>
                   <td class="left">Not Modified</td>
-                  <td id="status.304" class="left"><a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
+                  <td id="status.304" class="left"><a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
                </tr>
                <tr>
@@ -2245 +2216 @@
                   <td class="left">412</td>
                   <td class="left">Precondition Failed</td>
-                  <td id="status.412" class="left"><a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
+                  <td id="status.412" class="left"><a href="p4-conditional.html#status.412" title="412 Precondition Failed">Section 4.2</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
                </tr>
                <tr>
@@ -2312 +2283 @@
       <p id="rfc.section.6.1.p.2">Note that this list is not exhaustive — it does not include extension status codes defined in other specifications.</p>
       <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="status.1xx" href="#status.1xx">Informational 1xx</a></h2>
-      <div id="rfc.iref.54"></div>
-      <div id="rfc.iref.s.3"></div>
+      <div id="rfc.iref.53"></div>
+      <div id="rfc.iref.s.2"></div>
       <p id="rfc.section.6.2.p.1">This class of status code indicates a provisional response, consisting only of the status-line and optional header fields,
          and is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did
@@ -2325 +2296 @@
          a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).)
       </p>
-      <div id="rfc.iref.55"></div>
+      <div id="rfc.iref.54"></div>
       <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="status.100" href="#status.100">100 Continue</a></h3>
       <p id="rfc.section.6.2.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been
@@ -2331 +2302 @@
          server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section&nbsp;5.1.2.1</a> for detailed discussion of the use and handling of this status code.
       </p>
-      <div id="rfc.iref.55"></div>
+      <div id="rfc.iref.54"></div>
       <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
       <p id="rfc.section.6.2.2.p.1">The server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
@@ -2341 +2312 @@
       </p>
       <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="status.2xx" href="#status.2xx">Successful 2xx</a></h2>
+      <div id="rfc.iref.54"></div>
+      <div id="rfc.iref.s.3"></div>
+      <p id="rfc.section.6.3.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>
       <div id="rfc.iref.55"></div>
-      <div id="rfc.iref.s.4"></div>
-      <p id="rfc.section.6.3.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>
-      <div id="rfc.iref.56"></div>
       <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="status.200" href="#status.200">200 OK</a></h3>
       <p id="rfc.section.6.3.1.p.1">The request has succeeded. The payload returned with the response is dependent on the method used in the request, for example: </p>
@@ -2359 +2330 @@
       <p id="rfc.section.6.3.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 200 responses.
       </p>
-      <div id="rfc.iref.56"></div>
+      <div id="rfc.iref.55"></div>
       <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="status.201" href="#status.201">201 Created</a></h3>
       <p id="rfc.section.6.3.2.p.1">The request has been fulfilled and has resulted in one or more new resources being created.</p>
@@ -2369 +2340 @@
       </p>
       <p id="rfc.section.6.3.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by
-         the <a href="#header.location" class="smpl">Location</a> header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>).
-      </p>
-      <div id="rfc.iref.56"></div>
+         the <a href="#header.location" class="smpl">Location</a> header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>).
+      </p>
+      <div id="rfc.iref.55"></div>
       <h3 id="rfc.section.6.3.3"><a href="#rfc.section.6.3.3">6.3.3</a>&nbsp;<a id="status.202" href="#status.202">202 Accepted</a></h3>
       <p id="rfc.section.6.3.3.p.1">The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually
@@ -2382 +2353 @@
          user can expect the request to be fulfilled.
       </p>
-      <div id="rfc.iref.56"></div>
+      <div id="rfc.iref.55"></div>
       <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
       <p id="rfc.section.6.3.4.p.1">The representation in the response has been transformed or otherwise modified by a transforming proxy (<a href="p1-messaging.html#intermediaries" title="Intermediaries">Section 2.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). Note that the behavior of transforming intermediaries is controlled by the no-transform Cache-Control directive (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
@@ -2391 +2362 @@
       <p id="rfc.section.6.3.4.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 203 responses.
       </p>
-      <div id="rfc.iref.56"></div>
+      <div id="rfc.iref.55"></div>
       <h3 id="rfc.section.6.3.5"><a href="#rfc.section.6.3.5">6.3.5</a>&nbsp;<a id="status.204" href="#status.204">204 No Content</a></h3>
       <p id="rfc.section.6.3.5.p.1">The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional
@@ -2411 +2382 @@
       <p id="rfc.section.6.3.5.p.5">The 204 response <em class="bcp14">MUST NOT</em> include a message body, and thus is always terminated by the first empty line after the header fields.
       </p>
-      <div id="rfc.iref.56"></div>
+      <div id="rfc.iref.55"></div>
       <h3 id="rfc.section.6.3.6"><a href="#rfc.section.6.3.6">6.3.6</a>&nbsp;<a id="status.205" href="#status.205">205 Reset Content</a></h3>
       <p id="rfc.section.6.3.6.p.1">The server has fulfilled the request and the user agent <em class="bcp14">SHOULD</em> reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions
@@ -2420 +2391 @@
       </p>
       <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="status.3xx" href="#status.3xx">Redirection 3xx</a></h2>
-      <div id="rfc.iref.56"></div>
-      <div id="rfc.iref.s.5"></div>
+      <div id="rfc.iref.55"></div>
+      <div id="rfc.iref.s.4"></div>
       <p id="rfc.section.6.4.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.
          If the required action involves a subsequent HTTP request, it <em class="bcp14">MAY</em> be carried out by the user agent without interaction with the user if and only if the method used in the second request is
@@ -2440 +2411 @@
          </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.5.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.4.2</a>). This is status code <a href="#status.300" class="smpl">300 (Multiple Choices)</a>.
             </p>
          </li>
          <li>
             <p>Other kinds of redirection, such as to a cached result (status code <a href="p4-conditional.html#status.304" class="smpl">304
-                  (Not Modified)</a>, see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>).
+                  (Not Modified)</a>, see <a href="p4-conditional.html#status.304" title="304 Not Modified">Section 4.1</a> of <a href="#Part4" id="rfc.xref.Part4.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>).
             </p>
          </li>
@@ -2455 +2426 @@
          </p> 
       </div>
-      <p id="rfc.section.6.4.p.4">A <a href="#header.location" class="smpl">Location</a> header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;7.1.1</a>.
+      <p id="rfc.section.6.4.p.4">A <a href="#header.location" class="smpl">Location</a> header field on a 3xx response indicates that a client <em class="bcp14">MAY</em> automatically redirect to the URI provided; see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;7.1.2</a>.
       </p>
       <p id="rfc.section.6.4.p.5">Note that for methods not known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>, automatic redirection needs to done with care, since the redirect might change the conditions under which the request was
@@ -2466 +2437 @@
          </p> 
       </div>
-      <div id="rfc.iref.57"></div>
+      <div id="rfc.iref.56"></div>
       <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.5</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.4</a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
          location.
       </p>
@@ -2480 +2451 @@
       <p id="rfc.section.6.4.1.p.4">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 300 responses.
       </p>
-      <div id="rfc.iref.57"></div>
+      <div id="rfc.iref.56"></div>
       <h3 id="rfc.section.6.4.2"><a href="#rfc.section.6.4.2">6.4.2</a>&nbsp;<a id="status.301" href="#status.301">301 Moved Permanently</a></h3>
       <p id="rfc.section.6.4.2.p.1">The target resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the effective
@@ -2493 +2464 @@
          </p> 
       </div>
-      <div id="rfc.iref.57"></div>
+      <div id="rfc.iref.56"></div>
       <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a>&nbsp;<a id="status.302" href="#status.302">302 Found</a></h3>
       <p id="rfc.section.6.4.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
@@ -2503 +2474 @@
          </p> 
       </div>
-      <div id="rfc.iref.57"></div>
+      <div id="rfc.iref.56"></div>
       <h3 id="rfc.section.6.4.4"><a href="#rfc.section.6.4.4">6.4.4</a>&nbsp;<a id="status.303" href="#status.303">303 See Other</a></h3>
       <p id="rfc.section.6.4.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI
@@ -2523 +2494 @@
       <p id="rfc.section.6.4.4.p.4">Except for responses to a HEAD request, the representation of a 303 response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the <a href="#header.location" class="smpl">Location</a> URI.
       </p>
-      <div id="rfc.iref.57"></div>
+      <div id="rfc.iref.56"></div>
       <h3 id="rfc.section.6.4.5"><a href="#rfc.section.6.4.5">6.4.5</a>&nbsp;<a id="status.305" href="#status.305">305 Use Proxy</a></h3>
       <p id="rfc.section.6.4.5.p.1">The 305 status code was defined in a previous version of this specification (see <a href="#changes.from.rfc.2616" title="Changes from RFC 2616">Appendix&nbsp;C</a>), and is now deprecated.
       </p>
-      <div id="rfc.iref.57"></div>
+      <div id="rfc.iref.56"></div>
       <h3 id="rfc.section.6.4.6"><a href="#rfc.section.6.4.6">6.4.6</a>&nbsp;<a id="status.306" href="#status.306">306 (Unused)</a></h3>
       <p id="rfc.section.6.4.6.p.1">The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.</p>
-      <div id="rfc.iref.57"></div>
+      <div id="rfc.iref.56"></div>
       <h3 id="rfc.section.6.4.7"><a href="#rfc.section.6.4.7">6.4.7</a>&nbsp;<a id="status.307" href="#status.307">307 Temporary Redirect</a></h3>
       <p id="rfc.section.6.4.7.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
@@ -2543 +2514 @@
       </div>
       <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="status.4xx" href="#status.4xx">Client Error 4xx</a></h2>
-      <div id="rfc.iref.57"></div>
-      <div id="rfc.iref.s.6"></div>
+      <div id="rfc.iref.56"></div>
+      <div id="rfc.iref.s.5"></div>
       <p id="rfc.section.6.5.p.1">The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD
          request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
          These status codes are applicable to any request method. User agents <em class="bcp14">SHOULD</em> display any included representation to the user.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.1"><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;<a id="status.400" href="#status.400">400 Bad Request</a></h3>
       <p id="rfc.section.6.5.1.p.1">The server cannot or will not process the request, due to a client error (e.g., malformed syntax).</p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.2"><a href="#rfc.section.6.5.2">6.5.2</a>&nbsp;<a id="status.402" href="#status.402">402 Payment Required</a></h3>
       <p id="rfc.section.6.5.2.p.1">This code is reserved for future use.</p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.3"><a href="#rfc.section.6.5.3">6.5.3</a>&nbsp;<a id="status.403" href="#status.403">403 Forbidden</a></h3>
       <p id="rfc.section.6.5.3.p.1">The server understood the request, but refuses to authorize it. Providing different user authentication credentials might
@@ -2564 +2535 @@
             (Not Found)</a>  <em class="bcp14">MAY</em> be used instead.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.4"><a href="#rfc.section.6.5.4">6.5.4</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
       <p id="rfc.section.6.5.4.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary
@@ -2571 +2542 @@
          has been refused, or when no other response is applicable.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.5"><a href="#rfc.section.6.5.5">6.5.5</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
       <p id="rfc.section.6.5.5.p.1">The method specified in the request-line is not allowed for the target resource. The response <em class="bcp14">MUST</em> include an <a href="#header.allow" class="smpl">Allow</a> header field containing a list of valid methods for the requested resource.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.6"><a href="#rfc.section.6.5.6">6.5.6</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h3>
       <p id="rfc.section.6.5.6.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics
@@ -2592 +2563 @@
       <p id="rfc.section.6.5.6.p.4">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.7"><a href="#rfc.section.6.5.7">6.5.7</a>&nbsp;<a id="status.408" href="#status.408">408 Request Timeout</a></h3>
       <p id="rfc.section.6.5.7.p.1">The client did not produce a request within the time that the server was prepared to wait. The client <em class="bcp14">MAY</em> repeat the request without modifications at any later time.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.8"><a href="#rfc.section.6.5.8">6.5.8</a>&nbsp;<a id="status.409" href="#status.409">409 Conflict</a></h3>
       <p id="rfc.section.6.5.8.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in
@@ -2607 +2578 @@
          contain a list of the differences between the two versions.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.9"><a href="#rfc.section.6.5.9">6.5.9</a>&nbsp;<a id="status.410" href="#status.410">410 Gone</a></h3>
       <p id="rfc.section.6.5.9.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to
@@ -2621 +2592 @@
       <p id="rfc.section.6.5.9.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 410 responses.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.10"><a href="#rfc.section.6.5.10">6.5.10</a>&nbsp;<a id="status.411" href="#status.411">411 Length Required</a></h3>
       <p id="rfc.section.6.5.10.p.1">The server refuses to accept the request without a defined <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>. The client <em class="bcp14">MAY</em> repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request
          message.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.11"><a href="#rfc.section.6.5.11">6.5.11</a>&nbsp;<a id="status.413" href="#status.413">413 Request Representation Too Large</a></h3>
       <p id="rfc.section.6.5.11.p.1">The server is refusing to process a request because the request representation is larger than the server is willing or able
@@ -2633 +2604 @@
       <p id="rfc.section.6.5.11.p.2">If the condition is temporary, the server <em class="bcp14">SHOULD</em> include a <a href="#header.retry-after" class="smpl">Retry-After</a> header field to indicate that it is temporary and after what time the client <em class="bcp14">MAY</em> try again.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.12"><a href="#rfc.section.6.5.12">6.5.12</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h3>
       <p id="rfc.section.6.5.12.p.1">The server is refusing to service the request because the effective request URI is longer than the server is willing to interpret.
@@ -2641 +2612 @@
          in some servers using fixed-length buffers for reading or manipulating the request-target.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.13"><a href="#rfc.section.6.5.13">6.5.13</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
       <p id="rfc.section.6.5.13.p.1">The server is refusing to service the request because the request payload is in a format not supported by this request method
          on the target resource.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.14"><a href="#rfc.section.6.5.14">6.5.14</a>&nbsp;<a id="status.417" href="#status.417">417 Expectation Failed</a></h3>
       <p id="rfc.section.6.5.14.p.1">The expectation given in an <a href="#header.expect" class="smpl">Expect</a> header field (see <a href="#header.expect" id="rfc.xref.header.expect.2" title="Expect">Section&nbsp;5.1.2</a>) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could
          not be met by the next-hop server.
       </p>
-      <div id="rfc.iref.58"></div>
+      <div id="rfc.iref.57"></div>
       <h3 id="rfc.section.6.5.15"><a href="#rfc.section.6.5.15">6.5.15</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
       <p id="rfc.section.6.5.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) specifying the required protocols.
@@ -2667 +2638 @@
       </p>
       <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="status.5xx" href="#status.5xx">Server Error 5xx</a></h2>
-      <div id="rfc.iref.58"></div>
-      <div id="rfc.iref.s.7"></div>
+      <div id="rfc.iref.57"></div>
+      <div id="rfc.iref.s.6"></div>
       <p id="rfc.section.6.6.p.1">Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable
          of performing the request. Except when responding to a HEAD request, the server <em class="bcp14">SHOULD</em> include a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.
          User agents <em class="bcp14">SHOULD</em> display any included representation to the user. These response codes are applicable to any request method.
       </p>
-      <div id="rfc.iref.59"></div>
+      <div id="rfc.iref.58"></div>
       <h3 id="rfc.section.6.6.1"><a href="#rfc.section.6.6.1">6.6.1</a>&nbsp;<a id="status.500" href="#status.500">500 Internal Server Error</a></h3>
       <p id="rfc.section.6.6.1.p.1">The server encountered an unexpected condition which prevented it from fulfilling the request.</p>
-      <div id="rfc.iref.59"></div>
+      <div id="rfc.iref.58"></div>
       <h3 id="rfc.section.6.6.2"><a href="#rfc.section.6.6.2">6.6.2</a>&nbsp;<a id="status.501" href="#status.501">501 Not Implemented</a></h3>
       <p id="rfc.section.6.6.2.p.1">The server does not support the functionality required to fulfill the request. This is the appropriate response when the server
          does not recognize the request method and is not capable of supporting it for any resource.
       </p>
-      <div id="rfc.iref.59"></div>
+      <div id="rfc.iref.58"></div>
       <h3 id="rfc.section.6.6.3"><a href="#rfc.section.6.6.3">6.6.3</a>&nbsp;<a id="status.502" href="#status.502">502 Bad Gateway</a></h3>
       <p id="rfc.section.6.6.3.p.1">The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting
          to fulfill the request.
       </p>
-      <div id="rfc.iref.59"></div>
+      <div id="rfc.iref.58"></div>
       <h3 id="rfc.section.6.6.4"><a href="#rfc.section.6.6.4">6.6.4</a>&nbsp;<a id="status.503" href="#status.503">503 Service Unavailable</a></h3>
       <p id="rfc.section.6.6.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server.</p>
       <p id="rfc.section.6.6.4.p.2">The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the
-         delay <em class="bcp14">MAY</em> be indicated in a <a href="#header.retry-after" class="smpl">Retry-After</a> header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section&nbsp;7.1.2</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a <a href="#status.500" class="smpl">500 (Internal
+         delay <em class="bcp14">MAY</em> be indicated in a <a href="#header.retry-after" class="smpl">Retry-After</a> header field (<a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section&nbsp;7.1.3</a>). If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a <a href="#status.500" class="smpl">500 (Internal
             Server Error)</a> response.
       </p>
@@ -2698 +2669 @@
          </p> 
       </div>
-      <div id="rfc.iref.59"></div>
+      <div id="rfc.iref.58"></div>
       <h3 id="rfc.section.6.6.5"><a href="#rfc.section.6.6.5">6.6.5</a>&nbsp;<a id="status.504" href="#status.504">504 Gateway Timeout</a></h3>
       <p id="rfc.section.6.6.5.p.1">The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the
@@ -2708 +2679 @@
          </p> 
       </div>
-      <div id="rfc.iref.59"></div>
+      <div id="rfc.iref.58"></div>
       <h3 id="rfc.section.6.6.6"><a href="#rfc.section.6.6.6">6.6.6</a>&nbsp;<a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3>
       <p id="rfc.section.6.6.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
@@ -2720 +2691 @@
       <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="response.control.data" href="#response.control.data">Control Data</a></h2>
       <p id="rfc.section.7.1.p.1">Response header fields can supply control data that supplements the status code or instructs the client where to go next.</p>
-      <div id="rfc.table.u.11">
+      <div id="rfc.table.u.10">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -2730 +2701 @@
             <tbody>
                <tr>
+                  <td class="left">Age</td>
+                  <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 7.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
+               </tr>
+               <tr>
+                  <td class="left">Date</td>
+                  <td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;7.1.1</a></td>
+               </tr>
+               <tr>
                   <td class="left">Location</td>
-                  <td class="left"><a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;7.1.1</a></td>
+                  <td class="left"><a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section&nbsp;7.1.2</a></td>
                </tr>
                <tr>
                   <td class="left">Retry-After</td>
-                  <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;7.1.2</a></td>
+                  <td class="left"><a href="#header.retry-after" id="rfc.xref.header.retry-after.2" title="Retry-After">Section&nbsp;7.1.3</a></td>
                </tr>
             </tbody>
          </table>
       </div>
+      <div id="rfc.iref.d.2"></div>
+      <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h3>
+      <p id="rfc.section.7.1.1.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the
+         Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section&nbsp;8.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
+      </p>
+      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.27"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>
+</pre><p id="rfc.section.7.1.1.p.3">An example is</p>
+      <div id="rfc.figure.u.35"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
+</pre><p id="rfc.section.7.1.1.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 
+      </p>
+      <ol>
+         <li>If the response status code is <a href="#status.100" class="smpl">100 (Continue)</a> or <a href="#status.101" class="smpl">101 (Switching Protocols)</a>, the response <em class="bcp14">MAY</em> include a Date header field, at the server's option.
+         </li>
+         <li>If the response status code conveys a server error, e.g., <a href="#status.500" class="smpl">500
+               (Internal Server Error)</a> or <a href="#status.503" class="smpl">503 (Service Unavailable)</a>, and it is inconvenient or impossible to generate a valid Date.
+         </li>
+         <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field.
+         </li>
+      </ol>
+      <p id="rfc.section.7.1.1.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
+      </p>
+      <p id="rfc.section.7.1.1.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
+         when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload).
+      </p>
+      <p id="rfc.section.7.1.1.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
+         of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload
+         is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
+         value.
+      </p>
       <div id="rfc.iref.l.1"></div>
-      <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="header.location" href="#header.location">Location</a></h3>
-      <p id="rfc.section.7.1.1.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.
-      </p>
-      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.27"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#imported.abnf" class="smpl">URI-reference</a>
-</pre><p id="rfc.section.7.1.1.p.3">For <a href="#status.201" class="smpl">201 (Created)</a> responses, the Location is the URI of the new resource which was created by the request. For <a href="#status.3xx" class="smpl">3xx (Redirection)</a> responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
-      </p>
-      <p id="rfc.section.7.1.1.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,
+      <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="header.location" href="#header.location">Location</a></h3>
+      <p id="rfc.section.7.1.2.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code.
+      </p>
+      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.28"></span>  <a href="#header.location" class="smpl">Location</a> = <a href="#imported.abnf" class="smpl">URI-reference</a>
+</pre><p id="rfc.section.7.1.2.p.3">For <a href="#status.201" class="smpl">201 (Created)</a> responses, the Location is the URI of the new resource which was created by the request. For <a href="#status.3xx" class="smpl">3xx (Redirection)</a> responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.
+      </p>
+      <p id="rfc.section.7.1.2.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,
          then the original URI's fragment identifier is added to the final value.
       </p>
-      <div id="rfc.figure.u.35"></div> 
+      <div id="rfc.figure.u.37"></div> 
       <p>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</p>  <pre class="text">  Location: /pub/WWW/People.html#tim
 </pre>  <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p> 
-      <div id="rfc.figure.u.36"></div> 
+      <div id="rfc.figure.u.38"></div> 
       <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p>  <pre class="text">  Location: http://www.example.net/index.html
 </pre>  <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p> 
-      <div class="note" id="rfc.section.7.1.1.p.7"> 
+      <div class="note" id="rfc.section.7.1.2.p.7"> 
          <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate
             or define such processing, but does allow it.
          </p> 
       </div>
-      <p id="rfc.section.7.1.1.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears
+      <p id="rfc.section.7.1.2.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears
          in a <a href="#status.201" class="smpl">201
             (Created)</a> response, where the Location header field specifies the URI for the entire created resource.
       </p>
-      <div class="note" id="rfc.section.7.1.1.p.9"> 
+      <div class="note" id="rfc.section.7.1.2.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.1.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.
@@ -2771 +2779 @@
       </div>
       <div id="rfc.iref.r.3"></div>
-      <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="header.retry-after" href="#header.retry-after">Retry-After</a></h3>
-      <p id="rfc.section.7.1.2.p.1">The header "Retry-After" field can be used with a <a href="#status.503" class="smpl">503 (Service
+      <h3 id="rfc.section.7.1.3"><a href="#rfc.section.7.1.3">7.1.3</a>&nbsp;<a id="header.retry-after" href="#header.retry-after">Retry-After</a></h3>
+      <p id="rfc.section.7.1.3.p.1">The header "Retry-After" field can be used with a <a href="#status.503" class="smpl">503 (Service
             Unavailable)</a> response to indicate how long the service is expected to be unavailable to the requesting client. This field <em class="bcp14">MAY</em> also be used with any <a href="#status.3xx" class="smpl">3xx (Redirection)</a> response to indicate the minimum time the user-agent is asked to wait before issuing the redirected request.
       </p>
-      <p id="rfc.section.7.1.2.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>
-      <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.28"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
+      <p id="rfc.section.7.1.3.p.2">The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.</p>
+      <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#header.retry-after" class="smpl">Retry-After</a> = <a href="#http.date" class="smpl">HTTP-date</a> / <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>
 </pre><div id="rule.delta-seconds">
-         <p id="rfc.section.7.1.2.p.4">  Time spans are non-negative decimal integers, representing time in seconds.</p>
+         <p id="rfc.section.7.1.3.p.4">  Time spans are non-negative decimal integers, representing time in seconds.</p>
       </div>
-      <div id="rfc.figure.u.38"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
-</pre><p id="rfc.section.7.1.2.p.6">Two examples of its use are</p>
-      <div id="rfc.figure.u.39"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
+      <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#rule.delta-seconds" class="smpl">delta-seconds</a>  = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
+</pre><p id="rfc.section.7.1.3.p.6">Two examples of its use are</p>
+      <div id="rfc.figure.u.41"></div><pre class="text">  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
   Retry-After: 120
-</pre><p id="rfc.section.7.1.2.p.8">In the latter example, the delay is 2 minutes.</p>
-      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="response.cache.related" href="#response.cache.related">Cache-related</a></h2>
-      <p id="rfc.section.7.2.p.1">Cache-related response header fields provide metadata about the message in order to assist downstream caches.</p>
-      <div id="rfc.table.u.12">
+</pre><p id="rfc.section.7.1.3.p.8">In the latter example, the delay is 2 minutes.</p>
+      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2>
+      <p id="rfc.section.7.2.p.1"><span id="rfc.iref.s.7"></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.7.2.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:
+      </p>
+      <div id="rfc.table.u.11">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -2797 +2811 @@
             <tbody>
                <tr>
-                  <td class="left">Age</td>
-                  <td class="left"><a href="p6-cache.html#header.age" title="Age">Section 7.1</a> of <a href="#Part6" id="rfc.xref.Part6.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a></td>
-               </tr>
-               <tr>
-                  <td class="left">Date</td>
-                  <td class="left"><a href="#header.date" id="rfc.xref.header.date.2" title="Date">Section&nbsp;7.2.1</a></td>
+                  <td class="left">ETag</td>
+                  <td class="left"><a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
+               </tr>
+               <tr>
+                  <td class="left">Last-Modified</td>
+                  <td class="left"><a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.13"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a></td>
                </tr>
                <tr>
                   <td class="left">Vary</td>
-                  <td class="left"><a href="#header.vary" id="rfc.xref.header.vary.2" title="Vary">Section&nbsp;7.2.2</a></td>
+                  <td class="left"><a href="#header.vary" id="rfc.xref.header.vary.2" title="Vary">Section&nbsp;7.2.1</a></td>
                </tr>
             </tbody>
          </table>
       </div>
-      <div id="rfc.iref.d.2"></div>
-      <h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h3>
-      <p id="rfc.section.7.2.1.p.1">The "Date" header field represents the date and time at which the message was originated, having the same semantics as the
-         Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section&nbsp;8.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
-      </p>
-      <div id="rfc.figure.u.40"></div><pre class="inline"><span id="rfc.iref.g.30"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>
-</pre><p id="rfc.section.7.2.1.p.3">An example is</p>
-      <div id="rfc.figure.u.41"></div><pre class="text">  Date: Tue, 15 Nov 1994 08:12:31 GMT
-</pre><p id="rfc.section.7.2.1.p.5">Origin servers <em class="bcp14">MUST</em> include a Date header field in all responses, except in these cases: 
-      </p>
-      <ol>
-         <li>If the response status code is <a href="#status.100" class="smpl">100 (Continue)</a> or <a href="#status.101" class="smpl">101 (Switching Protocols)</a>, the response <em class="bcp14">MAY</em> include a Date header field, at the server's option.
-         </li>
-         <li>If the response status code conveys a server error, e.g., <a href="#status.500" class="smpl">500
-               (Internal Server Error)</a> or <a href="#status.503" class="smpl">503 (Service Unavailable)</a>, and it is inconvenient or impossible to generate a valid Date.
-         </li>
-         <li>If the server does not have a clock that can provide a reasonable approximation of the current time, its responses <em class="bcp14">MUST NOT</em> include a Date header field.
-         </li>
-      </ol>
-      <p id="rfc.section.7.2.1.p.6">A received message that does not have a Date header field <em class="bcp14">MUST</em> be assigned one by the recipient if the message will be cached by that recipient.
-      </p>
-      <p id="rfc.section.7.2.1.p.7">Clients can use the Date header field as well; in order to keep request messages small, they are advised not to include it
-         when it doesn't convey any useful information (as is usually the case for requests that do not contain a payload).
-      </p>
-      <p id="rfc.section.7.2.1.p.8">The HTTP-date sent in a Date header field <em class="bcp14">SHOULD NOT</em> represent a date and time subsequent to the generation of the message. It <em class="bcp14">SHOULD</em> represent the best available approximation of the date and time of message generation, unless the implementation has no means
-         of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the payload
-         is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic
-         value.
-      </p>
       <div id="rfc.iref.v.1"></div>
-      <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h3>
-      <p id="rfc.section.7.2.2.p.1">The "Vary" header field conveys the set of header fields that were used to select the representation.</p>
-      <p id="rfc.section.7.2.2.p.2">Caches use this information as part of determining whether a stored response can be used to satisfy a given request (<a href="p6-cache.html#caching.negotiated.responses" title="Using Negotiated Responses">Section 4.3</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
-      </p>
-      <p id="rfc.section.7.2.2.p.3">In uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select
+      <h3 id="rfc.section.7.2.1"><a href="#rfc.section.7.2.1">7.2.1</a>&nbsp;<a id="header.vary" href="#header.vary">Vary</a></h3>
+      <p id="rfc.section.7.2.1.p.1">The "Vary" header field conveys the set of header fields that were used to select the representation.</p>
+      <p id="rfc.section.7.2.1.p.2">Caches use this information as part of determining whether a stored response can be used to satisfy a given request (<a href="p6-cache.html#caching.negotiated.responses" title="Using Negotiated Responses">Section 4.3</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
+      </p>
+      <p id="rfc.section.7.2.1.p.3">In uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select
          the representation.
       </p>
       <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.31"></span>  <a href="#header.vary" class="smpl">Vary</a> = "*" / 1#<a href="#imported.abnf" class="smpl">field-name</a>
-</pre><p id="rfc.section.7.2.2.p.5">The set of header fields named by the Vary field value is known as the selecting header fields.</p>
-      <p id="rfc.section.7.2.2.p.6">A server <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to proactive negotiation. Doing so allows a cache
+</pre><p id="rfc.section.7.2.1.p.5">The set of header fields named by the Vary field value is known as the selecting header fields.</p>
+      <p id="rfc.section.7.2.1.p.6">A server <em class="bcp14">SHOULD</em> include a Vary header field with any cacheable response that is subject to proactive negotiation. Doing so allows a cache
          to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that
          resource. A server <em class="bcp14">MAY</em> include a Vary header field with a non-cacheable response that is subject to proactive negotiation, since this might provide
          the user agent with useful information about the dimensions over which the response varies at the time of the response.
       </p>
-      <p id="rfc.section.7.2.2.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the header fields (e.g., the network address
+      <p id="rfc.section.7.2.1.p.7">A Vary field value of "*" signals that unspecified parameters not limited to the header fields (e.g., the network address
          of the client), play a role in the selection of the response representation; therefore, a cache cannot determine whether this
          response is appropriate. A proxy <em class="bcp14">MUST NOT</em> generate the "*" value.
       </p>
-      <p id="rfc.section.7.2.2.p.8">The field-names given are not limited to the set of standard header fields defined by this specification. Field names are
+      <p id="rfc.section.7.2.1.p.8">The field-names given are not limited to the set of standard header fields defined by this specification. Field names are
          case-insensitive.
       </p>
@@ -2866 +2851 @@
          requests.
       </p>
-      <div id="rfc.table.u.13">
+      <div id="rfc.table.u.12">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -2888 +2873 @@
       <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="response.inform" href="#response.inform">Informative</a></h2>
       <p id="rfc.section.7.4.p.1">The remaining response header fields provide more information about the target resource for potential use in later requests.</p>
-      <div id="rfc.table.u.14">
+      <div id="rfc.table.u.13">
          <table class="tt full left" cellpadding="3" cellspacing="0">
             <thead>
@@ -3273 +3258 @@
          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.4.2</a>).
+         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.3.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>
@@ -3655 +3640 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.date" id="rfc.xref.header.date.3" title="Date">Section&nbsp;7.2.1</a> 
+                  <td class="left"> <a href="#header.date" id="rfc.xref.header.date.3" title="Date">Section&nbsp;7.1.1</a> 
                   </td>
                </tr>
@@ -3676 +3661 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section&nbsp;7.1.1</a> 
+                  <td class="left"> <a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section&nbsp;7.1.2</a> 
                   </td>
                </tr>
@@ -3704 +3689 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section&nbsp;7.1.2</a> 
+                  <td class="left"> <a href="#header.retry-after" id="rfc.xref.header.retry-after.3" title="Retry-After">Section&nbsp;7.1.3</a> 
                   </td>
                </tr>
@@ -3725 +3710 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.vary" id="rfc.xref.header.vary.3" title="Vary">Section&nbsp;7.2.2</a> 
+                  <td class="left"> <a href="#header.vary" id="rfc.xref.header.vary.3" title="Vary">Section&nbsp;7.2.1</a> 
                   </td>
                </tr>
@@ -4170 +4155 @@
       </p>
       <p id="rfc.section.C.p.14">Correct syntax of "<a href="#header.location" class="smpl">Location</a>" header field to allow URI references (including relative references and fragments), as referred symbol "absoluteURI" wasn't
-         what was expected, and add some clarifications as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;7.1.1</a>)
+         what was expected, and add some clarifications as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;7.1.2</a>)
       </p>
       <p id="rfc.section.C.p.15">Reclassify "<a href="#header.allow" class="smpl">Allow</a>" as response header field, removing the option to specify it in a PUT request. Relax the server requirement on the contents
@@ -4942 +4927 @@
          <ul class="ind">
             <li><a id="rfc.index.1" href="#rfc.index.1"><b>1</b></a><ul>
-                  <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">5.1.2.1</a>, <a href="#rfc.xref.status.100.2">5.1.2.1</a>, <a href="#rfc.xref.status.100.3">6.1</a>, <a href="#rfc.iref.55"><b>6.2.1</b></a>, <a href="#rfc.xref.status.100.4">9.2.3</a></li>
-                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.32"><b>5.1.2</b></a></li>
-                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">6.1</a>, <a href="#rfc.iref.55"><b>6.2.2</b></a>, <a href="#rfc.xref.status.101.2">9.2.3</a></li>
-                  <li>1xx Informational (status code class)&nbsp;&nbsp;<a href="#rfc.iref.54"><b>6.2</b></a></li>
+                  <li>100 Continue (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.100.1">5.1.2.1</a>, <a href="#rfc.xref.status.100.2">5.1.2.1</a>, <a href="#rfc.xref.status.100.3">6.1</a>, <a href="#rfc.iref.54"><b>6.2.1</b></a>, <a href="#rfc.xref.status.100.4">9.2.3</a></li>
+                  <li>100-continue (expect value)&nbsp;&nbsp;<a href="#rfc.iref.31"><b>5.1.2</b></a></li>
+                  <li>101 Switching Protocols (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.101.1">6.1</a>, <a href="#rfc.iref.54"><b>6.2.2</b></a>, <a href="#rfc.xref.status.101.2">9.2.3</a></li>
+                  <li>1xx Informational (status code class)&nbsp;&nbsp;<a href="#rfc.iref.53"><b>6.2</b></a></li>
                </ul>
             </li>
             <li><a id="rfc.index.2" href="#rfc.index.2"><b>2</b></a><ul>
-                  <li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">6.1</a>, <a href="#rfc.iref.56"><b>6.3.1</b></a>, <a href="#rfc.xref.status.200.2">9.2.3</a></li>
-                  <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">6.1</a>, <a href="#rfc.iref.56"><b>6.3.2</b></a>, <a href="#rfc.xref.status.201.2">9.2.3</a></li>
-                  <li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">6.1</a>, <a href="#rfc.iref.56"><b>6.3.3</b></a>, <a href="#rfc.xref.status.202.2">9.2.3</a></li>
-                  <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">6.1</a>, <a href="#rfc.iref.56"><b>6.3.4</b></a>, <a href="#rfc.xref.status.203.2">9.2.3</a>, <a href="#rfc.xref.status.203.3">C</a></li>
-                  <li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">6.1</a>, <a href="#rfc.iref.56"><b>6.3.5</b></a>, <a href="#rfc.xref.status.204.2">9.2.3</a></li>
-                  <li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">6.1</a>, <a href="#rfc.iref.56"><b>6.3.6</b></a>, <a href="#rfc.xref.status.205.2">9.2.3</a></li>
-                  <li>2xx Successful (status code class)&nbsp;&nbsp;<a href="#rfc.iref.55"><b>6.3</b></a></li>
+                  <li>200 OK (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.200.1">6.1</a>, <a href="#rfc.iref.55"><b>6.3.1</b></a>, <a href="#rfc.xref.status.200.2">9.2.3</a></li>
+                  <li>201 Created (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.201.1">6.1</a>, <a href="#rfc.iref.55"><b>6.3.2</b></a>, <a href="#rfc.xref.status.201.2">9.2.3</a></li>
+                  <li>202 Accepted (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.202.1">6.1</a>, <a href="#rfc.iref.55"><b>6.3.3</b></a>, <a href="#rfc.xref.status.202.2">9.2.3</a></li>
+                  <li>203 Non-Authoritative Information (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.203.1">6.1</a>, <a href="#rfc.iref.55"><b>6.3.4</b></a>, <a href="#rfc.xref.status.203.2">9.2.3</a>, <a href="#rfc.xref.status.203.3">C</a></li>
+                  <li>204 No Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.204.1">6.1</a>, <a href="#rfc.iref.55"><b>6.3.5</b></a>, <a href="#rfc.xref.status.204.2">9.2.3</a></li>
+                  <li>205 Reset Content (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.205.1">6.1</a>, <a href="#rfc.iref.55"><b>6.3.6</b></a>, <a href="#rfc.xref.status.205.2">9.2.3</a></li>
+                  <li>2xx Successful (status code class)&nbsp;&nbsp;<a href="#rfc.iref.54"><b>6.3</b></a></li>
                </ul>
             </li>
             <li><a id="rfc.index.3" href="#rfc.index.3"><b>3</b></a><ul>
-                  <li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">6.1</a>, <a href="#rfc.iref.57"><b>6.4.1</b></a>, <a href="#rfc.xref.status.300.2">9.2.3</a></li>
-                  <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">6.1</a>, <a href="#rfc.iref.57"><b>6.4.2</b></a>, <a href="#rfc.xref.status.301.2">9.2.3</a>, <a href="#rfc.xref.status.301.3">C</a></li>
-                  <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">6.1</a>, <a href="#rfc.iref.57"><b>6.4.3</b></a>, <a href="#rfc.xref.status.302.2">9.2.3</a>, <a href="#rfc.xref.status.302.3">C</a></li>
-                  <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">6.1</a>, <a href="#rfc.iref.57"><b>6.4.4</b></a>, <a href="#rfc.xref.status.303.2">9.2.3</a></li>
-                  <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">6.1</a>, <a href="#rfc.iref.57"><b>6.4.5</b></a>, <a href="#rfc.xref.status.305.2">9.2.3</a>, <a href="#rfc.xref.status.305.3">C</a></li>
-                  <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.57"><b>6.4.6</b></a>, <a href="#rfc.xref.status.306.1">9.2.3</a></li>
-                  <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">6.1</a>, <a href="#rfc.iref.57"><b>6.4.7</b></a>, <a href="#rfc.xref.status.307.2">9.2.3</a>, <a href="#rfc.xref.status.307.3">C</a></li>
-                  <li>3xx Redirection (status code class)&nbsp;&nbsp;<a href="#rfc.iref.56"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">C</a></li>
+                  <li>300 Multiple Choices (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.300.1">6.1</a>, <a href="#rfc.iref.56"><b>6.4.1</b></a>, <a href="#rfc.xref.status.300.2">9.2.3</a></li>
+                  <li>301 Moved Permanently (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.301.1">6.1</a>, <a href="#rfc.iref.56"><b>6.4.2</b></a>, <a href="#rfc.xref.status.301.2">9.2.3</a>, <a href="#rfc.xref.status.301.3">C</a></li>
+                  <li>302 Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.302.1">6.1</a>, <a href="#rfc.iref.56"><b>6.4.3</b></a>, <a href="#rfc.xref.status.302.2">9.2.3</a>, <a href="#rfc.xref.status.302.3">C</a></li>
+                  <li>303 See Other (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.303.1">6.1</a>, <a href="#rfc.iref.56"><b>6.4.4</b></a>, <a href="#rfc.xref.status.303.2">9.2.3</a></li>
+                  <li>305 Use Proxy (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.305.1">6.1</a>, <a href="#rfc.iref.56"><b>6.4.5</b></a>, <a href="#rfc.xref.status.305.2">9.2.3</a>, <a href="#rfc.xref.status.305.3">C</a></li>
+                  <li>306 (Unused) (status code)&nbsp;&nbsp;<a href="#rfc.iref.56"><b>6.4.6</b></a>, <a href="#rfc.xref.status.306.1">9.2.3</a></li>
+                  <li>307 Temporary Redirect (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.307.1">6.1</a>, <a href="#rfc.iref.56"><b>6.4.7</b></a>, <a href="#rfc.xref.status.307.2">9.2.3</a>, <a href="#rfc.xref.status.307.3">C</a></li>
+                  <li>3xx Redirection (status code class)&nbsp;&nbsp;<a href="#rfc.iref.55"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">C</a></li>
                </ul>
             </li>
             <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul>
-                  <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.1</b></a>, <a href="#rfc.xref.status.400.2">9.2.3</a></li>
-                  <li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.2</b></a>, <a href="#rfc.xref.status.402.2">9.2.3</a></li>
-                  <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.3</b></a>, <a href="#rfc.xref.status.403.2">9.2.3</a></li>
-                  <li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.4</b></a>, <a href="#rfc.xref.status.404.2">9.2.3</a></li>
-                  <li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.5</b></a>, <a href="#rfc.xref.status.405.2">9.2.3</a></li>
-                  <li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.6</b></a>, <a href="#rfc.xref.status.406.2">9.2.3</a></li>
-                  <li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.7</b></a>, <a href="#rfc.xref.status.408.2">9.2.3</a></li>
-                  <li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.8</b></a>, <a href="#rfc.xref.status.409.2">9.2.3</a></li>
-                  <li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.9</b></a>, <a href="#rfc.xref.status.410.2">9.2.3</a></li>
-                  <li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.10</b></a>, <a href="#rfc.xref.status.411.2">9.2.3</a></li>
-                  <li>413 Request Representation Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.11</b></a>, <a href="#rfc.xref.status.413.2">9.2.3</a></li>
-                  <li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.12</b></a>, <a href="#rfc.xref.status.414.2">9.2.3</a></li>
-                  <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.13</b></a>, <a href="#rfc.xref.status.415.2">9.2.3</a></li>
-                  <li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.14</b></a>, <a href="#rfc.xref.status.417.2">9.2.3</a></li>
-                  <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">6.1</a>, <a href="#rfc.iref.58"><b>6.5.15</b></a>, <a href="#rfc.xref.status.426.2">9.2.3</a>, <a href="#rfc.xref.status.426.3">C</a></li>
-                  <li>4xx Client Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.57"><b>6.5</b></a></li>
+                  <li>400 Bad Request (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.400.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.1</b></a>, <a href="#rfc.xref.status.400.2">9.2.3</a></li>
+                  <li>402 Payment Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.402.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.2</b></a>, <a href="#rfc.xref.status.402.2">9.2.3</a></li>
+                  <li>403 Forbidden (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.403.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.3</b></a>, <a href="#rfc.xref.status.403.2">9.2.3</a></li>
+                  <li>404 Not Found (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.404.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.4</b></a>, <a href="#rfc.xref.status.404.2">9.2.3</a></li>
+                  <li>405 Method Not Allowed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.405.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.5</b></a>, <a href="#rfc.xref.status.405.2">9.2.3</a></li>
+                  <li>406 Not Acceptable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.406.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.6</b></a>, <a href="#rfc.xref.status.406.2">9.2.3</a></li>
+                  <li>408 Request Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.408.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.7</b></a>, <a href="#rfc.xref.status.408.2">9.2.3</a></li>
+                  <li>409 Conflict (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.409.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.8</b></a>, <a href="#rfc.xref.status.409.2">9.2.3</a></li>
+                  <li>410 Gone (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.410.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.9</b></a>, <a href="#rfc.xref.status.410.2">9.2.3</a></li>
+                  <li>411 Length Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.411.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.10</b></a>, <a href="#rfc.xref.status.411.2">9.2.3</a></li>
+                  <li>413 Request Representation Too Large (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.413.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.11</b></a>, <a href="#rfc.xref.status.413.2">9.2.3</a></li>
+                  <li>414 URI Too Long (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.414.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.12</b></a>, <a href="#rfc.xref.status.414.2">9.2.3</a></li>
+                  <li>415 Unsupported Media Type (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.415.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.13</b></a>, <a href="#rfc.xref.status.415.2">9.2.3</a></li>
+                  <li>417 Expectation Failed (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.417.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.14</b></a>, <a href="#rfc.xref.status.417.2">9.2.3</a></li>
+                  <li>426 Upgrade Required (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.426.1">6.1</a>, <a href="#rfc.iref.57"><b>6.5.15</b></a>, <a href="#rfc.xref.status.426.2">9.2.3</a>, <a href="#rfc.xref.status.426.3">C</a></li>
+                  <li>4xx Client Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.56"><b>6.5</b></a></li>
                </ul>
             </li>
             <li><a id="rfc.index.5" href="#rfc.index.5"><b>5</b></a><ul>
-                  <li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">6.1</a>, <a href="#rfc.iref.59"><b>6.6.1</b></a>, <a href="#rfc.xref.status.500.2">9.2.3</a></li>
-                  <li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">6.1</a>, <a href="#rfc.iref.59"><b>6.6.2</b></a>, <a href="#rfc.xref.status.501.2">9.2.3</a></li>
-                  <li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">6.1</a>, <a href="#rfc.iref.59"><b>6.6.3</b></a>, <a href="#rfc.xref.status.502.2">9.2.3</a></li>
-                  <li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">6.1</a>, <a href="#rfc.iref.59"><b>6.6.4</b></a>, <a href="#rfc.xref.status.503.2">9.2.3</a></li>
-                  <li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">6.1</a>, <a href="#rfc.iref.59"><b>6.6.5</b></a>, <a href="#rfc.xref.status.504.2">9.2.3</a></li>
-                  <li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">6.1</a>, <a href="#rfc.iref.59"><b>6.6.6</b></a>, <a href="#rfc.xref.status.505.2">9.2.3</a></li>
-                  <li>5xx Server Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.58"><b>6.6</b></a></li>
+                  <li>500 Internal Server Error (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.500.1">6.1</a>, <a href="#rfc.iref.58"><b>6.6.1</b></a>, <a href="#rfc.xref.status.500.2">9.2.3</a></li>
+                  <li>501 Not Implemented (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.501.1">6.1</a>, <a href="#rfc.iref.58"><b>6.6.2</b></a>, <a href="#rfc.xref.status.501.2">9.2.3</a></li>
+                  <li>502 Bad Gateway (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.502.1">6.1</a>, <a href="#rfc.iref.58"><b>6.6.3</b></a>, <a href="#rfc.xref.status.502.2">9.2.3</a></li>
+                  <li>503 Service Unavailable (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.503.1">6.1</a>, <a href="#rfc.iref.58"><b>6.6.4</b></a>, <a href="#rfc.xref.status.503.2">9.2.3</a></li>
+                  <li>504 Gateway Timeout (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.504.1">6.1</a>, <a href="#rfc.iref.58"><b>6.6.5</b></a>, <a href="#rfc.xref.status.504.2">9.2.3</a></li>
+                  <li>505 HTTP Version Not Supported (status code)&nbsp;&nbsp;<a href="#rfc.xref.status.505.1">6.1</a>, <a href="#rfc.iref.58"><b>6.6.6</b></a>, <a href="#rfc.xref.status.505.2">9.2.3</a></li>
+                  <li>5xx Server Error (status code class)&nbsp;&nbsp;<a href="#rfc.iref.57"><b>6.6</b></a></li>
                </ul>
             </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.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>Accept header field&nbsp;&nbsp;<a href="#rfc.xref.header.accept.1">3.4.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.4.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.4.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.4.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>
@@ -5013 +4998 @@
                   <li>Content-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-encoding.1">3.1</a>, <a href="#rfc.iref.c.3"><b>3.1.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.1</a>, <a href="#rfc.iref.c.4"><b>3.1.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.1</a>, <a href="#rfc.iref.c.5"><b>3.1.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-Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.content-location.1">3.1</a>, <a href="#rfc.iref.c.5"><b>3.1.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.2</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.1</a>, <a href="#rfc.iref.c.2"><b>3.1.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>
@@ -5019 +5004 @@
             </li>
             <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul>
-                  <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.4</a>, <a href="#rfc.xref.header.date.2">7.2</a>, <a href="#rfc.iref.d.2"><b>7.2.1</b></a>, <a href="#rfc.xref.header.date.3">9.3.2</a></li>
+                  <li>Date header field&nbsp;&nbsp;<a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.xref.header.date.2">7.1</a>, <a href="#rfc.iref.d.2"><b>7.1.1</b></a>, <a href="#rfc.xref.header.date.3">9.3.2</a></li>
                   <li>deflate (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.d.3">8.4</a></li>
                   <li>DELETE method&nbsp;&nbsp;<a href="#rfc.xref.DELETE.1">4.1</a>, <a href="#rfc.iref.d.1"><b>4.3.5</b></a>, <a href="#rfc.xref.DELETE.2">9.1.3</a></li>
@@ -5038 +5023 @@
             </li>
             <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
-                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3.4</a>, <a href="#rfc.xref.GET.2">4.1</a>, <a href="#rfc.iref.g.6"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.3">9.1.3</a></li>
+                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">4.1</a>, <a href="#rfc.iref.g.6"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.3">9.1.3</a></li>
                   <li><tt>Grammar</tt>&nbsp;&nbsp;
                      <ul>
@@ -5057 +5042 @@
                         <li><tt>Content-Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.4"><b>3.1.4</b></a></li>
                         <li><tt>Content-Type</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.1"><b>3.1.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>Date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>7.1.1</b></a></li>
                         <li><tt>date1</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.36"><b>8.1</b></a></li>
                         <li><tt>day</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>8.1</b></a></li>
                         <li><tt>day-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>8.1</b></a></li>
                         <li><tt>day-name-l</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>8.1</b></a></li>
-                        <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>7.1.2</b></a></li>
+                        <li><tt>delta-seconds</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>7.1.3</b></a></li>
                         <li><tt>Expect</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.8"><b>5.1.2</b></a></li>
                         <li><tt>expect-name</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>5.1.2</b></a></li>
@@ -5074 +5059 @@
                         <li><tt>language-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.23"><b>5.3.5</b></a></li>
                         <li><tt>language-tag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.61"><b>8.6</b></a></li>
-                        <li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.27"><b>7.1.1</b></a></li>
+                        <li><tt>Location</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>7.1.2</b></a></li>
                         <li><tt>Max-Forwards</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.7"><b>5.1.1</b></a></li>
                         <li><tt>media-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.16"><b>5.3.2</b></a></li>
@@ -5088 +5073 @@
                         <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.14"><b>5.3.1</b></a></li>
                         <li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.25"><b>5.5.2</b></a></li>
-                        <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.28"><b>7.1.2</b></a></li>
+                        <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>7.1.3</b></a></li>
                         <li><tt>rfc1123-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>8.1</b></a></li>
                         <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.48"><b>8.1</b></a></li>
@@ -5098 +5083 @@
                         <li><tt>User-Agent</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.26"><b>5.5.3</b></a></li>
                         <li><tt>value</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.60"><b>8.5</b></a></li>
-                        <li><tt>Vary</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>7.2.2</b></a></li>
+                        <li><tt>Vary</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>7.2.1</b></a></li>
                         <li><tt>weight</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.13"><b>5.3.1</b></a></li>
                         <li><tt>year</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>8.1</b></a></li>
@@ -5115 +5100 @@
             </li>
             <li><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul>
-                  <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.1</b></a>, <a href="#rfc.xref.header.location.4">9.3.2</a>, <a href="#rfc.xref.header.location.5">C</a></li>
+                  <li>Location header field&nbsp;&nbsp;<a href="#rfc.xref.header.location.1">4.3.3</a>, <a href="#rfc.xref.header.location.2">6.4</a>, <a href="#rfc.xref.header.location.3">7.1</a>, <a href="#rfc.iref.l.1"><b>7.1.2</b></a>, <a href="#rfc.xref.header.location.4">9.3.2</a>, <a href="#rfc.xref.header.location.5">C</a></li>
                </ul>
             </li>
@@ -5128 +5113 @@
             </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.4</a>, <a href="#rfc.xref.Part1.8">3.4.1</a>, <a href="#rfc.xref.Part1.9">3.4.1</a>, <a href="#rfc.xref.Part1.10">3.4.2</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.4</a>, <a href="#rfc.xref.Part1.8">3.3.1</a>, <a href="#rfc.xref.Part1.9">3.3.1</a>, <a href="#rfc.xref.Part1.10">3.3.2</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>
@@ -5137 +5122 @@
                         <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.9">3.4.1</a></li>
+                        <li><em>Section 3.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.9">3.3.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.8">3.4.1</a></li>
+                        <li><em>Section 3.3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.8">3.3.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>
@@ -5149 +5134 @@
                         <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.7">3.1.4</a>, <a href="#rfc.xref.Part1.10">3.4.2</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.7">3.1.4</a>, <a href="#rfc.xref.Part1.10">3.3.2</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>
@@ -5158 +5143 @@
                      </ul>
                   </li>
-                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</a>, <a href="#rfc.xref.Part4.2">3.2</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.2</a></li>
-                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">3.2</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>
-                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.7">5.2</a></li>
-                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.8">5.2</a></li>
-                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.9">6.1</a></li>
-                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.10">6.1</a>, <a href="#rfc.xref.Part4.13">6.4</a></li>
-                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.11">6.1</a></li>
+                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.3.1</a>, <a href="#rfc.xref.Part4.2">5.2</a>, <a href="#rfc.xref.Part4.3">5.2</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">6.1</a>, <a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.11">6.4</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#rfc.xref.Part4.13">7.2</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.13">7.2</a></li>
+                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.12">7.2</a></li>
+                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">5.2</a></li>
+                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.2</a></li>
+                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.5">5.2</a></li>
+                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.6">5.2</a></li>
+                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.7">6.1</a></li>
+                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.11">6.4</a></li>
+                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.9">6.1</a></li>
                      </ul>
                   </li>
-                  <li><em>Part5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part5.1">3.4.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.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>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.4.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.3.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.1</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.1</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.1</a>, <a href="#rfc.xref.Part6.16">7.2.1</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>
-                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.16">7.2.2</a></li>
+                        <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.16">7.2.1</a></li>
                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">4.3.2</a></li>
                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">4.3.4</a>, <a href="#rfc.xref.Part6.7">4.3.5</a></li>
-                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.15">7.2</a></li>
+                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.15">7.1</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.1</a></li>
@@ -5202 +5187 @@
                      </ul>
                   </li>
-                  <li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.1">3.4</a></li>
-                  <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.4</a>, <a href="#rfc.xref.POST.2">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.3">9.1.3</a>, <a href="#rfc.xref.POST.4">C</a></li>
-                  <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.4</a>, <a href="#rfc.xref.PUT.2">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.3">9.1.3</a>, <a href="#rfc.xref.PUT.4">C</a></li>
+                  <li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.1">3.3</a></li>
+                  <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.3</a>, <a href="#rfc.xref.POST.2">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.3">9.1.3</a>, <a href="#rfc.xref.POST.4">C</a></li>
+                  <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.3</a>, <a href="#rfc.xref.PUT.2">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.3">9.1.3</a>, <a href="#rfc.xref.PUT.4">C</a></li>
                </ul>
             </li>
@@ -5211 +5196 @@
                   <li>representation&nbsp;&nbsp;<a href="#rfc.iref.r.1">3</a></li>
                   <li><em>REST</em>&nbsp;&nbsp;<a href="#rfc.xref.REST.1">3</a>, <a href="#rfc.xref.REST.2">4.1</a>, <a href="#REST"><b>12.2</b></a></li>
-                  <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">6.6.4</a>, <a href="#rfc.xref.header.retry-after.2">7.1</a>, <a href="#rfc.iref.r.3"><b>7.1.2</b></a>, <a href="#rfc.xref.header.retry-after.3">9.3.2</a></li>
+                  <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">6.6.4</a>, <a href="#rfc.xref.header.retry-after.2">7.1</a>, <a href="#rfc.iref.r.3"><b>7.1.3</b></a>, <a href="#rfc.xref.header.retry-after.3">9.3.2</a></li>
                   <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">8.1</a>, <a href="#rfc.xref.RFC1123.2">8.1</a>, <a href="#RFC1123"><b>12.2</b></a><ul>
                         <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">8.1</a></li>
@@ -5224 +5209 @@
                   <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.3</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.3</a></li>
+                  <li><em>RFC2046</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.1">3.2</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.2</a></li>
                         <li><em>Section 5.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2046.3">8.5.2</a></li>
                      </ul>
@@ -5241 +5226 @@
                   <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.5</a>, <a href="#RFC2295"><b>12.2</b></a></li>
+                  <li><em>RFC2295</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2295.1">3.4</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.1.4</a>, <a href="#RFC2557"><b>12.2</b></a>, <a href="#rfc.xref.RFC2557.2">A.6</a><ul>
@@ -5261 +5246 @@
                      </ul>
                   </li>
-                  <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">7.1.1</a>, <a href="#rfc.xref.RFC3986.2">7.1.1</a>, <a href="#RFC3986"><b>12.1</b></a><ul>
-                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">7.1.1</a></li>
-                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.2">7.1.1</a></li>
+                  <li><em>RFC3986</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">7.1.2</a>, <a href="#rfc.xref.RFC3986.2">7.1.2</a>, <a href="#RFC3986"><b>12.1</b></a><ul>
+                        <li><em>Section 4.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.1">7.1.2</a></li>
+                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC3986.2">7.1.2</a></li>
                      </ul>
                   </li>
@@ -5282 +5267 @@
                      </ul>
                   </li>
-                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a>, <a href="#rfc.xref.RFC5322.3">7.2.1</a>, <a href="#rfc.xref.RFC5322.4">8.1</a>, <a href="#RFC5322"><b>12.2</b></a>, <a href="#rfc.xref.RFC5322.5">A</a><ul>
+                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a>, <a href="#rfc.xref.RFC5322.3">7.1.1</a>, <a href="#rfc.xref.RFC5322.4">8.1</a>, <a href="#RFC5322"><b>12.2</b></a>, <a href="#rfc.xref.RFC5322.5">A</a><ul>
                         <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.4">8.1</a></li>
                         <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a></li>
-                        <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">7.2.1</a></li>
+                        <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">7.1.1</a></li>
                      </ul>
                   </li>
@@ -5299 +5284 @@
             </li>
             <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.2</b></a></li>
+                  <li>safe&nbsp;&nbsp;<a href="#rfc.iref.s.1"><b>4.2.1</b></a></li>
+                  <li>selected representation&nbsp;&nbsp;<a href="#rfc.iref.s.7"><b>7.2</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;
                      <ul>
-                        <li>1xx Informational&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>6.2</b></a></li>
-                        <li>2xx Successful&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>6.3</b></a></li>
-                        <li>3xx Redirection&nbsp;&nbsp;<a href="#rfc.iref.s.5"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">C</a></li>
-                        <li>4xx Client Error&nbsp;&nbsp;<a href="#rfc.iref.s.6"><b>6.5</b></a></li>
-                        <li>5xx Server Error&nbsp;&nbsp;<a href="#rfc.iref.s.7"><b>6.6</b></a></li>
+                        <li>1xx Informational&nbsp;&nbsp;<a href="#rfc.iref.s.2"><b>6.2</b></a></li>
+                        <li>2xx Successful&nbsp;&nbsp;<a href="#rfc.iref.s.3"><b>6.3</b></a></li>
+                        <li>3xx Redirection&nbsp;&nbsp;<a href="#rfc.iref.s.4"><b>6.4</b></a>, <a href="#rfc.xref.status.3xx.1">C</a></li>
+                        <li>4xx Client Error&nbsp;&nbsp;<a href="#rfc.iref.s.5"><b>6.5</b></a></li>
+                        <li>5xx Server Error&nbsp;&nbsp;<a href="#rfc.iref.s.6"><b>6.6</b></a></li>
                      </ul>
                   </li>
@@ -5319 +5304 @@
             </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.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>
+                  <li>User-Agent header field&nbsp;&nbsp;<a href="#rfc.xref.header.user-agent.1">3.4.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.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>
+                  <li>Vary header field&nbsp;&nbsp;<a href="#rfc.xref.header.vary.1">3.4.1</a>, <a href="#rfc.xref.header.vary.2">7.2</a>, <a href="#rfc.iref.v.1"><b>7.2.1</b></a>, <a href="#rfc.xref.header.vary.3">9.3.2</a></li>
                </ul>
             </li>

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

@@ -529 +529 @@
 </section>
 
-<section title="Selected Representation Header Fields" anchor="selected.representation">
-<t><iref primary="true" item="selected representation"/>
-   We use the term "<x:dfn>selected representation</x: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.
-</t>
-<t>
-   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:
-</t>
-<texttable align="left">
-  <ttcol>Header Field Name</ttcol>
-  <ttcol>Defined in...</ttcol>
-
-  <c>ETag</c> <c>&header-etag;</c>
-  <c>Last-Modified</c> <c>&header-last-modified;</c>
-</texttable>
-</section>
-
 <section title="Representation Data" anchor="representation.data">
   <x:anchor-alias value="representation-data"/>
@@ -3261 +3238 @@
   <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol>
 
+  <c>Age</c> <c>&header-age;</c>
+  <c>Date</c> <c><xref target="header.date"/></c>
   <c>Location</c> <c><xref target="header.location"/></c>
   <c>Retry-After</c> <c><xref target="header.retry-after"/></c>
 </texttable>
+
+<section title="Date" anchor="header.date">
+  <iref primary="true" item="Date header field" x:for-anchor=""/>
+  <x:anchor-alias value="Date"/>
+<t>
+   The "Date" header field represents the date and time at which
+   the message was originated, having the same semantics as the Origination
+   Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>.
+   The field value is an HTTP-date, as defined in <xref target="http.date"/>;
+   it &MUST; be sent in rfc1123-date format.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>
+  <x:ref>Date</x:ref> = <x:ref>HTTP-date</x:ref>
+</artwork></figure>
+<t>
+   An example is
+</t>
+<figure><artwork type="example">
+  Date: Tue, 15 Nov 1994 08:12:31 GMT
+</artwork></figure>
+<t>
+   Origin servers &MUST; include a Date header field in all responses,
+   except in these cases:
+  <list style="numbers">
+      <t>If the response status code is <x:ref>100 (Continue)</x:ref> or
+         <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a
+         Date header field, at the server's option.</t>
+
+      <t>If the response status code conveys a server error, e.g., <x:ref>500
+         (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>,
+         and it is inconvenient or impossible to generate a valid Date.</t>
+
+      <t>If the server does not have a clock that can provide a
+         reasonable approximation of the current time, its responses
+         &MUST-NOT; include a Date header field.</t>
+  </list>
+</t>
+<t>
+   A received message that does not have a Date header field &MUST; be
+   assigned one by the recipient if the message will be cached by that
+   recipient.
+</t>
+<t>
+   Clients can use the Date header field as well; in order to keep request
+   messages small, they are advised not to include it when it doesn't convey
+   any useful information (as is usually the case for requests that do not
+   contain a payload).
+</t>
+<t>
+   The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and
+   time subsequent to the generation of the message. It &SHOULD; represent
+   the best available approximation of the date and time of message
+   generation, unless the implementation has no means of generating a
+   reasonably accurate date and time. In theory, the date ought to
+   represent the moment just before the payload is generated. In
+   practice, the date can be generated at any time during the message
+   origination without affecting its semantic value.
+</t>
+</section>
 
 <section title="Location" anchor="header.location">
@@ -3367 +3405 @@
 </section>
 
-<section title="Cache-related" anchor="response.cache.related">
-<t>
-   Cache-related response header fields provide metadata about the message
-   in order to assist downstream caches.
+<section title="Selected Representation Header Fields" anchor="selected.representation">
+<t><iref primary="true" item="selected representation"/>
+   We use the term "<x:dfn>selected representation</x: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.
+</t>
+<t>
+   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:
 </t>
 <texttable align="left">
-  <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol>
-
-  <c>Age</c> <c>&header-age;</c>
-  <c>Date</c> <c><xref target="header.date"/></c>
+  <ttcol>Header Field Name</ttcol>
+  <ttcol>Defined in...</ttcol>
+
+  <c>ETag</c> <c>&header-etag;</c>
+  <c>Last-Modified</c> <c>&header-last-modified;</c>
   <c>Vary</c> <c><xref target="header.vary"/></c>
 </texttable>
-
-<section title="Date" anchor="header.date">
-  <iref primary="true" item="Date header field" x:for-anchor=""/>
-  <x:anchor-alias value="Date"/>
-<t>
-   The "Date" header field represents the date and time at which
-   the message was originated, having the same semantics as the Origination
-   Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>.
-   The field value is an HTTP-date, as defined in <xref target="http.date"/>;
-   it &MUST; be sent in rfc1123-date format.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>
-  <x:ref>Date</x:ref> = <x:ref>HTTP-date</x:ref>
-</artwork></figure>
-<t>
-   An example is
-</t>
-<figure><artwork type="example">
-  Date: Tue, 15 Nov 1994 08:12:31 GMT
-</artwork></figure>
-<t>
-   Origin servers &MUST; include a Date header field in all responses,
-   except in these cases:
-  <list style="numbers">
-      <t>If the response status code is <x:ref>100 (Continue)</x:ref> or
-         <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a
-         Date header field, at the server's option.</t>
-
-      <t>If the response status code conveys a server error, e.g., <x:ref>500
-         (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>,
-         and it is inconvenient or impossible to generate a valid Date.</t>
-
-      <t>If the server does not have a clock that can provide a
-         reasonable approximation of the current time, its responses
-         &MUST-NOT; include a Date header field.</t>
-  </list>
-</t>
-<t>
-   A received message that does not have a Date header field &MUST; be
-   assigned one by the recipient if the message will be cached by that
-   recipient.
-</t>
-<t>
-   Clients can use the Date header field as well; in order to keep request
-   messages small, they are advised not to include it when it doesn't convey
-   any useful information (as is usually the case for requests that do not
-   contain a payload).
-</t>
-<t>
-   The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and
-   time subsequent to the generation of the message. It &SHOULD; represent
-   the best available approximation of the date and time of message
-   generation, unless the implementation has no means of generating a
-   reasonably accurate date and time. In theory, the date ought to
-   represent the moment just before the payload is generated. In
-   practice, the date can be generated at any time during the message
-   origination without affecting its semantic value.
-</t>
-</section>
 
 <section anchor="header.vary" title="Vary">