Changeset 966

Timestamp:

30/07/10 06:12:22 (12 years ago)

Author:

fielding@…

Message:

regenerate html, but needs appendix updates

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (43 diffs)
• p2-semantics.html (modified) (38 diffs)
• p3-payload.html (modified) (50 diffs)
• p4-conditional.html (modified) (6 diffs)
• p5-range.html (modified) (5 diffs)
• p6-cache.html (modified) (5 diffs)
• p7-auth.html (modified) (4 diffs)

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

@@ -858 +858 @@
       <div id="rfc.figure.u.12"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">request-header</a>  = &lt;request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>&gt;
   <a href="#abnf.dependencies" class="smpl">response-header</a> = &lt;response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>&gt;
-</pre><div id="rfc.figure.u.13"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">entity-header</a>   = &lt;entity-header, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>&gt;
-  <a href="#abnf.dependencies" class="smpl">MIME-Version</a>    = &lt;MIME-Version, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>&gt;
+</pre><div id="rfc.figure.u.13"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">MIME-Version</a>    = &lt;MIME-Version, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>&gt;
 </pre><div id="rfc.figure.u.14"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Cache-Control</a>   = &lt;Cache-Control, defined in <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
   <a href="#abnf.dependencies" class="smpl">Pragma</a>          = &lt;Pragma, defined in <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>&gt;
@@ -877 +876 @@
       <div id="rfc.iref.u.1"></div>
       <div id="rfc.iref.o.1"></div>
+      <div id="rfc.iref.b.1"></div>
+      <div id="rfc.iref.s.2"></div>
       <p id="rfc.section.2.1.p.2">Note that the terms client and server refer only to the roles that these programs perform for a particular connection. The
          same program might act as a client on some connections and a server on others. We use the term "user agent" to refer to the
          program that initiates a request, such as a WWW browser, editor, or spider (web-traversing robot), and the term "origin server"
-         to refer to the program that can originate authoritative responses to a request.
+         to refer to the program that can originate authoritative responses to a request. For general requirements, we use the term
+         "sender" to refer to whichever component sent a given message and the term "recipient" to refer to any component that receives
+         the message.
       </p>
       <p id="rfc.section.2.1.p.3">Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In
@@ -919 +922 @@
 
 <span id="exbody">Hello World!
-</span></pre><h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
+</span></pre><div id="rfc.iref.i.1"></div>
+      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="intermediaries" href="#intermediaries">Intermediaries</a></h2>
       <p id="rfc.section.2.2.p.1">A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three
          common forms of intermediary: proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server,
@@ -934 +938 @@
          at the same time that it is handling A's request.
       </p>
-      <p id="rfc.section.2.2.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span>  <span id="rfc.iref.i.1"></span><span id="rfc.iref.o.2"></span> We use the terms "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message:
+      <p id="rfc.section.2.2.p.4"> <span id="rfc.iref.u.2"></span><span id="rfc.iref.d.1"></span>  <span id="rfc.iref.i.2"></span><span id="rfc.iref.o.2"></span> We use the terms "upstream" and "downstream" to describe various requirements in relation to the directional flow of a message:
          all messages flow from upstream to downstream. Likewise, we use the terms "inbound" and "outbound" to refer to directions
          in relation to the request path: "inbound" means toward the origin server and "outbound" means toward the user agent.
@@ -946 +950 @@
       <p id="rfc.section.2.2.p.6"><span id="rfc.iref.g.24"></span><span id="rfc.iref.r.3"></span> A "gateway" (a.k.a., "reverse proxy") is a receiving agent that acts as a layer above some other server(s) and translates
          the received requests to the underlying server's protocol. Gateways are often used for load balancing or partitioning HTTP
-         services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the requested
+         services across multiple machines. Unlike a proxy, a gateway receives requests as if it were the origin server for the target
          resource; the requesting client will not be aware that it is communicating with a gateway. A gateway communicates with the
          client as if the gateway is the origin server and thus is subject to all of the requirements on origin servers for that connection.
@@ -1153 +1157 @@
          might introduce security flaws due to the differing ways that such parsers interpret invalid characters.
       </p>
+      <p id="rfc.section.3.1.p.4">HTTP allows the set of defined header fields to be extended without changing the protocol version (see <a href="#header.field.registration" title="Header Field Registration">Section&nbsp;10.1</a>). However, such fields might not be recognized by a downstream recipient and might be stripped by non-transparent intermediaries.
+         Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by transparent proxies and <em class="bcp14">SHOULD</em> be ignored by a recipient.
+      </p>
       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.fields" href="#header.fields">Header Fields</a></h2>
       <p id="rfc.section.3.2.p.1">Each HTTP header field consists of a case-insensitive field name followed by a colon (":"), optional whitespace, and the field
@@ -1305 +1312 @@
                  / <a href="#header.via" class="smpl">Via</a>                      ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;9.9</a>
                  / <a href="#abnf.dependencies" class="smpl">Warning</a>                  ; <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>
-                 / <a href="#abnf.dependencies" class="smpl">MIME-Version</a>             ; <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>
+                 / <a href="#abnf.dependencies" class="smpl">MIME-Version</a>             ; <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#mime-version" title="MIME-Version">Appendix A.1</a>
 </pre><p id="rfc.section.3.4.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
          or experimental header fields might be given the semantics of general header fields if all parties in the communication recognize
-         them to be general-header fields. Unrecognized header fields are treated as entity-header fields.
+         them to be general-header fields.
       </p>
       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="request" href="#request">Request</a></h1>
@@ -1315 +1322 @@
       </p>
       <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.46"></span>  <a href="#request" class="smpl">Request</a>       = <a href="#request-line" class="smpl">Request-Line</a>              ; <a href="#request-line" title="Request-Line">Section&nbsp;4.1</a>
-                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.4</a>
-                   / <a href="#abnf.dependencies" class="smpl">request-header</a>         ; <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>
-                   / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
+                  *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )    ; <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>
                   <a href="#core.rules" class="smpl">CRLF</a>
                   [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>
@@ -1347 +1352 @@
 </pre><p id="rfc.section.4.1.2.p.8">To allow for transition to absolute-URIs in all requests in future versions of HTTP, all HTTP/1.1 servers <em class="bcp14">MUST</em> accept the absolute-URI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
       </p>
-      <p id="rfc.section.4.1.2.p.9">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+      <p id="rfc.section.4.1.2.p.9">The authority form is only used by the CONNECT method (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 7.9</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
       <p id="rfc.section.4.1.2.p.10">The most common form of request-target is that used to identify a resource on an origin server or gateway. In this case the
@@ -1379 +1384 @@
       </div>
       <p id="rfc.section.4.1.2.p.19">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target
-         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
       </p>
       <p id="rfc.section.4.1.2.p.20">Various ad-hoc limitations on request-target length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support request-target lengths of 8000 or more octets.
@@ -1409 +1414 @@
       </p>
       <div id="rfc.iref.e.1"></div>
+      <div id="rfc.iref.t.2"></div>
       <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="effective.request.uri" href="#effective.request.uri">Effective Request URI</a></h2>
-      <p id="rfc.section.4.3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the resource they are intended for; instead, the value needs to be inferred from the request-target, Host header and
-         other context. The result of this process is the "Effective Request URI".
-      </p>
-      <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the Effective Request URI is the request-target.</p>
-      <p id="rfc.section.4.3.p.3">If the request-target uses the path-absolute (plus optional query) syntax or if it is just the asterisk "*", then the Effective
-         Request URI is constructed by concatenating
+      <p id="rfc.section.4.3.p.1">HTTP requests often do not carry the absolute URI (<a href="#RFC3986" id="rfc.xref.RFC3986.20"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.3">Section 4.3</a>) for the target resource; instead, the URI needs to be inferred from the request-target, Host header field, and connection
+         context. The result of this process is called the "effective request URI". The "target resource" is the resource identified
+         by the effective request URI.
+      </p>
+      <p id="rfc.section.4.3.p.2">If the request-target is an absolute-URI, then the effective request URI is the request-target.</p>
+      <p id="rfc.section.4.3.p.3">If the request-target uses the path-absolute (plus optional query) syntax or if it is just the asterisk "*", then the effective
+         request URI is constructed by concatenating
       </p>
       <p id="rfc.section.4.3.p.4"> </p>
@@ -1429 +1436 @@
       <p id="rfc.section.4.3.p.5">Otherwise, when request-target uses the authority form, the Effective Request URI is undefined.</p>
       <div id="rfc.figure.u.40"></div> 
-      <p>Example 1: the Effective Request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
+      <p>Example 1: the effective request URI for the message</p>  <pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
 Host: www.example.org:8080
 </pre>  <p>(received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus
@@ -1435 +1442 @@
       </p> 
       <div id="rfc.figure.u.41"></div> 
-      <p>Example 2: the Effective Request URI for the message</p>  <pre class="text">GET * HTTP/1.1
+      <p>Example 2: the effective request URI for the message</p>  <pre class="text">GET * HTTP/1.1
 Host: www.example.org
 </pre>  <p>(received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org",
          thus "https://www.example.org".
       </p> 
-      <p id="rfc.section.4.3.p.8">Effective Request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.6.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/".
+      <p id="rfc.section.4.3.p.8">Effective request URIs are compared using the rules described in <a href="#uri.comparison" title="http and https URI Normalization and Comparison">Section&nbsp;2.6.3</a>, except that empty path components <em class="bcp14">MUST NOT</em> be treated as equivalent to an absolute path of "/".
       </p>
       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="response" href="#response">Response</a></h1>
       <p id="rfc.section.5.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
       <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  <a href="#response" class="smpl">Response</a>      = <a href="#status-line" class="smpl">Status-Line</a>               ; <a href="#status-line" title="Status-Line">Section&nbsp;5.1</a>
-                  *(( <a href="#general.header.fields" class="smpl">general-header</a>        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;3.4</a>
-                   / <a href="#abnf.dependencies" class="smpl">response-header</a>        ; <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>
-                   / <a href="#abnf.dependencies" class="smpl">entity-header</a> ) <a href="#core.rules" class="smpl">CRLF</a> ) ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
+                  *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )    ; <a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>
                   <a href="#core.rules" class="smpl">CRLF</a>
                   [ <a href="#message.body" class="smpl">message-body</a> ]          ; <a href="#message.body" title="Message Body">Section&nbsp;3.3</a>
@@ -1458 +1463 @@
 </pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
       <p id="rfc.section.5.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
-         are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
+         are fully defined in <a href="p2-semantics.html#status.codes" title="Status Code Definitions">Section 8</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code,
          out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A
          client <em class="bcp14">SHOULD</em> ignore the content of the Reason Phrase.
@@ -1588 +1593 @@
       <h3 id="rfc.section.6.2.1"><a href="#rfc.section.6.2.1">6.2.1</a>&nbsp;<a id="chunked.encoding" href="#chunked.encoding">Chunked Transfer Coding</a></h3>
       <p id="rfc.section.6.2.1.p.1">The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size
-         indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing entity-header fields. This allows dynamically produced content to be transferred along with the information
-         necessary for the recipient to verify that it has received the full message.
+         indicator, followed by an <em class="bcp14">OPTIONAL</em> trailer containing header fields. This allows dynamically produced content to be transferred along with the information necessary
+         for the recipient to verify that it has received the full message.
       </p>
       <div id="rfc.figure.u.54"></div><pre class="inline"><span id="rfc.iref.g.79"></span><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span><span id="rfc.iref.g.86"></span><span id="rfc.iref.g.87"></span><span id="rfc.iref.g.88"></span><span id="rfc.iref.g.89"></span>  <a href="#chunked.encoding" class="smpl">Chunked-Body</a>   = *<a href="#chunked.encoding" class="smpl">chunk</a>
@@ -1606 +1611 @@
   <a href="#chunked.encoding" class="smpl">chunk-ext-val</a>  = <a href="#rule.token.separators" class="smpl">token</a> / <a href="#chunked.encoding" class="smpl">quoted-str-nf</a>
   <a href="#chunked.encoding" class="smpl">chunk-data</a>     = 1*<a href="#core.rules" class="smpl">OCTET</a> ; a sequence of chunk-size octets
-  <a href="#chunked.encoding" class="smpl">trailer-part</a>   = *( <a href="#abnf.dependencies" class="smpl">entity-header</a> <a href="#core.rules" class="smpl">CRLF</a> )
+  <a href="#chunked.encoding" class="smpl">trailer-part</a>   = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
   
   <a href="#chunked.encoding" class="smpl">quoted-str-nf</a>  = <a href="#core.rules" class="smpl">DQUOTE</a> *( <a href="#chunked.encoding" class="smpl">qdtext-nf</a> / <a href="#rule.quoted-pair" class="smpl">quoted-pair</a> ) <a href="#core.rules" class="smpl">DQUOTE</a>
@@ -1695 +1700 @@
          <li>Pointer to specification text</li>
       </ul>
-      <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;6.2.2</a>).
+      <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;6.2.2</a>).
       </p>
       <p id="rfc.section.6.2.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
@@ -1714 +1719 @@
       </p>
       <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h2>
-      <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
+      <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
          is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
          a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
@@ -1778 +1783 @@
       <p id="rfc.section.7.1.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
       </p>
-      <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
+      <p id="rfc.section.7.1.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to
          send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request.
       </p>
@@ -1846 +1851 @@
          </p> 
       </div>
-      <p id="rfc.section.7.1.3.2.p.8">A transparent proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
+      <p id="rfc.section.7.1.3.2.p.8">A transparent proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message-body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;6.2</a>).
       </p>
       <h3 id="rfc.section.7.1.4"><a href="#rfc.section.7.1.4">7.1.4</a>&nbsp;<a id="persistent.practical" href="#persistent.practical">Practical Considerations</a></h3>
@@ -1862 +1867 @@
       </p>
       <p id="rfc.section.7.1.4.p.4">This means that clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">SHOULD</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request
-         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
+         sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 7.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding
          of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails.
       </p>
@@ -1889 +1894 @@
       </p>
       <h3 id="rfc.section.7.2.3"><a href="#rfc.section.7.2.3">7.2.3</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3>
-      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
+      <p id="rfc.section.7.2.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 8.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
          to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either
          be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking
@@ -1896 +1901 @@
       <p id="rfc.section.7.2.3.p.2">Requirements for HTTP/1.1 clients: </p>
       <ul>
-         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
-         </li>
-         <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
+         <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.
+         </li>
+         <li>A client <em class="bcp14">MUST NOT</em> send an Expect request-header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 9.2</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.
          </li>
       </ul>
@@ -1942 +1947 @@
          <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include
             an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding
-            of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
+            of 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 8.1</a> of <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).
          </li>
       </ul>
@@ -1988 +1993 @@
       <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.field.definitions" href="#header.field.definitions">Header Field Definitions</a></h1>
       <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to message framing and transport protocols.</p>
-      <p id="rfc.section.9.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
-         receives the message.
-      </p>
       <div id="rfc.iref.c.11"></div>
       <div id="rfc.iref.h.6"></div>
@@ -2101 +2103 @@
       <p id="rfc.section.9.4.p.7">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">4.2</a> and <a href="#changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses">B.1.1</a> for other requirements relating to Host.
       </p>
-      <div id="rfc.iref.t.2"></div>
+      <div id="rfc.iref.t.3"></div>
       <div id="rfc.iref.h.11"></div>
       <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
@@ -2150 +2152 @@
          is always acceptable.
       </p>
-      <div id="rfc.iref.t.3"></div>
+      <div id="rfc.iref.t.4"></div>
       <div id="rfc.iref.h.12"></div>
       <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
@@ -2170 +2172 @@
          <li>Trailer</li>
       </ul>
-      <div id="rfc.iref.t.4"></div>
+      <div id="rfc.iref.t.5"></div>
       <div id="rfc.iref.h.13"></div>
       <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2>
       <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what transfer-codings (if any) have been applied to the message body.
-         It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
+         It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings
          are not.
       </p>
@@ -2183 +2185 @@
       </p>
       <div id="rfc.figure.u.71"></div><pre class="text">  Transfer-Encoding: chunked
-</pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other entity-header fields not defined by this specification.
+</pre><p id="rfc.section.9.7.p.5">If multiple encodings have been applied to a representation, the transfer-codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
       </p>
       <p id="rfc.section.9.7.p.6">Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.</p>
@@ -2866 +2868 @@
       </p>
       <p id="rfc.section.A.p.4">The character set of a representation <em class="bcp14">SHOULD</em> be labeled as the lowest common denominator of the character codes used within that representation, with the exception that
-         not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
+         not labeling the representation is preferred over labeling the representation with the labels US-ASCII or ISO-8859-1. See <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
       </p>
       <p id="rfc.section.A.p.5">Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:</p>
@@ -3008 +3010 @@
 <a href="#rule.whitespace" class="smpl">RWS</a> = 1*( [ obs-fold ] WSP )
 <a href="#status.code.and.reason.phrase" class="smpl">Reason-Phrase</a> = *( WSP / VCHAR / obs-text )
-<a href="#request" class="smpl">Request</a> = Request-Line *( ( general-header / request-header /
- entity-header ) CRLF ) CRLF [ message-body ]
+<a href="#request" class="smpl">Request</a> = Request-Line *( header-field CRLF ) CRLF [ message-body ]
 <a href="#request-line" class="smpl">Request-Line</a> = Method SP request-target SP HTTP-Version CRLF
-<a href="#response" class="smpl">Response</a> = Status-Line *( ( general-header / response-header /
- entity-header ) CRLF ) CRLF [ message-body ]
+<a href="#response" class="smpl">Response</a> = Status-Line *( header-field CRLF ) CRLF [ message-body ]
 
 <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = 3DIGIT
@@ -3073 +3073 @@
  / %x53.75.6E.64.61.79 ; Sunday
 
-<a href="#abnf.dependencies" class="smpl">entity-header</a> = &lt;entity-header, defined in [Part3], Section 3.1&gt;
-
 <a href="#header.fields" class="smpl">field-content</a> = *( WSP / VCHAR / obs-text )
 <a href="#header.fields" class="smpl">field-name</a> = token
@@ -3153 +3151 @@
 <a href="#preferred.date.format" class="smpl">time-of-day</a> = hour ":" minute ":" second
 <a href="#rule.token.separators" class="smpl">token</a> = 1*tchar
-<a href="#chunked.encoding" class="smpl">trailer-part</a> = *( entity-header CRLF )
+<a href="#chunked.encoding" class="smpl">trailer-part</a> = *( header-field CRLF )
 <a href="#transfer.codings" class="smpl">transfer-coding</a> = "chunked" / "compress" / "deflate" / "gzip" /
  transfer-extension
@@ -3440 +3438 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>&gt;: "Handling multiple Content-Length headers"
          </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>&gt;: "Clarify entity / representation / variant terminology"
+         </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "consider removing the 'changes from 2068' sections"
          </li>
@@ -3459 +3459 @@
             <li class="indline0"><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul class="ind">
                   <li class="indline1"><em>BCP97</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.BCP97.1">13.1</a>, <a class="iref" href="#rfc.xref.BCP97.2">13.1</a>, <a class="iref" href="#rfc.xref.BCP97.3">13.1</a>, <a class="iref" href="#BCP97"><b>13.2</b></a></li>
+                  <li class="indline1">browser&nbsp;&nbsp;<a class="iref" href="#rfc.iref.b.1"><b>2.1</b></a></li>
                </ul>
             </li>
             <li class="indline0"><a id="rfc.index.C" href="#rfc.index.C"><b>C</b></a><ul class="ind">
-                  <li class="indline1">cache&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.3">2.3</a></li>
-                  <li class="indline1">cacheable&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.4">2.3</a></li>
+                  <li class="indline1">cache&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.3"><b>2.3</b></a></li>
+                  <li class="indline1">cacheable&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.4"><b>2.3</b></a></li>
                   <li class="indline1">chunked (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.5">6.2.1</a></li>
-                  <li class="indline1">client&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.1">2.1</a></li>
+                  <li class="indline1">client&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.1"><b>2.1</b></a></li>
                   <li class="indline1">Coding Format&nbsp;&nbsp;
                      <ul class="ind">
@@ -3475 +3476 @@
                   </li>
                   <li class="indline1">compress (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.7">6.2.2.1</a></li>
-                  <li class="indline1">connection&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2">2.1</a></li>
+                  <li class="indline1">connection&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2"><b>2.1</b></a></li>
                   <li class="indline1">Connection header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.connection.1">3.4</a>, <a class="iref" href="#rfc.xref.header.connection.2">7.1.2</a>, <a class="iref" href="#rfc.xref.header.connection.3">7.1.3</a>, <a class="iref" href="#rfc.xref.header.connection.4">7.1.3.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.header.connection.5">9.5</a>, <a class="iref" href="#rfc.xref.header.connection.6">9.8</a>, <a class="iref" href="#rfc.xref.header.connection.7">10.1</a>, <a class="iref" href="#rfc.xref.header.connection.8">B.2</a>, <a class="iref" href="#rfc.xref.header.connection.9">B.3</a></li>
                   <li class="indline1">Content-Length header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-length.1">3.3</a>, <a class="iref" href="#rfc.iref.c.12"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.header.content-length.2">10.1</a></li>
@@ -3483 +3484 @@
                   <li class="indline1">Date header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.date.1">3.4</a>, <a class="iref" href="#rfc.iref.d.3"><b>9.3</b></a>, <a class="iref" href="#rfc.xref.header.date.2">10.1</a></li>
                   <li class="indline1">deflate (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.2">6.2.2.2</a></li>
-                  <li class="indline1">downstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1">2.2</a></li>
+                  <li class="indline1">downstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1"><b>2.2</b></a></li>
                </ul>
             </li>
             <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind">
-                  <li class="indline1">Effective Request URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.e.1"><b>4.3</b></a></li>
+                  <li class="indline1">effective request URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.e.1"><b>4.3</b></a></li>
                </ul>
             </li>
             <li class="indline0"><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul class="ind">
-                  <li class="indline1">gateway&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24">2.2</a></li>
+                  <li class="indline1">gateway&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>2.2</b></a></li>
                   <li class="indline1"><tt>Grammar</tt>&nbsp;&nbsp;
                      <ul class="ind">
@@ -3640 +3641 @@
             </li>
             <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind">
-                  <li class="indline1">inbound&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1">2.2</a></li>
+                  <li class="indline1">inbound&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.2"><b>2.2</b></a></li>
+                  <li class="indline1">intermediary&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1"><b>2.2</b></a></li>
                   <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">3.2</a>, <a class="iref" href="#ISO-8859-1"><b>13.1</b></a></li>
                </ul>
@@ -3655 +3657 @@
                      </ul>
                   </li>
-                  <li class="indline1">message&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.1">2.1</a></li>
+                  <li class="indline1">message&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.1"><b>2.1</b></a></li>
                   <li class="indline1">message/http Media Type&nbsp;&nbsp;<a class="iref" href="#rfc.iref.m.3"><b>10.3.1</b></a></li>
                </ul>
@@ -3664 +3666 @@
             </li>
             <li class="indline0"><a id="rfc.index.O" href="#rfc.index.O"><b>O</b></a><ul class="ind">
-                  <li class="indline1">origin server&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.1">2.1</a></li>
-                  <li class="indline1">outbound&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.2">2.2</a></li>
+                  <li class="indline1">origin server&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.1"><b>2.1</b></a></li>
+                  <li class="indline1">outbound&nbsp;&nbsp;<a class="iref" href="#rfc.iref.o.2"><b>2.2</b></a></li>
                </ul>
             </li>
             <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
                   <li class="indline1"><em>Pad1995</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Pad1995.1">7.1.1</a>, <a class="iref" href="#Pad1995"><b>13.2</b></a></li>
-                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4</a>, <a class="iref" href="#rfc.xref.Part2.4">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.5">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a>, <a class="iref" href="#rfc.xref.Part2.7">5.1.1</a>, <a class="iref" href="#rfc.xref.Part2.8">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.10">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.13">7.2.3</a>, <a class="iref" href="#Part2"><b>13.1</b></a><ul class="ind">
-                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4</a></li>
-                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.6">5</a></li>
-                        <li class="indline1"><em>Section 7.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.9">7.1.4</a></li>
-                        <li class="indline1"><em>Section 7.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.4">4.1.2</a></li>
-                        <li class="indline1"><em>Section 8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.7">5.1.1</a></li>
-                        <li class="indline1"><em>Section 8.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.10">7.2.3</a></li>
-                        <li class="indline1"><em>Section 8.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.13">7.2.3</a></li>
-                        <li class="indline1"><em>Section 8.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.5">4.1.2</a></li>
-                        <li class="indline1"><em>Section 9.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.12">7.2.3</a></li>
+                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part2.3">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.4">4.1.2</a>, <a class="iref" href="#rfc.xref.Part2.5">5.1.1</a>, <a class="iref" href="#rfc.xref.Part2.6">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.7">7.1.4</a>, <a class="iref" href="#rfc.xref.Part2.8">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.9">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.10">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.11">7.2.3</a>, <a class="iref" href="#Part2"><b>13.1</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">1.2.3</a></li>
+                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">1.2.3</a></li>
+                        <li class="indline1"><em>Section 7.1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.6">7.1.2.2</a>, <a class="iref" href="#rfc.xref.Part2.7">7.1.4</a></li>
+                        <li class="indline1"><em>Section 7.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.3">4.1.2</a></li>
+                        <li class="indline1"><em>Section 8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.5">5.1.1</a></li>
+                        <li class="indline1"><em>Section 8.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.8">7.2.3</a></li>
+                        <li class="indline1"><em>Section 8.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.11">7.2.3</a></li>
+                        <li class="indline1"><em>Section 8.4.15</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.4">4.1.2</a></li>
+                        <li class="indline1"><em>Section 9.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.9">7.2.3</a>, <a class="iref" href="#rfc.xref.Part2.10">7.2.3</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">3.4</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a>, <a class="iref" href="#rfc.xref.Part3.7">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.8">6.4</a>, <a class="iref" href="#rfc.xref.Part3.9">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.10">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.11">A</a><ul class="ind">
-                        <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.7">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.10">9.7</a></li>
-                        <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">5</a></li>
-                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.8">6.4</a></li>
+                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">3.4</a>, <a class="iref" href="#rfc.xref.Part3.4">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.5">6.4</a>, <a class="iref" href="#rfc.xref.Part3.6">7.1.3.2</a>, <a class="iref" href="#rfc.xref.Part3.7">9.7</a>, <a class="iref" href="#Part3"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part3.8">A</a><ul class="ind">
+                        <li class="indline1"><em>Section 2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">6.2.3</a>, <a class="iref" href="#rfc.xref.Part3.7">9.7</a></li>
+                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">6.4</a></li>
                         <li class="indline1"><em>Appendix A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a></li>
-                        <li class="indline1"><em>Appendix A.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.4">3.4</a></li>
+                        <li class="indline1"><em>Appendix A.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.3</a>, <a class="iref" href="#rfc.xref.Part3.3">3.4</a></li>
                      </ul>
                   </li>
@@ -3698 +3699 @@
                      </ul>
                   </li>
-                  <li class="indline1">proxy&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1">2.2</a></li>
+                  <li class="indline1">proxy&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1"><b>2.2</b></a></li>
                </ul>
             </li>
             <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind">
-                  <li class="indline1">request&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.1">2.1</a></li>
+                  <li class="indline1">request&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.1"><b>2.1</b></a></li>
                   <li class="indline1">resource&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.4"><b>2.6</b></a></li>
-                  <li class="indline1">response&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.2">2.1</a></li>
-                  <li class="indline1">reverse proxy&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.3">2.2</a></li>
+                  <li class="indline1">response&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.2"><b>2.1</b></a></li>
+                  <li class="indline1">reverse proxy&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.3"><b>2.2</b></a></li>
                   <li class="indline1"><em>RFC1123</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1123.1">6.1</a>, <a class="iref" href="#RFC1123"><b>13.2</b></a></li>
                   <li class="indline1"><em>RFC1305</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1305.1">9.3</a>, <a class="iref" href="#RFC1305"><b>13.2</b></a></li>
@@ -3767 +3768 @@
             </li>
             <li class="indline0"><a id="rfc.index.S" href="#rfc.index.S"><b>S</b></a><ul class="ind">
-                  <li class="indline1">server&nbsp;&nbsp;<a class="iref" href="#rfc.iref.s.1">2.1</a></li>
+                  <li class="indline1">server&nbsp;&nbsp;<a class="iref" href="#rfc.iref.s.1"><b>2.1</b></a></li>
                   <li class="indline1"><em>Spe</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Spe.1">7.1.1</a>, <a class="iref" href="#Spe"><b>13.2</b></a></li>
+                  <li class="indline1">spider&nbsp;&nbsp;<a class="iref" href="#rfc.iref.s.2"><b>2.1</b></a></li>
                </ul>
             </li>
             <li class="indline0"><a id="rfc.index.T" href="#rfc.index.T"><b>T</b></a><ul class="ind">
-                  <li class="indline1">TE header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.t.2"><b>9.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">10.1</a></li>
+                  <li class="indline1">target resource&nbsp;&nbsp;<a class="iref" href="#rfc.iref.t.2"><b>4.3</b></a></li>
+                  <li class="indline1">TE header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.te.1">6.2</a>, <a class="iref" href="#rfc.xref.header.te.2">6.2.1</a>, <a class="iref" href="#rfc.xref.header.te.3">6.4</a>, <a class="iref" href="#rfc.iref.t.3"><b>9.5</b></a>, <a class="iref" href="#rfc.xref.header.te.4">10.1</a></li>
                   <li class="indline1"><em>Tou1998</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Tou1998.1">7.1.1</a>, <a class="iref" href="#Tou1998"><b>13.2</b></a></li>
-                  <li class="indline1">Trailer header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.4</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.t.3"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li>
-                  <li class="indline1">Transfer-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.t.4"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>
-                  <li class="indline1">tunnel&nbsp;&nbsp;<a class="iref" href="#rfc.iref.t.1">2.2</a></li>
+                  <li class="indline1">Trailer header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.trailer.1">3.4</a>, <a class="iref" href="#rfc.xref.header.trailer.2">6.2.1</a>, <a class="iref" href="#rfc.iref.t.4"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.trailer.3">10.1</a></li>
+                  <li class="indline1">Transfer-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.2">3.3</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.3">3.4</a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.4">6.2</a>, <a class="iref" href="#rfc.iref.t.5"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.transfer-encoding.5">10.1</a></li>
+                  <li class="indline1">tunnel&nbsp;&nbsp;<a class="iref" href="#rfc.iref.t.1"><b>2.2</b></a></li>
                </ul>
             </li>
             <li class="indline0"><a id="rfc.index.U" href="#rfc.index.U"><b>U</b></a><ul class="ind">
                   <li class="indline1">Upgrade header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.upgrade.1">3.4</a>, <a class="iref" href="#rfc.iref.u.5"><b>9.8</b></a>, <a class="iref" href="#rfc.xref.header.upgrade.2">10.1</a></li>
-                  <li class="indline1">upstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.2">2.2</a></li>
+                  <li class="indline1">upstream&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.2"><b>2.2</b></a></li>
                   <li class="indline1">URI scheme&nbsp;&nbsp;
                      <ul class="ind">
@@ -3789 +3792 @@
                   </li>
                   <li class="indline1"><em>USASCII</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.USASCII.1">1.2</a>, <a class="iref" href="#rfc.xref.USASCII.2">3.2</a>, <a class="iref" href="#USASCII"><b>13.1</b></a></li>
-                  <li class="indline1">user agent&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.1">2.1</a></li>
+                  <li class="indline1">user agent&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.1"><b>2.1</b></a></li>
                </ul>
             </li>

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

@@ -684 +684 @@
          to each request, in the order received on that connection, with one or more HTTP response messages. This document defines
          the commonly agreed upon semantics of the HTTP uniform interface, the intentions defined by each request method, and the various
-         response messages that might be expected as a result of applying that method for the requested resource.
+         response messages that might be expected as a result of applying that method to the target resource.
       </p>
       <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
@@ -726 +726 @@
   <a href="#abnf.dependencies" class="smpl">TE</a>            = &lt;TE, defined in <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.te" title="TE">Section 9.5</a>&gt;
   <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>&gt;
-</pre><div id="rfc.figure.u.3"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Accept</a>        = &lt;Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>&gt;
+</pre><div id="rfc.figure.u.3"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">Accept</a>        = &lt;Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>&gt;
   <a href="#abnf.dependencies" class="smpl">Accept-Charset</a> =
-             &lt;Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>&gt;
+             &lt;Accept-Charset, defined in <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a>&gt;
   <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a> =
-             &lt;Accept-Encoding, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>&gt;
+             &lt;Accept-Encoding, defined in <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a>&gt;
   <a href="#abnf.dependencies" class="smpl">Accept-Language</a> =
-             &lt;Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>&gt;
+             &lt;Accept-Language, defined in <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a>&gt;
 </pre><div id="rfc.figure.u.4"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">ETag</a>          = &lt;ETag, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a>&gt;
   <a href="#abnf.dependencies" class="smpl">If-Match</a>      = &lt;If-Match, defined in <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a>&gt;
@@ -753 +753 @@
              &lt;WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>&gt;
 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
-      <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
+      <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
       </p>
       <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#method" class="smpl">Method</a>         = %x4F.50.54.49.4F.4E.53   ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section&nbsp;7.2</a>
@@ -765 +765 @@
                  / <a href="#method" class="smpl">extension-method</a>
   <a href="#method" class="smpl">extension-method</a> = <a href="#core.rules" class="smpl">token</a>
-</pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;9.1</a>). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the
-         set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested
+</pre><p id="rfc.section.2.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;9.1</a>). The status code of the response always notifies the client whether a method is currently allowed on a resource, since the
+         set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> respond with the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the
          resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. The methods GET
          and HEAD <em class="bcp14">MUST</em> be supported by all general-purpose servers. All other methods are <em class="bcp14">OPTIONAL</em>; however, if the above methods are implemented, they <em class="bcp14">MUST</em> be implemented with the same semantics as those specified in <a href="#method.definitions" title="Method Definitions">Section&nbsp;7</a>.
@@ -790 +790 @@
          method invocation.
       </p>
-      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#request.header.fields" class="smpl">request-header</a> = <a href="#abnf.dependencies" class="smpl">Accept</a>                   ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>
-                 / <a href="#abnf.dependencies" class="smpl">Accept-Charset</a>           ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>
-                 / <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a>          ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>
-                 / <a href="#abnf.dependencies" class="smpl">Accept-Language</a>          ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>
+      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#request.header.fields" class="smpl">request-header</a> = <a href="#abnf.dependencies" class="smpl">Accept</a>                   ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>
+                 / <a href="#abnf.dependencies" class="smpl">Accept-Charset</a>           ; <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a>
+                 / <a href="#abnf.dependencies" class="smpl">Accept-Encoding</a>          ; <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a>
+                 / <a href="#abnf.dependencies" class="smpl">Accept-Language</a>          ; <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a>
                  / <a href="#abnf.dependencies" class="smpl">Authorization</a>            ; <a href="#Part7" id="rfc.xref.Part7.5"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a>
                  / <a href="#header.expect" class="smpl">Expect</a>                   ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;9.2</a>
@@ -811 +811 @@
 </pre><p id="rfc.section.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
          or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields.
-         Unrecognized header fields are treated as entity-header fields.
       </p>
       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h1>
@@ -883 +882 @@
       <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
          Status-Line. These header fields give information about the server and about further access to the resource identified by
-         the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
+         the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
       </p>
       <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a>           ; <a href="#Part5" id="rfc.xref.Part5.9"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a>
@@ -897 +896 @@
 </pre><p id="rfc.section.5.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new
          or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header
-         fields. Unrecognized header fields are treated as entity-header fields.
+         fields.
       </p>
       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
@@ -908 +907 @@
       </p>
       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="identifying.response.associated.with.representation" href="#identifying.response.associated.with.representation">Identifying the Resource Associated with a Representation</a></h2>
-      <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine the identity of the resource associated with a representation.</p>
+      <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
       <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
-      <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the Effective Request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
+      <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the effective request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
          rules are used (with the first applicable one being selected):
       </p>
       <ol>
-         <li>If the response status code is 200 or 203 and the request method was GET, the response is a representation of the resource
-            at the Effective Request URI.
-         </li>
-         <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation
-            of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
-         </li>
-         <li>If the response has a Content-Location header, and that URI is the same as the Effective Request URI, the response is a representation
-            of the resource at the Effective Request URI.
-         </li>
-         <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts
-            that it is a representation of the resource at the Content-Location URI (but it might not be).
+         <li>If the response status code is 200 or 203 and the request method was GET, the response payload is a representation of the
+            resource identified by the effective request URI.
+         </li>
+         <li>If the response status code is 204, 206, or 304 and the request method was GET or HEAD, the response payload is a partial
+            representation of the resource identified by the effective request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.8</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
+         </li>
+         <li>If the response has a Content-Location header, and that URI is the same as the effective request URI, the response payload
+            is a representation of the resource identified by the effective request URI.
+         </li>
+         <li>If the response has a Content-Location header, and that URI is not the same as the effective request URI, then the response
+            asserts that its payload is a representation of the resource identified by the Content-Location URI. However, such an assertion
+            cannot be trusted unless it can be verified by other means (not defined by HTTP).
          </li>
          <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
@@ -960 +960 @@
       <div id="rfc.iref.m.1"></div>
       <p id="rfc.section.7.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response
-         chain identified by the Effective Request URI. This method allows the client to determine the options and/or requirements
+         chain identified by the effective request URI. This method allows the client to determine the options and/or requirements
          associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
       </p>
@@ -986 +986 @@
       <div id="rfc.iref.m.2"></div>
       <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of a representation) currently corresponds to the resource
-         identified by the Effective Request URI.
-      </p>
-      <p id="rfc.section.7.3.p.2">If the Effective Request URI identifies a data-producing process, it is the produced data which shall be returned as the representation
+         identified by the effective request URI.
+      </p>
+      <p id="rfc.section.7.3.p.2">If the effective request URI identifies a data-producing process, it is the produced data which shall be returned as the representation
          in the response and not the source text of the process, unless that text happens to be the output of the process.
       </p>
@@ -1020 +1020 @@
       <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
       <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the representation enclosed in the request as data to be
-         processed by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the
+         processed by the resource identified by the effective request URI. POST is designed to allow a uniform method to cover the
          following functions: 
       </p>
@@ -1029 +1029 @@
          <li>Extending a database through an append operation.</li>
       </ul>
-      <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Effective Request
+      <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the effective request
          URI.
       </p>
@@ -1039 +1039 @@
          a Location header (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section&nbsp;9.4</a>).
       </p>
-      <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
+      <p id="rfc.section.7.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the Effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.
       </p>
       <p id="rfc.section.7.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent
@@ -1047 +1047 @@
       <div id="rfc.iref.m.5"></div>
       <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h2>
-      <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed representation be stored at the Effective Request URI. If the Effective Request
-         URI refers to an already existing resource, the enclosed representation <em class="bcp14">SHOULD</em> be considered a modified version of the one residing on the origin server. Otherwise, if the Effective Request URI does not
+      <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed representation be stored at the effective request URI. If the effective request
+         URI refers to an already existing resource, the enclosed representation <em class="bcp14">SHOULD</em> be considered a modified version of the one residing on the origin server. Otherwise, if the effective request URI does not
          point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the
          origin server can create the resource with that URI.
       </p>
-      <p id="rfc.section.7.6.p.2">If a new resource is created at the Effective Request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No
+      <p id="rfc.section.7.6.p.2">If a new resource is created at the effective request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No
          Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
       </p>
-      <p id="rfc.section.7.6.p.3">If the resource identified by the Effective Request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
-      </p>
-      <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the Effective Request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
-      </p>
-      <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request
+      <p id="rfc.section.7.6.p.3">If the resource identified by the effective request URI could not be created or modified, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the representation <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
+      </p>
+      <p id="rfc.section.7.6.p.4">If the request passes through a cache that has one or more stored responses for the effective request URI, those stored responses <em class="bcp14">SHOULD</em> be marked as stale if the response to the PUT request has a success status code. Responses to the PUT method are not cacheable.
+      </p>
+      <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the effective request
          URI. The URI in a POST request identifies the resource that will handle the enclosed representation. That resource might be
          a data-accepting process, a gateway to some other protocol, or a document that accepts annotations. In contrast, the URI in
@@ -1071 +1071 @@
       </p>
       <p id="rfc.section.7.6.p.7">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p>
-      <p id="rfc.section.7.6.p.8">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT.
+      <p id="rfc.section.7.6.p.8">Header fields in a PUT request that are recognized as representation metadata <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored.
       </p>
       <div id="rfc.iref.d.1"></div>
       <div id="rfc.iref.m.6"></div>
       <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h2>
-      <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Effective Request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
+      <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the effective request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
          has been carried out, even if the status code returned from the origin server indicates that the action has been completed
          successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible
@@ -1084 +1084 @@
          enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation.
       </p>
-      <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Effective Request URI identifies one or more currently cached representations,
+      <p id="rfc.section.7.7.p.3">If the request passes through a cache and the effective request URI identifies one or more currently cached representations,
          those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to the DELETE method are not cacheable.
       </p>
@@ -1143 +1143 @@
       <div id="rfc.iref.s.4"></div>
       <h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a>&nbsp;<a id="status.200" href="#status.200">200 OK</a></h3>
-      <p id="rfc.section.8.2.1.p.1">The request has succeeded. The information returned with the response is dependent on the method used in the request, for
-         example: 
-      </p>
+      <p id="rfc.section.8.2.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>
       <dl>
          <dt>GET</dt>
-         <dd>a representation corresponding to the requested resource is sent in the response;</dd>
+         <dd>a representation of the resource corresponding to the effective request URI is sent in the response;</dd>
          <dt>HEAD</dt>
-         <dd>the entity-header fields corresponding to the requested resource are sent in the response without any message-body;</dd>
+         <dd>the same representation as GET, except without the message-body;</dd>
          <dt>POST</dt>
          <dd>a representation describing or containing the result of the action;</dd>
@@ -1185 +1183 @@
       <div id="rfc.iref.s.7"></div>
       <h3 id="rfc.section.8.2.4"><a href="#rfc.section.8.2.4">8.2.4</a>&nbsp;<a id="status.203" href="#status.203">203 Non-Authoritative Information</a></h3>
-      <p id="rfc.section.8.2.4.p.1">The returned metadata in the entity-header is not the definitive set as available from the origin server, but is gathered
+      <p id="rfc.section.8.2.4.p.1">The returned metadata in the header fields is not the definitive set as available from the origin server, but is gathered
          from a local or a third-party copy. The set presented <em class="bcp14">MAY</em> be a subset or superset of the original version. For example, including local annotation information about the resource might
          result in a superset of the metadata known by the origin server. Use of this response code is not required and is only appropriate
@@ -1196 +1194 @@
       <h3 id="rfc.section.8.2.5"><a href="#rfc.section.8.2.5">8.2.5</a>&nbsp;<a id="status.204" href="#status.204">204 No Content</a></h3>
       <p id="rfc.section.8.2.5.p.1">The server has successfully fulfilled the request, but there is no additional content to return in the response payload body.
-         The resource metadata and representation metadata in the response message's header fields refer to the requested resource
-         and its current representation, respectively, after the requested action. For example, if a 204 status code is received in
-         response to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for
-         the representation that was successfully PUT to the requested resource.
+         The resource metadata and representation metadata in the response message's header fields refer to the target resource and
+         its current representation, respectively, after the requested action. For example, if a 204 status code is received in response
+         to a PUT and the response contains an ETag header field, then the value of that field is the current entity-tag for the representation
+         that was successfully PUT.
       </p>
       <p id="rfc.section.8.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input
@@ -1233 +1231 @@
       <div id="rfc.iref.s.11"></div>
       <h3 id="rfc.section.8.3.1"><a href="#rfc.section.8.3.1">8.3.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
-      <p id="rfc.section.8.3.1.p.1">The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven
-         negotiation information (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that
+      <p id="rfc.section.8.3.1.p.1">The target resource more than one representation, each with its own specific location, and agent-driven negotiation information
+         (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that
          location.
       </p>
-      <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of resource characteristics and location(s) from which the user or user agent can
+      <p id="rfc.section.8.3.1.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of representation metadata and location(s) from which the user or user agent can
          choose the one most appropriate. The data format is specified by the media type given in the Content-Type header field. Depending
          upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection.
@@ -1248 +1246 @@
       <div id="rfc.iref.s.12"></div>
       <h3 id="rfc.section.8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;<a id="status.301" href="#status.301">301 Moved Permanently</a></h3>
-      <p id="rfc.section.8.3.2.p.1">The requested 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
-         Request URI to one or more of the new references returned by the server, where possible.
+      <p id="rfc.section.8.3.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
+         request URI to one or more of the new references returned by the server, where possible.
       </p>
       <p id="rfc.section.8.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.13"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.
@@ -1266 +1264 @@
       <div id="rfc.iref.s.13"></div>
       <h3 id="rfc.section.8.3.3"><a href="#rfc.section.8.3.3">8.3.3</a>&nbsp;<a id="status.302" href="#status.302">302 Found</a></h3>
-      <p id="rfc.section.8.3.3.p.1">The requested 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.
+      <p id="rfc.section.8.3.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.
       </p>
       <p id="rfc.section.8.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
@@ -1285 +1282 @@
       <p id="rfc.section.8.3.4.p.1">The server directs the user agent to a different resource, indicated by a URI in the Location header field, that provides
          an indirect response to the original request. The user agent <em class="bcp14">MAY</em> perform a GET request on the URI in the Location field in order to obtain a representation corresponding to the response,
-         be redirected again, or end with an error status. The Location URI is not a substitute reference for the originally requested
-         resource.
+         be redirected again, or end with an error status. The Location URI is not a substitute reference for the effective request
+         URI.
       </p>
       <p id="rfc.section.8.3.4.p.2">The 303 status code is generally applicable to any HTTP method. It is primarily used to allow the output of a POST action
@@ -1293 +1290 @@
       </p>
       <p id="rfc.section.8.3.4.p.3">A 303 response to a GET request indicates that the requested resource does not have a representation of its own that can be
-         transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the requested resource such
-         that the follow-on representation might be useful without implying that it adequately represents the previously requested
+         transferred by the server over HTTP. The Location URI indicates a resource that is descriptive of the target resource, such
+         that the follow-on representation might be useful to recipients without implying that it adequately represents the target
          resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might
          be a useful description are outside the scope of HTTP and thus entirely determined by the URI owner(s).
@@ -1318 +1315 @@
       <div id="rfc.iref.s.18"></div>
       <h3 id="rfc.section.8.3.8"><a href="#rfc.section.8.3.8">8.3.8</a>&nbsp;<a id="status.307" href="#status.307">307 Temporary Redirect</a></h3>
-      <p id="rfc.section.8.3.8.p.1">The requested 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.
+      <p id="rfc.section.8.3.8.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.
       </p>
       <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand
@@ -1360 +1357 @@
       <div id="rfc.iref.s.23"></div>
       <h3 id="rfc.section.8.4.5"><a href="#rfc.section.8.4.5">8.4.5</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
-      <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the Effective Request URI. No indication is given of whether the condition is temporary
+      <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the effective request URI. No indication is given of whether the condition is temporary
          or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable
          and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request
@@ -1368 +1365 @@
       <div id="rfc.iref.s.24"></div>
       <h3 id="rfc.section.8.4.6"><a href="#rfc.section.8.4.6">8.4.6</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
-      <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the Effective Request URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.
+      <p id="rfc.section.8.4.6.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 Allow header containing a list of valid methods for the requested resource.
       </p>
       <div id="rfc.iref.48"></div>
@@ -1414 +1411 @@
       <div id="rfc.iref.s.29"></div>
       <h3 id="rfc.section.8.4.11"><a href="#rfc.section.8.4.11">8.4.11</a>&nbsp;<a id="status.410" href="#status.410">410 Gone</a></h3>
-      <p id="rfc.section.8.4.11.p.1">The requested resource is no longer available at the server and no forwarding address is known. This condition is expected
-         to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the Effective Request URI after user approval. If the server does not know, or has no facility to determine,
+      <p id="rfc.section.8.4.11.p.1">The target resource is no longer available at the server and no forwarding address is known. This condition is expected to
+         be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the effective request URI after user approval. If the server does not know, or has no facility to determine,
          whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead.
       </p>
@@ -1449 +1446 @@
       <div id="rfc.iref.s.33"></div>
       <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h3>
-      <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the Effective Request URI is longer than the server is willing to interpret.
+      <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the effective request URI is longer than the server is willing to interpret.
          This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long
          query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that
          points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present
-         in some servers using fixed-length buffers for reading or manipulating the Effective Request URI.
+         in some servers using fixed-length buffers for reading or manipulating the effective request URI.
       </p>
       <div id="rfc.iref.57"></div>
@@ -1459 +1456 @@
       <h3 id="rfc.section.8.4.16"><a href="#rfc.section.8.4.16">8.4.16</a>&nbsp;<a id="status.415" href="#status.415">415 Unsupported Media Type</a></h3>
       <p id="rfc.section.8.4.16.p.1">The server is refusing to service the request because the representation of the request is in a format not supported by the
-         requested resource for the requested method.
+         target resource for the requested method.
       </p>
       <div id="rfc.iref.58"></div>
@@ -1523 +1520 @@
       <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
       <p id="rfc.section.9.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to request and response semantics.</p>
-      <p id="rfc.section.9.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
-         receives the message.
-      </p>
       <div id="rfc.iref.a.1"></div>
       <div id="rfc.iref.h.2"></div>
       <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
-      <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the Effective
-         Request URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource.
+      <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the target resource. The purpose of
+         this field is strictly to inform the recipient of valid methods associated with the resource.
       </p>
       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.allow" class="smpl">Allow</a>   = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a>
@@ -1615 +1609 @@
       </div>
       <div class="note" id="rfc.section.9.4.p.9"> 
-         <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
+         <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.
             It is therefore possible for a response to contain header fields for both Location and Content-Location.
          </p> 
@@ -1636 +1630 @@
       <div id="rfc.iref.h.7"></div>
       <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
-      <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the Effective Request
+      <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the effective request
          URI was obtained (the "referrer", although the header field is misspelled.).
       </p>
@@ -1644 +1638 @@
          contain a Referer header field.
       </p>
-      <p id="rfc.section.9.6.p.3">If the Effective Request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard),
+      <p id="rfc.section.9.6.p.3">If the effective request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard),
          the Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with
          non-HTTP URIs (e.g., FTP).
@@ -1652 +1646 @@
 </pre><p id="rfc.section.9.6.p.5">Example:</p>
       <div id="rfc.figure.u.22"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
-</pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Effective Request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations.
+</pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the effective request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations.
       </p>
       <div id="rfc.iref.r.2"></div>
@@ -2259 +2253 @@
          user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">8.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">8.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.4" title="307 Temporary Redirect">8.3.8</a>)
       </p>
-      <p id="rfc.section.A.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the requested resource
+      <p id="rfc.section.A.p.4">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource
          must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient
          was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;8.3.6</a>)
@@ -2759 +2753 @@
                   </li>
                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a>, <a class="iref" href="#rfc.xref.Part3.9">6</a>, <a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.11">8.3.1</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a>, <a class="iref" href="#Part3"><b>13.1</b></a><ul class="ind">
-                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.11">8.3.1</a></li>
-                        <li class="indline1"><em>Section 5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a></li>
-                        <li class="indline1"><em>Section 5.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a></li>
-                        <li class="indline1"><em>Section 5.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a></li>
-                        <li class="indline1"><em>Section 5.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a></li>
-                        <li class="indline1"><em>Section 5.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a></li>
+                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.11">8.3.1</a></li>
+                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.5">3</a></li>
+                        <li class="indline1"><em>Section 6.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.6">3</a></li>
+                        <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.7">3</a></li>
+                        <li class="indline1"><em>Section 6.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">1.2.2</a>, <a class="iref" href="#rfc.xref.Part3.8">3</a></li>
+                        <li class="indline1"><em>Section 6.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.10">7.5</a>, <a class="iref" href="#rfc.xref.Part3.12">9.4</a></li>
                      </ul>
                   </li>

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

@@ -377 +377 @@
       <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">
       <link rel="Chapter" title="2 Protocol Parameters" href="#rfc.section.2">
-      <link rel="Chapter" title="3 Representation" href="#rfc.section.3">
-      <link rel="Chapter" title="4 Content Negotiation" href="#rfc.section.4">
-      <link rel="Chapter" title="5 Header Field Definitions" href="#rfc.section.5">
-      <link rel="Chapter" title="6 IANA Considerations" href="#rfc.section.6">
-      <link rel="Chapter" title="7 Security Considerations" href="#rfc.section.7">
-      <link rel="Chapter" title="8 Acknowledgments" href="#rfc.section.8">
-      <link rel="Chapter" href="#rfc.section.9" title="9 References">
+      <link rel="Chapter" title="3 Payload" href="#rfc.section.3">
+      <link rel="Chapter" title="4 Representation" href="#rfc.section.4">
+      <link rel="Chapter" title="5 Content Negotiation" href="#rfc.section.5">
+      <link rel="Chapter" title="6 Header Field Definitions" href="#rfc.section.6">
+      <link rel="Chapter" title="7 IANA Considerations" href="#rfc.section.7">
+      <link rel="Chapter" title="8 Security Considerations" href="#rfc.section.8">
+      <link rel="Chapter" title="9 Acknowledgments" href="#rfc.section.9">
+      <link rel="Chapter" href="#rfc.section.10" title="10 References">
       <link rel="Appendix" title="A Differences between HTTP and MIME" href="#rfc.section.A">
       <link rel="Appendix" title="B Additional Features" href="#rfc.section.B">
@@ -555 +556 @@
             </ul>
          </li>
-         <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul class="toc">
-               <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#entity.header.fields">Entity Header Fields</a></li>
-               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#payload.body">Payload Body</a><ul class="toc">
-                     <li class="tocline1">3.2.1&nbsp;&nbsp;&nbsp;<a href="#type">Type</a></li>
-                  </ul>
-               </li>
+         <li class="tocline0">3.&nbsp;&nbsp;&nbsp;<a href="#payload">Payload</a><ul class="toc">
+               <li class="tocline1">3.1&nbsp;&nbsp;&nbsp;<a href="#payload.header.fields">Payload Header Fields</a></li>
+               <li class="tocline1">3.2&nbsp;&nbsp;&nbsp;<a href="#payload.body">Payload Body</a></li>
             </ul>
          </li>
-         <li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul class="toc">
-               <li class="tocline1">4.1&nbsp;&nbsp;&nbsp;<a href="#server-driven.negotiation">Server-driven Negotiation</a></li>
-               <li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li>
+         <li class="tocline0">4.&nbsp;&nbsp;&nbsp;<a href="#representation">Representation</a><ul class="toc">
+               <li class="tocline1">4.1&nbsp;&nbsp;&nbsp;<a href="#representation.header.fields">Representation Header Fields</a></li>
+               <li class="tocline1">4.2&nbsp;&nbsp;&nbsp;<a href="#representation.data">Representation Data</a></li>
             </ul>
          </li>
-         <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul class="toc">
-               <li class="tocline1">5.1&nbsp;&nbsp;&nbsp;<a href="#header.accept">Accept</a></li>
-               <li class="tocline1">5.2&nbsp;&nbsp;&nbsp;<a href="#header.accept-charset">Accept-Charset</a></li>
-               <li class="tocline1">5.3&nbsp;&nbsp;&nbsp;<a href="#header.accept-encoding">Accept-Encoding</a></li>
-               <li class="tocline1">5.4&nbsp;&nbsp;&nbsp;<a href="#header.accept-language">Accept-Language</a></li>
-               <li class="tocline1">5.5&nbsp;&nbsp;&nbsp;<a href="#header.content-encoding">Content-Encoding</a></li>
-               <li class="tocline1">5.6&nbsp;&nbsp;&nbsp;<a href="#header.content-language">Content-Language</a></li>
-               <li class="tocline1">5.7&nbsp;&nbsp;&nbsp;<a href="#header.content-location">Content-Location</a></li>
-               <li class="tocline1">5.8&nbsp;&nbsp;&nbsp;<a href="#header.content-md5">Content-MD5</a></li>
-               <li class="tocline1">5.9&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
+         <li class="tocline0">5.&nbsp;&nbsp;&nbsp;<a href="#content.negotiation">Content Negotiation</a><ul class="toc">
+               <li class="tocline1">5.1&nbsp;&nbsp;&nbsp;<a href="#server-driven.negotiation">Server-driven Negotiation</a></li>
+               <li class="tocline1">5.2&nbsp;&nbsp;&nbsp;<a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li>
             </ul>
          </li>
-         <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul class="toc">
-               <li class="tocline1">6.1&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
-               <li class="tocline1">6.2&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Content Coding Registry</a></li>
+         <li class="tocline0">6.&nbsp;&nbsp;&nbsp;<a href="#header.fields">Header Field Definitions</a><ul class="toc">
+               <li class="tocline1">6.1&nbsp;&nbsp;&nbsp;<a href="#header.accept">Accept</a></li>
+               <li class="tocline1">6.2&nbsp;&nbsp;&nbsp;<a href="#header.accept-charset">Accept-Charset</a></li>
+               <li class="tocline1">6.3&nbsp;&nbsp;&nbsp;<a href="#header.accept-encoding">Accept-Encoding</a></li>
+               <li class="tocline1">6.4&nbsp;&nbsp;&nbsp;<a href="#header.accept-language">Accept-Language</a></li>
+               <li class="tocline1">6.5&nbsp;&nbsp;&nbsp;<a href="#header.content-encoding">Content-Encoding</a></li>
+               <li class="tocline1">6.6&nbsp;&nbsp;&nbsp;<a href="#header.content-language">Content-Language</a></li>
+               <li class="tocline1">6.7&nbsp;&nbsp;&nbsp;<a href="#header.content-location">Content-Location</a></li>
+               <li class="tocline1">6.8&nbsp;&nbsp;&nbsp;<a href="#header.content-md5">Content-MD5</a></li>
+               <li class="tocline1">6.9&nbsp;&nbsp;&nbsp;<a href="#header.content-type">Content-Type</a></li>
             </ul>
          </li>
-         <li class="tocline0">7.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul class="toc">
-               <li class="tocline1">7.1&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li>
-               <li class="tocline1">7.2&nbsp;&nbsp;&nbsp;<a href="#content-disposition.issues">Content-Disposition Issues</a></li>
+         <li class="tocline0">7.&nbsp;&nbsp;&nbsp;<a href="#IANA.considerations">IANA Considerations</a><ul class="toc">
+               <li class="tocline1">7.1&nbsp;&nbsp;&nbsp;<a href="#header.field.registration">Header Field Registration</a></li>
+               <li class="tocline1">7.2&nbsp;&nbsp;&nbsp;<a href="#content.coding.registration">Content Coding Registry</a></li>
             </ul>
          </li>
-         <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#ack">Acknowledgments</a></li>
-         <li class="tocline0">9.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul class="toc">
-               <li class="tocline1">9.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
-               <li class="tocline1">9.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
+         <li class="tocline0">8.&nbsp;&nbsp;&nbsp;<a href="#security.considerations">Security Considerations</a><ul class="toc">
+               <li class="tocline1">8.1&nbsp;&nbsp;&nbsp;<a href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></li>
+               <li class="tocline1">8.2&nbsp;&nbsp;&nbsp;<a href="#content-disposition.issues">Content-Disposition Issues</a></li>
+            </ul>
+         </li>
+         <li class="tocline0">9.&nbsp;&nbsp;&nbsp;<a href="#ack">Acknowledgments</a></li>
+         <li class="tocline0">10.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a><ul class="toc">
+               <li class="tocline1">10.1&nbsp;&nbsp;&nbsp;<a href="#rfc.references.1">Normative References</a></li>
+               <li class="tocline1">10.2&nbsp;&nbsp;&nbsp;<a href="#rfc.references.2">Informative References</a></li>
             </ul>
          </li>
@@ -648 +651 @@
          <li>The mechanism for selecting the appropriate representation when servicing a request. The representation in any response can
             be negotiated (including error responses).
-         </li>
-      </ul>
-      <p id="rfc.section.1.1.p.3"> <span id="rfc.iref.p.1"></span>  <dfn>payload</dfn>  
-      </p>
-      <ul class="empty">
-         <li>The information transferred within a given message is called the payload, consisting of optional payload metadata and an optional
-            payload body. The payload in HTTP is always a partial or complete representation of some resource, though which resource is
-            represented is dependent on the type of message (request or response), the request method, and the response status code.
-         </li>
-      </ul>
-      <p id="rfc.section.1.1.p.4"> <span id="rfc.iref.r.1"></span>  <dfn>representation</dfn>  
-      </p>
-      <ul class="empty">
-         <li>A representation is information in a format that can be readily communicated from one party to another. For our purposes,
-            a representation is binary data and its associated metadata. A representation of a resource is information that reflects the
-            state of that resource, as observed at some point in the past or to be desired at some point in the future.
          </li>
       </ul>
@@ -744 +731 @@
       </p>
       <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.2"></span>  <a href="#content.codings" class="smpl">content-coding</a>   = <a href="#core.rules" class="smpl">token</a>
-</pre><p id="rfc.section.2.2.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section&nbsp;5.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;5.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
+</pre><p id="rfc.section.2.2.p.3">All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.1" title="Accept-Encoding">Section&nbsp;6.3</a>) and Content-Encoding (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.1" title="Content-Encoding">Section&nbsp;6.5</a>) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding
          mechanism will be required to remove the encoding.
       </p>
@@ -788 +775 @@
       </p>
       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="media.types" href="#media.types">Media Types</a></h2>
-      <p id="rfc.section.2.3.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;5.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;5.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
+      <p id="rfc.section.2.3.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the Content-Type (<a href="#header.content-type" id="rfc.xref.header.content-type.1" title="Content-Type">Section&nbsp;6.9</a>) and Accept (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;6.1</a>) header fields in order to provide open and extensible data typing and type negotiation.
       </p>
       <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#media.types" class="smpl">media-type</a> = <a href="#media.types" class="smpl">type</a> "/" <a href="#media.types" class="smpl">subtype</a> *( <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> )
@@ -860 +847 @@
 </pre> <p id="rfc.section.2.4.p.6">See <a href="#RFC5646" id="rfc.xref.RFC5646.3"><cite title="Tags for Identifying Languages">[RFC5646]</cite></a> for further information.
       </p>
-      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
-      <p id="rfc.section.3.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists
-         of entity-header fields and a representation body, although some responses will only include the entity-headers.
-      </p>
-      <p id="rfc.section.3.p.2">In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives
-         the message.
-      </p>
-      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="entity.header.fields" href="#entity.header.fields">Entity Header Fields</a></h2>
-      <p id="rfc.section.3.1.p.1">Entity-header fields define metadata about the representation data enclosed in the message-body or, if no message-body is
-         present, about the representation that would have been transferred in a 200 response to a simultaneous GET request on the
-         Effective Request URI.
-      </p>
-      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>  <a href="#entity.header.fields" class="smpl">entity-header</a>  = <a href="#header.content-encoding" class="smpl">Content-Encoding</a>         ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;5.5</a>
-                 / <a href="#header.content-language" class="smpl">Content-Language</a>         ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;5.6</a>
-                 / <a href="#abnf.dependencies" class="smpl">Content-Length</a>           ; <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 9.2</a>
-                 / <a href="#header.content-location" class="smpl">Content-Location</a>         ; <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;5.7</a>
-                 / <a href="#header.content-md5" class="smpl">Content-MD5</a>              ; <a href="#header.content-md5" id="rfc.xref.header.content-md5.1" title="Content-MD5">Section&nbsp;5.8</a>
-                 / <a href="#abnf.dependencies" class="smpl">Content-Range</a>            ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a>
-                 / <a href="#header.content-type" class="smpl">Content-Type</a>             ; <a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;5.9</a>
-                 / <a href="#abnf.dependencies" class="smpl">Expires</a>                  ; <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a>
-                 / <a href="#abnf.dependencies" class="smpl">Last-Modified</a>            ; <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a>
-                 / <a href="#entity.header.fields" class="smpl">extension-header</a>
-  
-  <a href="#entity.header.fields" class="smpl">extension-header</a> = <a href="#abnf.dependencies" class="smpl">header-field</a>
-</pre><p id="rfc.section.3.1.p.3">The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these
-         fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by the recipient and <em class="bcp14">MUST</em> be forwarded by transparent proxies.
-      </p>
-      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
-      <p id="rfc.section.3.2.p.1">The payload body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.</p>
-      <p id="rfc.section.3.2.p.2">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
+      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="payload" href="#payload">Payload</a></h1>
+      <p id="rfc.section.3.p.1">HTTP messages <em class="bcp14">MAY</em> transfer a payload if not otherwise restricted by the request method or response status code. The payload consists of metadata,
+         in the form of header fields, and data, in the form of the sequence of octets in the message-body after any transfer-coding
+         has been decoded.
+      </p>
+      <div id="rfc.iref.p.1"></div>
+      <p id="rfc.section.3.p.2">A "<dfn>payload</dfn>" in HTTP is always a partial or complete representation of some resource. We use separate terms for payload and representation
+         because some messages contain only the associated representation's header fields (e.g., responses to HEAD) or only some part(s)
+         of the representation (e.g., the 206 status code).
+      </p>
+      <p id="rfc.section.3.p.3">define metadata for the whole representation, which we refer to as "representation header fields", while others define only
+         metadata about what is included in the message, which we
+      </p>
+      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h2>
+      <p id="rfc.section.3.1.p.1">HTTP header fields that specifically define the payload, rather than the associated representation, are referred to as "payload
+         header fields". The following payload header fields are defined by HTTP/1.1:
+      </p>
+      <div id="rfc.figure.u.12"></div><pre>   <a href="#abnf.dependencies" class="smpl">Content-Length</a>           ; <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 9.2</a>
+   <a href="#header.content-md5" class="smpl">Content-MD5</a>              ; <a href="#header.content-md5" id="rfc.xref.header.content-md5.1" title="Content-MD5">Section&nbsp;6.8</a>
+   <a href="#abnf.dependencies" class="smpl">Content-Range</a>            ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a>
+</pre><h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="payload.body" href="#payload.body">Payload Body</a></h2>
+      <p id="rfc.section.3.2.p.1">A payload body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The payload body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
          safe and proper transfer of the message.
       </p>
-      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="type" href="#type">Type</a></h3>
-      <p id="rfc.section.3.2.1.p.1">When a payload body is included with a message, the data type of that body is determined via the header fields Content-Type
-         and Content-Encoding. These define a two-layer, ordered encoding model:
-      </p>
-      <div id="rfc.figure.u.13"></div><pre class="text">  payload-body := Content-Encoding( Content-Type( data ) )
-</pre><p id="rfc.section.3.2.1.p.3">Content-Type specifies the media type of the underlying data. 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 that body, unless that information is unknown.
-      </p>
-      <p id="rfc.section.3.2.1.p.4">If the Content-Type header field is not present, it indicates that the sender does not know the media type of the data; recipients <em class="bcp14">MAY</em> either assume that it is "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><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.2.1.p.5">In practice, currently-deployed servers sometimes provide a Content-Type header which does not correctly convey the intended
-         interpretation of the content sent, with the result that some clients will examine the response body's content and override
-         the specified type.
-      </p>
-      <p id="rfc.section.3.2.1.p.6">Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation").
-         Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.
-      </p>
-      <p id="rfc.section.3.2.1.p.7">Content-Encoding 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. There is no default encoding.
-      </p>
-      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
-      <p id="rfc.section.4.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
+      <div id="rfc.iref.r.1"></div>
+      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="representation" href="#representation">Representation</a></h1>
+      <p id="rfc.section.4.p.1">A "<dfn>representation</dfn>" is information in a format that can be readily communicated from one party to another. A resource representation is information
+         that reflects the state of that resource, as observed at some point in the past (e.g., in a response to GET) or to be desired
+         at some point in the future (e.g., in a PUT request).
+      </p>
+      <p id="rfc.section.4.p.2">Most, but not all, representations transferred via HTTP are intended to be a representation of the target resource (the resource
+         identified by the effective request URI). The precise semantics of a representation are determined by the type of message
+         (request or response), the request method, the response status code, and the representation metadata. For example, the above
+         semantic is true for the representation in any 200 (OK) response to GET and for the representation in any PUT request. A 200
+         response to PUT, in contrast, contains either a representation that describes the successful action or a representation of
+         the target resource, with the latter indicated by a Content-Location header field with the same value as the effective request
+         URI. Likewise, response messages with an error status code usually contain a representation that describes the error and what
+         next steps are suggested for resolving it.
+      </p>
+      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
+      <p id="rfc.section.4.1.p.1">Representation header fields define metadata about the representation data enclosed in the message-body or, if no message-body
+         is present, about the representation that would have been transferred in a 200 response to a simultaneous GET request with
+         the same effective request URI.
+      </p>
+      <p id="rfc.section.4.1.p.2">The following header fields are defined as representation metadata:</p>
+      <div id="rfc.figure.u.13"></div><pre>   <a href="#header.content-encoding" class="smpl">Content-Encoding</a>         ; <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.2" title="Content-Encoding">Section&nbsp;6.5</a>
+   <a href="#header.content-language" class="smpl">Content-Language</a>         ; <a href="#header.content-language" id="rfc.xref.header.content-language.1" title="Content-Language">Section&nbsp;6.6</a>
+   <a href="#header.content-location" class="smpl">Content-Location</a>         ; <a href="#header.content-location" id="rfc.xref.header.content-location.1" title="Content-Location">Section&nbsp;6.7</a>
+   <a href="#header.content-type" class="smpl">Content-Type</a>             ; <a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;6.9</a>
+   <a href="#abnf.dependencies" class="smpl">Expires</a>                  ; <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a>
+   <a href="#abnf.dependencies" class="smpl">Last-Modified</a>            ; <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 6.6</a>
+</pre><h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
+      <p id="rfc.section.4.2.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
+         to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by
+         the representation metadata header fields.
+      </p>
+      <p id="rfc.section.4.2.p.2">The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define
+         a two-layer, ordered encoding model:
+      </p>
+      <div id="rfc.figure.u.14"></div><pre class="text">  representation-data := Content-Encoding( Content-Type( bits ) )
+</pre><p id="rfc.section.4.2.p.4">Content-Type 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.3"><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.4.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 response body's content and override the specified
+         type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege
+         escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats
+         match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling
+         such "content sniffing" when it is used.
+      </p>
+      <p id="rfc.section.4.2.p.6">Content-Encoding 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 Content-Type.
+      </p>
+      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1>
+      <p id="rfc.section.5.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further
          processing. Often, the server has different ways of representing the same information; for example, in different formats,
          languages, or using different character encodings.
       </p>
-      <p id="rfc.section.4.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
+      <p id="rfc.section.5.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence
          which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP
          provides mechanisms for "content negotiation" -- a process of allowing selection of a representation of a given resource,
          when more than one is available.
       </p>
-      <p id="rfc.section.4.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation
+      <p id="rfc.section.5.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation
          based upon the client's stated preferences, and "agent-driven" 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
@@ -927 +939 @@
          parameters, 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.4.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.5.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number
          of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by
          a user-agent), server-driven negotiation becomes unwieldy, and might not be appropriate. Conversely, when the number of representations
          to choose from is very large, agent-driven negotiation might not be appropriate.
       </p>
-      <p id="rfc.section.4.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might
+      <p id="rfc.section.5.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might
          be considered to be the "same information".
       </p>
-      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h2>
-      <p id="rfc.section.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 server-driven
+      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h2>
+      <p id="rfc.section.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 server-driven
          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.4.1.p.2">Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult
+      <p id="rfc.section.5.1.p.2">Server-driven 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 (Accept, Accept-Language, Accept-Encoding, etc.) which describe its preferences for such a response.
       </p>
-      <p id="rfc.section.4.1.p.3">Server-driven negotiation has disadvantages: </p>
+      <p id="rfc.section.5.1.p.3">Server-driven 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
@@ -958 +970 @@
          <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.4.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent
-         capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;5.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;5.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;5.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;5.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></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 information outside the request-header fields or within extension
+      <p id="rfc.section.5.1.p.4">HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent
+         capabilities and user preferences: Accept (<a href="#header.accept" id="rfc.xref.header.accept.2" title="Accept">Section&nbsp;6.1</a>), Accept-Charset (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.1" title="Accept-Charset">Section&nbsp;6.2</a>), Accept-Encoding (<a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.2" title="Accept-Encoding">Section&nbsp;6.3</a>), Accept-Language (<a href="#header.accept-language" id="rfc.xref.header.accept-language.1" title="Accept-Language">Section&nbsp;6.4</a>), and User-Agent (<a href="p2-semantics.html#header.user-agent" title="User-Agent">Section 9.9</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></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 information outside the request-header fields or within extension
          header fields not defined by this specification.
       </p>
-      <div class="note" id="rfc.section.4.1.p.5"> 
+      <div class="note" id="rfc.section.5.1.p.5"> 
          <p> <b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized.
          </p> 
       </div>
-      <p id="rfc.section.4.1.p.6">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
-      </p>
-      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>
-      <p id="rfc.section.4.2.p.1">With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving
+      <p id="rfc.section.5.1.p.6">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
+      </p>
+      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>
+      <p id="rfc.section.5.2.p.1">With agent-driven 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
@@ -975 +987 @@
          user selecting from a generated (possibly hypertext) menu.
       </p>
-      <p id="rfc.section.4.2.p.2">Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language,
+      <p id="rfc.section.5.2.p.2">Agent-driven 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.4.2.p.3">Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation.
+      <p id="rfc.section.5.2.p.3">Agent-driven 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.4.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation
+      <p id="rfc.section.5.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation
          when the server is unwilling or unable to provide a varying response using server-driven negotiation.
       </p>
-      <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
-      <p id="rfc.section.5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to the payload of messages.</p>
-      <p id="rfc.section.5.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
-         receives the message.
-      </p>
+      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
+      <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to the payload of messages.</p>
       <div id="rfc.iref.a.1"></div>
       <div id="rfc.iref.h.1"></div>
-      <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="header.accept" href="#header.accept">Accept</a></h2>
-      <p id="rfc.section.5.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept headers
+      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.accept" href="#header.accept">Accept</a></h2>
+      <p id="rfc.section.6.1.p.1">The "Accept" request-header field can be used by user agents to specify response media types that are acceptable. Accept headers
          can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request
          for an in-line image.
       </p>
-      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.accept" class="smpl">Accept</a>   = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>
+      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.accept" class="smpl">Accept</a>   = "Accept" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.accept" class="smpl">Accept-v</a>
   <a href="#header.accept" class="smpl">Accept-v</a> = #( <a href="#header.accept" class="smpl">media-range</a> [ <a href="#header.accept" class="smpl">accept-params</a> ] )
   
@@ -1009 +1018 @@
   <a href="#header.accept" class="smpl">accept-ext</a>     = <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> <a href="#core.rules" class="smpl">token</a>
                    [ "=" <a href="#core.rules" class="smpl">word</a> ]
-</pre><p id="rfc.section.5.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating
+</pre><p id="rfc.section.6.1.p.3">The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating
          all subtypes of that type. The media-range <em class="bcp14">MAY</em> include media type parameters that are applicable to that range.
       </p>
-      <p id="rfc.section.5.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first
+      <p id="rfc.section.6.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first
          "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
          agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 6.4</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
       </p>
-      <div class="note" id="rfc.section.5.1.p.5"> 
+      <div class="note" id="rfc.section.6.1.p.5"> 
          <p> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.
             Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to
@@ -1023 +1032 @@
          </p> 
       </div>
-      <p id="rfc.section.5.1.p.6">The example</p>
-      <div id="rfc.figure.u.15"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
-</pre><p id="rfc.section.5.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
+      <p id="rfc.section.6.1.p.6">The example</p>
+      <div id="rfc.figure.u.16"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
+</pre><p id="rfc.section.6.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
          quality".
       </p>
-      <p id="rfc.section.5.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
+      <p id="rfc.section.6.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
          is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then
          the server <em class="bcp14">SHOULD</em> send a 406 (Not Acceptable) response.
       </p>
-      <p id="rfc.section.5.1.p.10">A more elaborate example is</p>
-      <div id="rfc.figure.u.16"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
+      <p id="rfc.section.6.1.p.10">A more elaborate example is</p>
+      <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
           text/x-dvi; q=0.8, text/x-c
-</pre><p id="rfc.section.5.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
+</pre><p id="rfc.section.6.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
          send the text/x-dvi representation, and if that does not exist, send the text/plain representation".
       </p>
-      <p id="rfc.section.5.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
+      <p id="rfc.section.6.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
          to a given type, the most specific reference has precedence. For example,
       </p>
-      <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
-</pre><p id="rfc.section.5.1.p.15">have the following precedence: </p>
+      <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
+</pre><p id="rfc.section.6.1.p.15">have the following precedence: </p>
       <ol>
          <li>text/html;level=1</li>
@@ -1049 +1058 @@
          <li>*/*</li>
       </ol>
-      <p id="rfc.section.5.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence
+      <p id="rfc.section.6.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence
          which matches that type. For example,
       </p>
-      <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
+      <div id="rfc.figure.u.19"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
           text/html;level=2;q=0.4, */*;q=0.5
-</pre><p id="rfc.section.5.1.p.18">would cause the following values to be associated:</p>
+</pre><p id="rfc.section.6.1.p.18">would cause the following values to be associated:</p>
       <div id="rfc.table.u.1">
          <table class="tt full left" cellpadding="3" cellspacing="0">
@@ -1091 +1100 @@
          </table>
       </div>
-      <p id="rfc.section.5.1.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent
+      <p id="rfc.section.6.1.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent
          is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user.
       </p>
       <div id="rfc.iref.a.2"></div>
       <div id="rfc.iref.h.2"></div>
-      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2>
-      <p id="rfc.section.5.2.p.1">The "Accept-Charset" request-header field can be used by user agents to indicate what response character sets are acceptable.
+      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.accept-charset" href="#header.accept-charset">Accept-Charset</a></h2>
+      <p id="rfc.section.6.2.p.1">The "Accept-Charset" request-header field can be used by user agents to indicate what response character sets are acceptable.
          This field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability
          to a server which is capable of representing documents in those character sets.
       </p>
-      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a>   = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>
+      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a>   = "Accept-Charset" ":" <a href="#core.rules" class="smpl">OWS</a>
           <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a>
   <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = 1#( ( <a href="#rule.charset" class="smpl">charset</a> / "*" )
                          [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
-</pre><p id="rfc.section.5.2.p.3">Character set values are described in <a href="#character.sets" title="Character Sets">Section&nbsp;2.1</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An
+</pre><p id="rfc.section.6.2.p.3">Character set values are described in <a href="#character.sets" title="Character Sets">Section&nbsp;2.1</a>. Each charset <em class="bcp14">MAY</em> be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An
          example is
       </p>
-      <div id="rfc.figure.u.20"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
-</pre><p id="rfc.section.5.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is
+      <div id="rfc.figure.u.21"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
+</pre><p id="rfc.section.6.2.p.5">The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is
          not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets
          not explicitly mentioned get a quality value of 0, except for ISO-8859-1, which gets a quality value of 1 if not explicitly
          mentioned.
       </p>
-      <p id="rfc.section.5.2.p.6">If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is
+      <p id="rfc.section.6.2.p.6">If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is
          present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code, though the sending of an unacceptable response is also allowed.
       </p>
       <div id="rfc.iref.a.3"></div>
       <div id="rfc.iref.h.3"></div>
-      <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2>
-      <p id="rfc.section.5.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) are acceptable in the response.
-      </p>
-      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.20"></span><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>    = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>
+      <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="header.accept-encoding" href="#header.accept-encoding">Accept-Encoding</a></h2>
+      <p id="rfc.section.6.3.p.1">The "Accept-Encoding" request-header field can be used by user agents to indicate what response content-codings (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>) are acceptable in the response.
+      </p>
+      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>    = "Accept-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a>
                      <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a>
   <a href="#header.accept-encoding" class="smpl">Accept-Encoding-v</a>  = 
                      #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#core.rules" class="smpl">OWS</a> ";" <a href="#core.rules" class="smpl">OWS</a> "q=" <a href="#abnf.dependencies" class="smpl">qvalue</a> ] )
   <a href="#header.accept-encoding" class="smpl">codings</a>            = ( <a href="#content.codings" class="smpl">content-coding</a> / "*" )
-</pre><p id="rfc.section.5.3.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1.
-      </p>
-      <p id="rfc.section.5.3.p.4">Examples of its use are:</p>
-      <div id="rfc.figure.u.22"></div><pre class="text">  Accept-Encoding: compress, gzip
+</pre><p id="rfc.section.6.3.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding. The default value is q=1.
+      </p>
+      <p id="rfc.section.6.3.p.4">Examples of its use are:</p>
+      <div id="rfc.figure.u.23"></div><pre class="text">  Accept-Encoding: compress, gzip
   Accept-Encoding:
   Accept-Encoding: *
   Accept-Encoding: compress;q=0.5, gzip;q=1.0
   Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
-</pre><p id="rfc.section.5.3.p.6">A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules: </p>
+</pre><p id="rfc.section.6.3.p.6">A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules: </p>
       <ol>
          <li>If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it
@@ -1149 +1158 @@
          </li>
       </ol>
-      <p id="rfc.section.5.3.p.7">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according
+      <p id="rfc.section.6.3.p.7">If an Accept-Encoding field is present in a request, and if the server cannot send a response which is acceptable according
          to the Accept-Encoding header, then the server <em class="bcp14">SHOULD</em> send an error response with the 406 (Not Acceptable) status code.
       </p>
-      <p id="rfc.section.5.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings,
+      <p id="rfc.section.6.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings,
          then the server <em class="bcp14">SHOULD</em> use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the
          client.
       </p>
-      <div class="note" id="rfc.section.5.3.p.9"> 
+      <div class="note" id="rfc.section.6.3.p.9"> 
          <p> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings
             commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display
@@ -1163 +1172 @@
          </p> 
       </div>
-      <div class="note" id="rfc.section.5.3.p.10"> 
+      <div class="note" id="rfc.section.6.3.p.10"> 
          <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will
             not work and are not permitted with x-gzip or x-compress.
@@ -1170 +1179 @@
       <div id="rfc.iref.a.4"></div>
       <div id="rfc.iref.h.4"></div>
-      <h2 id="rfc.section.5.4"><a href="#rfc.section.5.4">5.4</a>&nbsp;<a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2>
-      <p id="rfc.section.5.4.p.1">The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred
+      <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a>&nbsp;<a id="header.accept-language" href="#header.accept-language">Accept-Language</a></h2>
+      <p id="rfc.section.6.4.p.1">The "Accept-Language" request-header field can be used by user agents to indicate the set of natural languages that are preferred
          in the response. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>.
       </p>
-      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.23"></span><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a>   = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>
+      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>  <a href="#header.accept-language" class="smpl">Accept-Language</a>   = "Accept-Language" ":" <a href="#core.rules" class="smpl">OWS</a>
                     <a href="#header.accept-language" class="smpl">Accept-Language-v</a>
   <a href="#header.accept-language" class="smpl">Accept-Language-v</a> =
@@ -1180 +1189 @@
   <a href="#header.accept-language" class="smpl">language-range</a>    = 
             &lt;language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>&gt;
-</pre><p id="rfc.section.5.4.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the
+</pre><p id="rfc.section.6.4.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the
          languages specified by that range. The quality value defaults to "q=1". For example,
       </p>
-      <div id="rfc.figure.u.24"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
-</pre><p id="rfc.section.5.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
-      </p>
-      <p id="rfc.section.5.4.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements.
-      </p>
-      <div class="note" id="rfc.section.5.4.p.7"> 
+      <div id="rfc.figure.u.25"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
+</pre><p id="rfc.section.6.4.p.5">would mean: "I prefer Danish, but will accept British English and other types of English". (see also <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>)
+      </p>
+      <p id="rfc.section.6.4.p.6">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements.
+      </p>
+      <div class="note" id="rfc.section.6.4.p.7"> 
          <p> <b>Note:</b> The "Basic Filtering" scheme (<a href="#RFC4647" id="rfc.xref.RFC4647.4"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-3.3.1">Section 3.3.1</a>) is identical to the matching scheme that was previously defined in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
          </p> 
       </div>
-      <p id="rfc.section.5.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic
-         preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section&nbsp;7.1</a>.
-      </p>
-      <p id="rfc.section.5.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
+      <p id="rfc.section.6.4.p.8">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic
+         preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section&nbsp;8.1</a>.
+      </p>
+      <p id="rfc.section.6.4.p.9">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
          of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field <em class="bcp14">MUST NOT</em> be given in the request.
       </p>
-      <div class="note" id="rfc.section.5.4.p.10"> 
+      <div class="note" id="rfc.section.6.4.p.10"> 
          <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not
             familiar with the details of language matching as described above, and should provide appropriate guidance. As an example,
@@ -1207 +1216 @@
       <div id="rfc.iref.c.7"></div>
       <div id="rfc.iref.h.5"></div>
-      <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
-      <p id="rfc.section.5.5.p.1">The "Content-Encoding" entity-header field indicates what content-codings have been applied to the representation, and thus
-         what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding
+      <h2 id="rfc.section.6.5"><a href="#rfc.section.6.5">6.5</a>&nbsp;<a id="header.content-encoding" href="#header.content-encoding">Content-Encoding</a></h2>
+      <p id="rfc.section.6.5.p.1">The "Content-Encoding" header field indicates what content-codings have been applied to the representation, and thus what
+         decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding
          is primarily used to allow a representation to be compressed without losing the identity of its underlying media type.
       </p>
-      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a>   = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>
+      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>  <a href="#header.content-encoding" class="smpl">Content-Encoding</a>   = "Content-Encoding" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a>
   <a href="#header.content-encoding" class="smpl">Content-Encoding-v</a> = 1#<a href="#content.codings" class="smpl">content-coding</a>
-</pre><p id="rfc.section.5.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>. An example of its use is
-      </p>
-      <div id="rfc.figure.u.26"></div><pre class="text">  Content-Encoding: gzip
-</pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
+</pre><p id="rfc.section.6.5.p.3">Content codings are defined in <a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>. An example of its use is
+      </p>
+      <div id="rfc.figure.u.27"></div><pre class="text">  Content-Encoding: gzip
+</pre><p id="rfc.section.6.5.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
          and is only decoded before rendering or analogous usage. However, a non-transparent proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
          directive is present in the message.
       </p>
-      <p id="rfc.section.5.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;5.5</a>) that lists the non-identity content-coding(s) used.
-      </p>
-      <p id="rfc.section.5.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
-      </p>
-      <p id="rfc.section.5.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
+      <p id="rfc.section.6.5.p.6">If the content-coding of a representation is not "identity", then the representation metadata <em class="bcp14">MUST</em> include a Content-Encoding header field (<a href="#header.content-encoding" id="rfc.xref.header.content-encoding.3" title="Content-Encoding">Section&nbsp;6.5</a>) that lists the non-identity content-coding(s) used.
+      </p>
+      <p id="rfc.section.6.5.p.7">If the content-coding of a representation in a request message is not acceptable to the origin server, the server <em class="bcp14">SHOULD</em> respond with a status code of 415 (Unsupported Media Type).
+      </p>
+      <p id="rfc.section.6.5.p.8">If multiple encodings have been applied to a representation, the content codings <em class="bcp14">MUST</em> be listed in the order in which they were applied. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.
       </p>
       <div id="rfc.iref.c.8"></div>
       <div id="rfc.iref.h.6"></div>
-      <h2 id="rfc.section.5.6"><a href="#rfc.section.5.6">5.6</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
-      <p id="rfc.section.5.6.p.1">The "Content-Language" entity-header field describes the natural language(s) of the intended audience for the representation.
-         Note that this might not be equivalent to all the languages used within the representation.
-      </p>
-      <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span>  <a href="#header.content-language" class="smpl">Content-Language</a>   = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>
+      <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="header.content-language" href="#header.content-language">Content-Language</a></h2>
+      <p id="rfc.section.6.6.p.1">The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note
+         that this might not be equivalent to all the languages used within the representation.
+      </p>
+      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span>  <a href="#header.content-language" class="smpl">Content-Language</a>   = "Content-Language" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-language" class="smpl">Content-Language-v</a>
   <a href="#header.content-language" class="smpl">Content-Language-v</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
-</pre><p id="rfc.section.5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
+</pre><p id="rfc.section.6.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.4</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
          user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate
          field is
       </p>
-      <div id="rfc.figure.u.28"></div><pre class="text">  Content-Language: da
-</pre><p id="rfc.section.5.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
+      <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: da
+</pre><p id="rfc.section.6.6.p.5">If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean
          that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language
          it is intended.
       </p>
-      <p id="rfc.section.5.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented
+      <p id="rfc.section.6.6.p.6">Multiple languages <em class="bcp14">MAY</em> be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented
          simultaneously in the original Maori and English versions, would call for
       </p>
-      <div id="rfc.figure.u.29"></div><pre class="text">  Content-Language: mi, en
-</pre><p id="rfc.section.5.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
+      <div id="rfc.figure.u.30"></div><pre class="text">  Content-Language: mi, en
+</pre><p id="rfc.section.6.6.p.8">However, just because multiple languages are present within a representation does not mean that it is intended for multiple
          linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly
          intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
       </p>
-      <p id="rfc.section.5.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type -- it is not limited to textual documents.
+      <p id="rfc.section.6.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type -- it is not limited to textual documents.
       </p>
       <div id="rfc.iref.c.9"></div>
       <div id="rfc.iref.h.7"></div>
-      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
-      <p id="rfc.section.5.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
+      <h2 id="rfc.section.6.7"><a href="#rfc.section.6.7">6.7</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
+      <p id="rfc.section.6.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
          message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response
          would contain the same representation that is enclosed as payload in this message.
       </p>
-      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span>  <a href="#header.content-location" class="smpl">Content-Location</a>   = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>
+      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span>  <a href="#header.content-location" class="smpl">Content-Location</a>   = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>
                     <a href="#header.content-location" class="smpl">Content-Location-v</a>
   <a href="#header.content-location" class="smpl">Content-Location-v</a> =
                     <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
-</pre><p id="rfc.section.5.7.p.3">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
+</pre><p id="rfc.section.6.7.p.3">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
          body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
       </p>
-      <p id="rfc.section.5.7.p.4">If Content-Location is included in a response message and its value is the same as the Effective Request URI, then the response
+      <p id="rfc.section.6.7.p.4">If Content-Location is included in a response message and its value is the same as the effective request URI, then the response
          payload <em class="bcp14">SHOULD</em> be considered the current representation of that resource. For a GET or HEAD request, this is the same as the default semantics
          when no Content-Location is provided by the server. For a state-changing method like PUT or POST, it implies that the server's
@@ -1275 +1284 @@
          need for a subsequent GET request.
       </p>
-      <p id="rfc.section.5.7.p.5">If Content-Location is included in a response message and its value differs from the Effective Request URI, then the origin
+      <p id="rfc.section.6.7.p.5">If Content-Location is included in a response message and its value differs from the effective request URI, then the origin
          server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD
-         request, this is an indication that the Effective Request URI identifies a resource that is subject to content negotiation
+         request, this is an indication that the effective request URI identifies a resource that is subject to content negotiation
          and the representation selected for this response can also be found at the identified URI. For other methods, such a Content-Location
          indicates that this representation contains a report on the action's status and the same report is available (for future access
@@ -1284 +1293 @@
          in the future.
       </p>
-      <p id="rfc.section.5.7.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
+      <p id="rfc.section.6.7.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
          representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is
          providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated
@@ -1292 +1301 @@
          latter semantics, it would have applied the PUT directly to the Content-Location URI.
       </p>
-      <p id="rfc.section.5.7.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use
+      <p id="rfc.section.6.7.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use
          in other contexts, such as within source links or other metadata.
       </p>
-      <p id="rfc.section.5.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used
+      <p id="rfc.section.6.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used
          to respond to later requests on that Content-Location URI.
       </p>
-      <p id="rfc.section.5.7.p.9">If the Content-Location value is a partial URI, it is interpreted relative to the Effective Request URI.</p>
+      <p id="rfc.section.6.7.p.9">If the Content-Location value is a partial URI, the partial URI is interpreted relative to the effective request URI.</p>
       <div id="rfc.iref.c.10"></div>
       <div id="rfc.iref.h.8"></div>
-      <h2 id="rfc.section.5.8"><a href="#rfc.section.5.8">5.8</a>&nbsp;<a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2>
-      <p id="rfc.section.5.8.p.1">The "Content-MD5" entity-header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the payload body that provides an end-to-end message integrity check (MIC) of the payload body (the
+      <h2 id="rfc.section.6.8"><a href="#rfc.section.6.8">6.8</a>&nbsp;<a id="header.content-md5" href="#header.content-md5">Content-MD5</a></h2>
+      <p id="rfc.section.6.8.p.1">The "Content-MD5" header field, as defined in <a href="#RFC1864" id="rfc.xref.RFC1864.1"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>, is an MD5 digest of the payload body that provides an end-to-end message integrity check (MIC) of the payload body (the
          message-body after any transfer-coding is decoded). Note that a MIC is good for detecting accidental modification of the payload
          body in transit, but is not proof against malicious attacks.
       </p>
-      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span>  <a href="#header.content-md5" class="smpl">Content-MD5</a>   = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a>
+      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span>  <a href="#header.content-md5" class="smpl">Content-MD5</a>   = "Content-MD5" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-md5" class="smpl">Content-MD5-v</a>
   <a href="#header.content-md5" class="smpl">Content-MD5-v</a> = &lt;base64 of 128 bit MD5 digest as per <a href="#RFC1864" id="rfc.xref.RFC1864.2"><cite title="The Content-MD5 Header Field">[RFC1864]</cite></a>&gt;
-</pre><p id="rfc.section.5.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user
+</pre><p id="rfc.section.6.8.p.3">The Content-MD5 header field <em class="bcp14">MAY</em> be generated by an origin server or client to function as an integrity check of the payload body. Only origin servers or user
          agents <em class="bcp14">MAY</em> generate the Content-MD5 header field; proxies and gateways <em class="bcp14">MUST NOT</em> generate it, as this would defeat its value as an end-to-end integrity check. Any recipient <em class="bcp14">MAY</em> check that the digest value in this header field matches a corresponding digest calculated on payload body as received.
       </p>
-      <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding
+      <p id="rfc.section.6.8.p.4">The MD5 digest is computed based on the content of the payload body, including any content-coding, but not including any transfer-coding
          applied to the message-body because such transfer-codings might be applied or removed anywhere along the request/response
          chain. If the message is received with a transfer-coding, that encoding <em class="bcp14">MUST</em> be decoded prior to checking the Content-MD5 value against the received payload.
       </p>
-      <p id="rfc.section.5.8.p.5">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822),
+      <p id="rfc.section.6.8.p.5">HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822),
          but this does not change how the digest is computed as defined in the preceding paragraph.
       </p>
-      <p id="rfc.section.5.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding
+      <p id="rfc.section.6.8.p.6">There are several consequences of this. The payload for composite types <em class="bcp14">MAY</em> contain many body-parts, each with its own MIME and HTTP headers (including Content-MD5, Content-Transfer-Encoding, and Content-Encoding
          headers). If a body-part has a Content-Transfer-Encoding or Content-Encoding header, it is assumed that the content of the
          body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest as is -- i.e., after the application.
          The Transfer-Encoding header field is not allowed within body-parts.
       </p>
-      <p id="rfc.section.5.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
-      </p>
-      <div class="note" id="rfc.section.5.8.p.8"> 
+      <p id="rfc.section.6.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest.
+      </p>
+      <div class="note" id="rfc.section.6.8.p.8"> 
          <p> <b>Note:</b> While the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several
             ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One
@@ -1336 +1345 @@
       <div id="rfc.iref.c.11"></div>
       <div id="rfc.iref.h.9"></div>
-      <h2 id="rfc.section.5.9"><a href="#rfc.section.5.9">5.9</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h2>
-      <p id="rfc.section.5.9.p.1">The "Content-Type" entity-header field indicates the media type of the representation. In the case of responses to the HEAD
-         method, the media type is that which would have been sent had the request been a GET.
-      </p>
-      <div id="rfc.figure.u.32"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span>  <a href="#header.content-type" class="smpl">Content-Type</a>   = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>
+      <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a>&nbsp;<a id="header.content-type" href="#header.content-type">Content-Type</a></h2>
+      <p id="rfc.section.6.9.p.1">The "Content-Type" header field indicates the media type of the representation. In the case of responses to the HEAD method,
+         the media type is that which would have been sent had the request been a GET.
+      </p>
+      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span>  <a href="#header.content-type" class="smpl">Content-Type</a>   = "Content-Type" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.content-type" class="smpl">Content-Type-v</a>
   <a href="#header.content-type" class="smpl">Content-Type-v</a> = <a href="#media.types" class="smpl">media-type</a>
-</pre><p id="rfc.section.5.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;2.3</a>. An example of the field is
-      </p>
-      <div id="rfc.figure.u.33"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
-</pre><p id="rfc.section.5.9.p.5">Further discussion of methods for identifying the media type of a representation is provided in <a href="#type" title="Type">Section&nbsp;3.2.1</a>.
-      </p>
-      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
-      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
-      <p id="rfc.section.6.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
+</pre><p id="rfc.section.6.9.p.3">Media types are defined in <a href="#media.types" title="Media Types">Section&nbsp;2.3</a>. An example of the field is
+      </p>
+      <div id="rfc.figure.u.34"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
+</pre><p id="rfc.section.6.9.p.5">Further discussion of Content-Type is provided in <a href="#representation.data" title="Representation Data">Section&nbsp;4.2</a>.
+      </p>
+      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
+      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
+      <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
       </p>
       <div id="rfc.table.1">
@@ -1367 +1376 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;5.1</a> 
+                  <td class="left"> <a href="#header.accept" id="rfc.xref.header.accept.3" title="Accept">Section&nbsp;6.1</a> 
                   </td>
                </tr>
@@ -1374 +1383 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;5.2</a> 
+                  <td class="left"> <a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;6.2</a> 
                   </td>
                </tr>
@@ -1381 +1390 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;5.3</a> 
+                  <td class="left"> <a href="#header.accept-encoding" id="rfc.xref.header.accept-encoding.3" title="Accept-Encoding">Section&nbsp;6.3</a> 
                   </td>
                </tr>
@@ -1388 +1397 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;5.4</a> 
+                  <td class="left"> <a href="#header.accept-language" id="rfc.xref.header.accept-language.2" title="Accept-Language">Section&nbsp;6.4</a> 
                   </td>
                </tr>
@@ -1402 +1411 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section&nbsp;5.5</a> 
+                  <td class="left"> <a href="#header.content-encoding" id="rfc.xref.header.content-encoding.4" title="Content-Encoding">Section&nbsp;6.5</a> 
                   </td>
                </tr>
@@ -1409 +1418 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;5.6</a> 
+                  <td class="left"> <a href="#header.content-language" id="rfc.xref.header.content-language.2" title="Content-Language">Section&nbsp;6.6</a> 
                   </td>
                </tr>
@@ -1416 +1425 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;5.7</a> 
+                  <td class="left"> <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;6.7</a> 
                   </td>
                </tr>
@@ -1423 +1432 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.content-md5" id="rfc.xref.header.content-md5.2" title="Content-MD5">Section&nbsp;5.8</a> 
+                  <td class="left"> <a href="#header.content-md5" id="rfc.xref.header.content-md5.2" title="Content-MD5">Section&nbsp;6.8</a> 
                   </td>
                </tr>
@@ -1430 +1439 @@
                   <td class="left">http</td>
                   <td class="left">standard</td>
-                  <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;5.9</a> 
+                  <td class="left"> <a href="#header.content-type" id="rfc.xref.header.content-type.3" title="Content-Type">Section&nbsp;6.9</a> 
                   </td>
                </tr>
@@ -1443 +1452 @@
          </table>
       </div>
-      <p id="rfc.section.6.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
-      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="content.coding.registration" href="#content.coding.registration">Content Coding Registry</a></h2>
-      <p id="rfc.section.6.2.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;2.2.1</a> of this document.
-      </p>
-      <p id="rfc.section.6.2.p.2">The HTTP Content Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; should be updated with the registration below:
+      <p id="rfc.section.7.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
+      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="content.coding.registration" href="#content.coding.registration">Content Coding Registry</a></h2>
+      <p id="rfc.section.7.2.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;2.2.1</a> of this document.
+      </p>
+      <p id="rfc.section.7.2.p.2">The HTTP Content Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; should be updated with the registration below:
       </p>
       <div id="rfc.table.2">
@@ -1488 +1497 @@
          </table>
       </div>
-      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
-      <p id="rfc.section.7.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
+      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
+      <p id="rfc.section.8.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
          as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does
          make some suggestions for reducing security risks.
       </p>
-      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="privacy.issues.connected.to.accept.headers" href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></h2>
-      <p id="rfc.section.7.1.p.1">Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header
+      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="privacy.issues.connected.to.accept.headers" href="#privacy.issues.connected.to.accept.headers">Privacy Issues Connected to Accept Headers</a></h2>
+      <p id="rfc.section.8.1.p.1">Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header
          in particular can reveal information the user would consider to be of a private nature, because the understanding of particular
          languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option
@@ -1500 +1509 @@
          process include a message which makes the user aware of the loss of privacy involved.
       </p>
-      <p id="rfc.section.7.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default,
+      <p id="rfc.section.8.1.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default,
          and to ask the user whether or not to start sending Accept-Language headers to a server if it detects, by looking for any
          Vary response-header fields generated by the server, that such sending could improve the quality of service.
       </p>
-      <p id="rfc.section.7.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be
+      <p id="rfc.section.8.1.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be
          used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers
          to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions
@@ -1512 +1521 @@
          filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
       </p>
-      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="content-disposition.issues" href="#content-disposition.issues">Content-Disposition Issues</a></h2>
-      <p id="rfc.section.7.2.p.1"> <a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, from which the often implemented Content-Disposition (see <a href="#content-disposition" id="rfc.xref.content-disposition.2" title="Content-Disposition">Appendix&nbsp;B.1</a>) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the
+      <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="content-disposition.issues" href="#content-disposition.issues">Content-Disposition Issues</a></h2>
+      <p id="rfc.section.8.2.p.1"> <a href="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>, from which the often implemented Content-Disposition (see <a href="#content-disposition" id="rfc.xref.content-disposition.2" title="Content-Disposition">Appendix&nbsp;B.1</a>) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the
          HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See <a href="http://tools.ietf.org/html/rfc2183#section-5">Section 5</a> of <a href="#RFC2183" id="rfc.xref.RFC2183.2"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> for details.
       </p>
-      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
-      <h1 id="rfc.references"><a id="rfc.section.9" href="#rfc.section.9">9.</a> References
+      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
+      <h1 id="rfc.references"><a id="rfc.section.10" href="#rfc.section.10">10.</a> References
       </h1>
-      <h2 id="rfc.references.1"><a href="#rfc.section.9.1" id="rfc.section.9.1">9.1</a> Normative References
+      <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References
       </h2>
       <table>                                
@@ -1605 +1614 @@
          </tr>
       </table>
-      <h2 id="rfc.references.2"><a href="#rfc.section.9.2" id="rfc.section.9.2">9.2</a> Informative References
+      <h2 id="rfc.references.2"><a href="#rfc.section.10.2" id="rfc.section.10.2">10.2</a> Informative References
       </h2>
       <table>                                
@@ -1724 +1733 @@
          environments.
       </p>
-      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span>  <a href="#mime-version" class="smpl">MIME-Version</a>   = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a>
+      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span>  <a href="#mime-version" class="smpl">MIME-Version</a>   = "MIME-Version" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#mime-version" class="smpl">MIME-Version-v</a>
   <a href="#mime-version" class="smpl">MIME-Version-v</a> = 1*<a href="#notation" class="smpl">DIGIT</a> "." 1*<a href="#notation" class="smpl">DIGIT</a>
 </pre><p id="rfc.section.A.1.p.3">MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this
@@ -1782 +1791 @@
          in <a href="#RFC2183" id="rfc.xref.RFC2183.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a>.
       </p>
-      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span>  <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a>
+      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span>  <a href="#content-disposition" class="smpl">content-disposition</a> = "Content-Disposition" ":" <a href="#core.rules" class="smpl">OWS</a>
                         <a href="#content-disposition" class="smpl">content-disposition-v</a>
   <a href="#content-disposition" class="smpl">content-disposition-v</a> = <a href="#content-disposition" class="smpl">disposition-type</a>
@@ -1792 +1801 @@
   <a href="#content-disposition" class="smpl">disp-extension-parm</a> = <a href="#core.rules" class="smpl">token</a> "=" <a href="#core.rules" class="smpl">word</a>
 </pre><p id="rfc.section.B.1.p.3">An example is</p>
-      <div id="rfc.figure.u.36"></div><pre class="text">  Content-Disposition: attachment; filename="fname.ext"
+      <div id="rfc.figure.u.37"></div><pre class="text">  Content-Disposition: attachment; filename="fname.ext"
 </pre><p id="rfc.section.B.1.p.5">The receiving user agent <em class="bcp14">SHOULD NOT</em> respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply
          to HTTP implementations at this time. The filename <em class="bcp14">SHOULD</em> be treated as a terminal component only.
@@ -1799 +1808 @@
          agent should not display the response, but directly enter a "save response as..." dialog.
       </p>
-      <p id="rfc.section.B.1.p.7">See <a href="#content-disposition.issues" title="Content-Disposition Issues">Section&nbsp;7.2</a> for Content-Disposition security issues.
+      <p id="rfc.section.B.1.p.7">See <a href="#content-disposition.issues" title="Content-Disposition Issues">Section&nbsp;8.2</a> for Content-Disposition security issues.
       </p>
       <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
@@ -1806 +1815 @@
       <p id="rfc.section.C.p.2">Remove base URI setting semantics for Content-Location due to poor implementation support, which was caused by too many broken
          servers emitting bogus Content-Location headers, and also the potentially undesirable effect of potentially breaking relative
-         links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;5.7</a>)
+         links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section&nbsp;6.7</a>)
       </p>
       <p id="rfc.section.C.p.3">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
       </p>
       <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
-      <div id="rfc.figure.u.37"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v
+      <div id="rfc.figure.u.38"></div> <pre class="inline"><a href="#header.accept" class="smpl">Accept</a> = "Accept:" OWS Accept-v
 <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = "Accept-Charset:" OWS Accept-Charset-v
 <a href="#header.accept-charset" class="smpl">Accept-Charset-v</a> = *( "," OWS ) ( charset / "*" ) [ OWS ";" OWS "q="
@@ -1868 +1877 @@
 <a href="#content-disposition" class="smpl">disposition-type</a> = "attachment" / disp-extension-token
 
-<a href="#entity.header.fields" class="smpl">entity-header</a> = Content-Encoding / Content-Language / Content-Length
- / Content-Location / Content-MD5 / Content-Range / Content-Type /
- Expires / Last-Modified / extension-header
-<a href="#entity.header.fields" class="smpl">extension-header</a> = header-field
-
 <a href="#content-disposition" class="smpl">filename-parm</a> = "filename=" quoted-string
 
@@ -1898 +1902 @@
 
 <a href="#core.rules" class="smpl">word</a> = &lt;word, defined in [Part1], Section 1.2.2&gt;
-</pre> <div id="rfc.figure.u.38"></div>
+</pre> <div id="rfc.figure.u.39"></div>
       <p>ABNF diagnostics:</p><pre class="inline">; Accept defined but not used
 ; Accept-Charset defined but not used
@@ -1905 +1909 @@
 ; MIME-Version defined but not used
 ; content-disposition defined but not used
-; entity-header defined but not used
 </pre><h1 id="rfc.section.E"><a href="#rfc.section.E">E.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
       <h2 id="rfc.section.E.1"><a href="#rfc.section.E.1">E.1</a>&nbsp;Since RFC2616
@@ -2090 +2093 @@
          <ul class="ind">
             <li class="indline0"><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul class="ind">
-                  <li class="indline1">Accept header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">4.1</a>, <a class="iref" href="#rfc.iref.a.1"><b>5.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">6.1</a></li>
-                  <li class="indline1">Accept-Charset header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-charset.1">4.1</a>, <a class="iref" href="#rfc.iref.a.2"><b>5.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">6.1</a></li>
-                  <li class="indline1">Accept-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.a.3"><b>5.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">6.1</a></li>
-                  <li class="indline1">Accept-Language header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-language.1">4.1</a>, <a class="iref" href="#rfc.iref.a.4"><b>5.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">6.1</a></li>
+                  <li class="indline1">Accept header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">5.1</a>, <a class="iref" href="#rfc.iref.a.1"><b>6.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">7.1</a></li>
+                  <li class="indline1">Accept-Charset header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-charset.1">5.1</a>, <a class="iref" href="#rfc.iref.a.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">7.1</a></li>
+                  <li class="indline1">Accept-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">5.1</a>, <a class="iref" href="#rfc.iref.a.3"><b>6.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">7.1</a></li>
+                  <li class="indline1">Accept-Language header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-language.1">5.1</a>, <a class="iref" href="#rfc.iref.a.4"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">7.1</a></li>
                </ul>
             </li>
             <li class="indline0"><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul class="ind">
-                  <li class="indline1"><em>BCP97</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.BCP97.1">9.1</a>, <a class="iref" href="#rfc.xref.BCP97.2">9.1</a>, <a class="iref" href="#rfc.xref.BCP97.3">9.1</a>, <a class="iref" href="#BCP97"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.BCP97.4">E.5</a></li>
+                  <li class="indline1"><em>BCP97</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.BCP97.1">10.1</a>, <a class="iref" href="#rfc.xref.BCP97.2">10.1</a>, <a class="iref" href="#rfc.xref.BCP97.3">10.1</a>, <a class="iref" href="#BCP97"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.BCP97.4">E.5</a></li>
                </ul>
             </li>
@@ -2111 +2114 @@
                   <li class="indline1">compress (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.2">2.2</a></li>
                   <li class="indline1">content negotiation&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.1">1.1</a></li>
-                  <li class="indline1">Content-Disposition header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.content-disposition.1">6.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">7.2</a>, <a class="iref" href="#rfc.iref.c.12"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li>
-                  <li class="indline1">Content-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">3.1</a>, <a class="iref" href="#rfc.iref.c.7"><b>5.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">5.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">6.1</a></li>
-                  <li class="indline1">Content-Language header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-language.1">3.1</a>, <a class="iref" href="#rfc.iref.c.8"><b>5.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">6.1</a></li>
-                  <li class="indline1">Content-Location header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-location.1">3.1</a>, <a class="iref" href="#rfc.iref.c.9"><b>5.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">6.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li>
-                  <li class="indline1">Content-MD5 header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.c.10"><b>5.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">6.1</a></li>
-                  <li class="indline1">Content-Type header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">3.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>5.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">6.1</a></li>
+                  <li class="indline1">Content-Disposition header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.content-disposition.1">7.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">8.2</a>, <a class="iref" href="#rfc.iref.c.12"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li>
+                  <li class="indline1">Content-Encoding header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.c.7"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">6.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">7.1</a></li>
+                  <li class="indline1">Content-Language header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-language.1">4.1</a>, <a class="iref" href="#rfc.iref.c.8"><b>6.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">7.1</a></li>
+                  <li class="indline1">Content-Location header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-location.1">4.1</a>, <a class="iref" href="#rfc.iref.c.9"><b>6.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">7.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li>
+                  <li class="indline1">Content-MD5 header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.c.10"><b>6.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">7.1</a></li>
+                  <li class="indline1">Content-Type header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">4.1</a>, <a class="iref" href="#rfc.iref.c.11"><b>6.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">7.1</a></li>
                </ul>
             </li>
@@ -2126 +2129 @@
                   <li class="indline1"><tt>Grammar</tt>&nbsp;&nbsp;
                      <ul class="ind">
-                        <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>5.1</b></a></li>
-                        <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>5.2</b></a></li>
-                        <li class="indline1"><tt>Accept-Charset-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>5.2</b></a></li>
-                        <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>5.3</b></a></li>
-                        <li class="indline1"><tt>Accept-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>5.3</b></a></li>
-                        <li class="indline1"><tt>accept-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li>
-                        <li class="indline1"><tt>Accept-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>5.4</b></a></li>
-                        <li class="indline1"><tt>Accept-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>5.4</b></a></li>
-                        <li class="indline1"><tt>accept-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>5.1</b></a></li>
-                        <li class="indline1"><tt>Accept-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>5.1</b></a></li>
+                        <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>6.2</b></a></li>
+                        <li class="indline1"><tt>Accept-Charset-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>6.2</b></a></li>
+                        <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>6.3</b></a></li>
+                        <li class="indline1"><tt>Accept-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.19"><b>6.3</b></a></li>
+                        <li class="indline1"><tt>accept-ext</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>Accept-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>6.4</b></a></li>
+                        <li class="indline1"><tt>Accept-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>6.4</b></a></li>
+                        <li class="indline1"><tt>accept-params</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>6.1</b></a></li>
+                        <li class="indline1"><tt>Accept-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>6.1</b></a></li>
                         <li class="indline1"><tt>attribute</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.8"><b>2.3</b></a></li>
                         <li class="indline1"><tt>charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.1"><b>2.1</b></a></li>
-                        <li class="indline1"><tt>codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li>
+                        <li class="indline1"><tt>codings</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>6.3</b></a></li>
                         <li class="indline1"><tt>content-coding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.2"><b>2.2</b></a></li>
-                        <li class="indline1"><tt>content-disposition</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>content-disposition-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>Content-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>5.5</b></a></li>
-                        <li class="indline1"><tt>Content-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>5.5</b></a></li>
-                        <li class="indline1"><tt>Content-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>5.6</b></a></li>
-                        <li class="indline1"><tt>Content-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>5.6</b></a></li>
-                        <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>5.7</b></a></li>
-                        <li class="indline1"><tt>Content-Location-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>5.7</b></a></li>
-                        <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>5.8</b></a></li>
-                        <li class="indline1"><tt>Content-MD5-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>5.8</b></a></li>
-                        <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>5.9</b></a></li>
-                        <li class="indline1"><tt>Content-Type-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>5.9</b></a></li>
-                        <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.44"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.43"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>entity-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>3.1</b></a></li>
-                        <li class="indline1"><tt>extension-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>3.1</b></a></li>
-                        <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li>
-                        <li class="indline1"><tt>language-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>5.4</b></a></li>
+                        <li class="indline1"><tt>content-disposition</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>content-disposition-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>Content-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.24"><b>6.5</b></a></li>
+                        <li class="indline1"><tt>Content-Encoding-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.25"><b>6.5</b></a></li>
+                        <li class="indline1"><tt>Content-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.26"><b>6.6</b></a></li>
+                        <li class="indline1"><tt>Content-Language-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>6.6</b></a></li>
+                        <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>6.7</b></a></li>
+                        <li class="indline1"><tt>Content-Location-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>6.7</b></a></li>
+                        <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>6.8</b></a></li>
+                        <li class="indline1"><tt>Content-MD5-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>6.8</b></a></li>
+                        <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.32"><b>6.9</b></a></li>
+                        <li class="indline1"><tt>Content-Type-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.33"><b>6.9</b></a></li>
+                        <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.42"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.41"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.39"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.40"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>language-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.23"><b>6.4</b></a></li>
                         <li class="indline1"><tt>language-tag</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>2.4</b></a></li>
-                        <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>5.1</b></a></li>
+                        <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>6.1</b></a></li>
                         <li class="indline1"><tt>media-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.4"><b>2.3</b></a></li>
-                        <li class="indline1"><tt>MIME-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><b>A.1</b></a></li>
-                        <li class="indline1"><tt>MIME-Version-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>A.1</b></a></li>
+                        <li class="indline1"><tt>MIME-Version</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>A.1</b></a></li>
+                        <li class="indline1"><tt>MIME-Version-v</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>A.1</b></a></li>
                         <li class="indline1"><tt>parameter</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.7"><b>2.3</b></a></li>
                         <li class="indline1"><tt>subtype</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.6"><b>2.3</b></a></li>
@@ -2177 +2178 @@
                   <li class="indline1">Headers&nbsp;&nbsp;
                      <ul class="ind">
-                        <li class="indline1">Accept&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">4.1</a>, <a class="iref" href="#rfc.iref.h.1"><b>5.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">6.1</a></li>
-                        <li class="indline1">Accept-Charset&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-charset.1">4.1</a>, <a class="iref" href="#rfc.iref.h.2"><b>5.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">6.1</a></li>
-                        <li class="indline1">Accept-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.h.3"><b>5.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">6.1</a></li>
-                        <li class="indline1">Accept-Language&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-language.1">4.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>5.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">6.1</a></li>
-                        <li class="indline1">Content-Disposition&nbsp;&nbsp;<a class="iref" href="#rfc.xref.content-disposition.1">6.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">7.2</a>, <a class="iref" href="#rfc.iref.h.11"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li>
-                        <li class="indline1">Content-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">3.1</a>, <a class="iref" href="#rfc.iref.h.5"><b>5.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">5.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">6.1</a></li>
-                        <li class="indline1">Content-Language&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-language.1">3.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>5.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">6.1</a></li>
-                        <li class="indline1">Content-Location&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-location.1">3.1</a>, <a class="iref" href="#rfc.iref.h.7"><b>5.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">6.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li>
-                        <li class="indline1">Content-MD5&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>5.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">6.1</a></li>
-                        <li class="indline1">Content-Type&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">3.1</a>, <a class="iref" href="#rfc.iref.h.9"><b>5.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">6.1</a></li>
-                        <li class="indline1">MIME-Version&nbsp;&nbsp;<a class="iref" href="#rfc.xref.mime-version.1">6.1</a>, <a class="iref" href="#rfc.iref.h.10"><b>A.1</b></a></li>
+                        <li class="indline1">Accept&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept.1">2.3</a>, <a class="iref" href="#rfc.xref.header.accept.2">5.1</a>, <a class="iref" href="#rfc.iref.h.1"><b>6.1</b></a>, <a class="iref" href="#rfc.xref.header.accept.3">7.1</a></li>
+                        <li class="indline1">Accept-Charset&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-charset.1">5.1</a>, <a class="iref" href="#rfc.iref.h.2"><b>6.2</b></a>, <a class="iref" href="#rfc.xref.header.accept-charset.2">7.1</a></li>
+                        <li class="indline1">Accept-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.accept-encoding.2">5.1</a>, <a class="iref" href="#rfc.iref.h.3"><b>6.3</b></a>, <a class="iref" href="#rfc.xref.header.accept-encoding.3">7.1</a></li>
+                        <li class="indline1">Accept-Language&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.accept-language.1">5.1</a>, <a class="iref" href="#rfc.iref.h.4"><b>6.4</b></a>, <a class="iref" href="#rfc.xref.header.accept-language.2">7.1</a></li>
+                        <li class="indline1">Content-Disposition&nbsp;&nbsp;<a class="iref" href="#rfc.xref.content-disposition.1">7.1</a>, <a class="iref" href="#rfc.xref.content-disposition.2">8.2</a>, <a class="iref" href="#rfc.iref.h.11"><b>B.1</b></a>, <a class="iref" href="#rfc.extref.c.32">B.1</a>, <a class="iref" href="#rfc.extref.c.50">D</a></li>
+                        <li class="indline1">Content-Encoding&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-encoding.1">2.2</a>, <a class="iref" href="#rfc.xref.header.content-encoding.2">4.1</a>, <a class="iref" href="#rfc.iref.h.5"><b>6.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">6.5</a>, <a class="iref" href="#rfc.xref.header.content-encoding.4">7.1</a></li>
+                        <li class="indline1">Content-Language&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-language.1">4.1</a>, <a class="iref" href="#rfc.iref.h.6"><b>6.6</b></a>, <a class="iref" href="#rfc.xref.header.content-language.2">7.1</a></li>
+                        <li class="indline1">Content-Location&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-location.1">4.1</a>, <a class="iref" href="#rfc.iref.h.7"><b>6.7</b></a>, <a class="iref" href="#rfc.xref.header.content-location.2">7.1</a>, <a class="iref" href="#rfc.xref.header.content-location.3">C</a></li>
+                        <li class="indline1">Content-MD5&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-md5.1">3.1</a>, <a class="iref" href="#rfc.iref.h.8"><b>6.8</b></a>, <a class="iref" href="#rfc.xref.header.content-md5.2">7.1</a></li>
+                        <li class="indline1">Content-Type&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.content-type.1">2.3</a>, <a class="iref" href="#rfc.xref.header.content-type.2">4.1</a>, <a class="iref" href="#rfc.iref.h.9"><b>6.9</b></a>, <a class="iref" href="#rfc.xref.header.content-type.3">7.1</a></li>
+                        <li class="indline1">MIME-Version&nbsp;&nbsp;<a class="iref" href="#rfc.xref.mime-version.1">7.1</a>, <a class="iref" href="#rfc.iref.h.10"><b>A.1</b></a></li>
                      </ul>
                   </li>
@@ -2194 +2195 @@
             <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind">
                   <li class="indline1">identity (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1">2.2</a></li>
-                  <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">2.1.1</a>, <a class="iref" href="#ISO-8859-1"><b>9.1</b></a></li>
+                  <li class="indline1"><em>ISO-8859-1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.ISO-8859-1.1">2.1.1</a>, <a class="iref" href="#ISO-8859-1"><b>10.1</b></a></li>
                </ul>
             </li>
             <li class="indline0"><a id="rfc.index.M" href="#rfc.index.M"><b>M</b></a><ul class="ind">
-                  <li class="indline1">MIME-Version header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.mime-version.1">6.1</a>, <a class="iref" href="#rfc.iref.m.1"><b>A.1</b></a></li>
+                  <li class="indline1">MIME-Version header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.mime-version.1">7.1</a>, <a class="iref" href="#rfc.iref.m.1"><b>A.1</b></a></li>
                </ul>
             </li>
             <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
-                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">5.1</a>, <a class="iref" href="#rfc.xref.Part1.20">5.3</a>, <a class="iref" href="#rfc.xref.Part1.21">5.7</a>, <a class="iref" href="#rfc.xref.Part1.22">6.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a>, <a class="iref" href="#Part1"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.Part1.25">A.3</a>, <a class="iref" href="#rfc.xref.Part1.26">A.6</a><ul class="ind">
+                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a>, <a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.9">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.16">2.2.1</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a>, <a class="iref" href="#rfc.xref.Part1.18">3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">6.1</a>, <a class="iref" href="#rfc.xref.Part1.20">6.3</a>, <a class="iref" href="#rfc.xref.Part1.21">6.7</a>, <a class="iref" href="#rfc.xref.Part1.22">7.2</a>, <a class="iref" href="#rfc.xref.Part1.23">7.2</a>, <a class="iref" href="#rfc.xref.Part1.24">7.2</a>, <a class="iref" href="#Part1"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.Part1.25">A.3</a>, <a class="iref" href="#rfc.xref.Part1.26">A.6</a><ul class="ind">
                         <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1.3</a></li>
                         <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.3">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.3.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.3.1</a></li>
@@ -2208 +2209 @@
                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.3.2</a></li>
                         <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">3.2</a></li>
-                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">5.7</a></li>
+                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">6.7</a></li>
                         <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.25">A.3</a></li>
                         <li class="indline1"><em>Section 6.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">2.2.1</a></li>
-                        <li class="indline1"><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.22">6.2</a></li>
+                        <li class="indline1"><em>Section 6.2.2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">2.2</a>, <a class="iref" href="#rfc.xref.Part1.22">7.2</a></li>
                         <li class="indline1"><em>Section 6.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.16">2.2.1</a></li>
-                        <li class="indline1"><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.23">6.2</a></li>
-                        <li class="indline1"><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">6.2</a></li>
-                        <li class="indline1"><em>Section 6.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">5.1</a>, <a class="iref" href="#rfc.xref.Part1.20">5.3</a></li>
+                        <li class="indline1"><em>Section 6.2.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.13">2.2</a>, <a class="iref" href="#rfc.xref.Part1.23">7.2</a></li>
+                        <li class="indline1"><em>Section 6.2.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">2.2</a>, <a class="iref" href="#rfc.xref.Part1.24">7.2</a></li>
+                        <li class="indline1"><em>Section 6.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.11">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.19">6.1</a>, <a class="iref" href="#rfc.xref.Part1.20">6.3</a></li>
                         <li class="indline1"><em>Section 9.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">1.3.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3.1</a></li>
                         <li class="indline1"><em>Section 9.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">A.6</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind">
-                        <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a></li>
+                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">5.1</a>, <a class="iref" href="#Part2"><b>10.1</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">5.1</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2">3.1</a>, <a class="iref" href="#Part4"><b>9.1</b></a><ul class="ind">
-                        <li class="indline1"><em>Section 6.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2">3.1</a></li>
+                  <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2">4.1</a>, <a class="iref" href="#Part4"><b>10.1</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 6.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part4.2">4.1</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a>, <a class="iref" href="#Part5"><b>9.1</b></a><ul class="ind">
+                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a>, <a class="iref" href="#Part5"><b>10.1</b></a><ul class="ind">
                         <li class="indline1"><em>Section 5.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a>, <a class="iref" href="#rfc.xref.Part6.3">4.1</a>, <a class="iref" href="#Part6"><b>9.1</b></a><ul class="ind">
-                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a></li>
-                        <li class="indline1"><em>Section 3.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.3">4.1</a></li>
+                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a>, <a class="iref" href="#rfc.xref.Part6.3">5.1</a>, <a class="iref" href="#Part6"><b>10.1</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a></li>
+                        <li class="indline1"><em>Section 3.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.3">5.1</a></li>
                      </ul>
                   </li>
-                  <li class="indline1">payload&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1">1.1</a></li>
+                  <li class="indline1">payload&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1">3</a></li>
                </ul>
             </li>
             <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind">
-                  <li class="indline1">representation&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.1">1.1</a></li>
-                  <li class="indline1"><em>RFC1864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1864.1">5.8</a>, <a class="iref" href="#rfc.xref.RFC1864.2">5.8</a>, <a class="iref" href="#RFC1864"><b>9.1</b></a></li>
-                  <li class="indline1"><em>RFC1945</em>&nbsp;&nbsp;<a class="iref" href="#RFC1945"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li>
-                  <li class="indline1"><em>RFC1950</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1950.1">6.2</a>, <a class="iref" href="#RFC1950"><b>9.1</b></a></li>
-                  <li class="indline1"><em>RFC1951</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1951.1">6.2</a>, <a class="iref" href="#RFC1951"><b>9.1</b></a></li>
-                  <li class="indline1"><em>RFC1952</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1952.1">6.2</a>, <a class="iref" href="#RFC1952"><b>9.1</b></a></li>
-                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#RFC2045"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a></li>
-                  <li class="indline1"><em>RFC2046</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a>, <a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a>, <a class="iref" href="#RFC2046"><b>9.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.4">A.2</a><ul class="ind">
-                        <li class="indline1"><em>Section 4.5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.3">3.2.1</a></li>
+                  <li class="indline1">representation&nbsp;&nbsp;<a class="iref" href="#rfc.iref.r.1">4</a></li>
+                  <li class="indline1"><em>RFC1864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1864.1">6.8</a>, <a class="iref" href="#rfc.xref.RFC1864.2">6.8</a>, <a class="iref" href="#RFC1864"><b>10.1</b></a></li>
+                  <li class="indline1"><em>RFC1945</em>&nbsp;&nbsp;<a class="iref" href="#RFC1945"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC1945.1">B</a></li>
+                  <li class="indline1"><em>RFC1950</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1950.1">7.2</a>, <a class="iref" href="#RFC1950"><b>10.1</b></a></li>
+                  <li class="indline1"><em>RFC1951</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1951.1">7.2</a>, <a class="iref" href="#RFC1951"><b>10.1</b></a></li>
+                  <li class="indline1"><em>RFC1952</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1952.1">7.2</a>, <a class="iref" href="#RFC1952"><b>10.1</b></a></li>
+                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#RFC2045"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a></li>
+                  <li class="indline1"><em>RFC2046</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.1">2.3</a>, <a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a>, <a class="iref" href="#rfc.xref.RFC2046.3">4.2</a>, <a class="iref" href="#RFC2046"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.RFC2046.4">A.2</a><ul class="ind">
+                        <li class="indline1"><em>Section 4.5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.3">4.2</a></li>
                         <li class="indline1"><em>Section 5.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.2">2.3.2</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>RFC2049</em>&nbsp;&nbsp;<a class="iref" href="#RFC2049"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a><ul class="ind">
+                  <li class="indline1"><em>RFC2049</em>&nbsp;&nbsp;<a class="iref" href="#RFC2049"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2049.1">A.2</a><ul class="ind">
                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2049.1">A.2</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">9.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">9.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">9.1</a>, <a class="iref" href="#RFC2068"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.4">B</a></li>
-                  <li class="indline1"><em>RFC2076</em>&nbsp;&nbsp;<a class="iref" href="#RFC2076"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2076.1">B</a></li>
-                  <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.2</a>, <a class="iref" href="#RFC2119"><b>9.1</b></a></li>
-                  <li class="indline1"><em>RFC2183</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2183.1">7.2</a>, <a class="iref" href="#rfc.xref.RFC2183.2">7.2</a>, <a class="iref" href="#RFC2183"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2183.3">B.1</a><ul class="ind">
-                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2183.2">7.2</a></li>
+                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">10.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">10.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">10.1</a>, <a class="iref" href="#RFC2068"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.4">B</a></li>
+                  <li class="indline1"><em>RFC2076</em>&nbsp;&nbsp;<a class="iref" href="#RFC2076"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2076.1">B</a></li>
+                  <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.2</a>, <a class="iref" href="#RFC2119"><b>10.1</b></a></li>
+                  <li class="indline1"><em>RFC2183</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2183.1">8.2</a>, <a class="iref" href="#rfc.xref.RFC2183.2">8.2</a>, <a class="iref" href="#RFC2183"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2183.3">B.1</a><ul class="ind">
+                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2183.2">8.2</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>RFC2277</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2277.1">2.1</a>, <a class="iref" href="#RFC2277"><b>9.2</b></a></li>
-                  <li class="indline1"><em>RFC2295</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2295.1">4</a>, <a class="iref" href="#RFC2295"><b>9.2</b></a></li>
-                  <li class="indline1"><em>RFC2388</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2388.1">2.3.2</a>, <a class="iref" href="#RFC2388"><b>9.2</b></a></li>
-                  <li class="indline1"><em>RFC2557</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2557.1">5.7</a>, <a class="iref" href="#RFC2557"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.2">A.7</a><ul class="ind">
-                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2557.1">5.7</a></li>
+                  <li class="indline1"><em>RFC2277</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2277.1">2.1</a>, <a class="iref" href="#RFC2277"><b>10.2</b></a></li>
+                  <li class="indline1"><em>RFC2295</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2295.1">5</a>, <a class="iref" href="#RFC2295"><b>10.2</b></a></li>
+                  <li class="indline1"><em>RFC2388</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2388.1">2.3.2</a>, <a class="iref" href="#RFC2388"><b>10.2</b></a></li>
+                  <li class="indline1"><em>RFC2557</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2557.1">6.7</a>, <a class="iref" href="#RFC2557"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.2">A.7</a><ul class="ind">
+                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2557.1">6.7</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">5.4</a>, <a class="iref" href="#RFC2616"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">E.1</a><ul class="ind">
-                        <li class="indline1"><em>Section 14.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.2">5.4</a></li>
+                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">6.4</a>, <a class="iref" href="#RFC2616"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">E.1</a><ul class="ind">
+                        <li class="indline1"><em>Section 14.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.2">6.4</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>RFC3629</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3629.1">2.1</a>, <a class="iref" href="#RFC3629"><b>9.2</b></a></li>
-                  <li class="indline1"><em>RFC3864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3864.1">6.1</a>, <a class="iref" href="#RFC3864"><b>9.2</b></a></li>
-                  <li class="indline1"><em>RFC4288</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4288.1">2.3</a>, <a class="iref" href="#RFC4288"><b>9.2</b></a></li>
-                  <li class="indline1"><em>RFC4647</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.1">5.4</a>, <a class="iref" href="#rfc.xref.RFC4647.2">5.4</a>, <a class="iref" href="#rfc.xref.RFC4647.3">5.4</a>, <a class="iref" href="#rfc.xref.RFC4647.4">5.4</a>, <a class="iref" href="#RFC4647"><b>9.1</b></a><ul class="ind">
-                        <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.1">5.4</a></li>
-                        <li class="indline1"><em>Section 2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.2">5.4</a></li>
-                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.3">5.4</a></li>
-                        <li class="indline1"><em>Section 3.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.4">5.4</a></li>
+                  <li class="indline1"><em>RFC3629</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3629.1">2.1</a>, <a class="iref" href="#RFC3629"><b>10.2</b></a></li>
+                  <li class="indline1"><em>RFC3864</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC3864.1">7.1</a>, <a class="iref" href="#RFC3864"><b>10.2</b></a></li>
+                  <li class="indline1"><em>RFC4288</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4288.1">2.3</a>, <a class="iref" href="#RFC4288"><b>10.2</b></a></li>
+                  <li class="indline1"><em>RFC4647</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.1">6.4</a>, <a class="iref" href="#rfc.xref.RFC4647.2">6.4</a>, <a class="iref" href="#rfc.xref.RFC4647.3">6.4</a>, <a class="iref" href="#rfc.xref.RFC4647.4">6.4</a>, <a class="iref" href="#RFC4647"><b>10.1</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.1">6.4</a></li>
+                        <li class="indline1"><em>Section 2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.2">6.4</a></li>
+                        <li class="indline1"><em>Section 3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.3">6.4</a></li>
+                        <li class="indline1"><em>Section 3.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC4647.4">6.4</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>RFC5226</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5226.1">2.2.1</a>, <a class="iref" href="#RFC5226"><b>9.2</b></a><ul class="ind">
+                  <li class="indline1"><em>RFC5226</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5226.1">2.2.1</a>, <a class="iref" href="#RFC5226"><b>10.2</b></a><ul class="ind">
                         <li class="indline1"><em>Section 4.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5226.1">2.2.1</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>RFC5234</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5234.1">1.3</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.3</a>, <a class="iref" href="#RFC5234"><b>9.1</b></a><ul class="ind">
+                  <li class="indline1"><em>RFC5234</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5234.1">1.3</a>, <a class="iref" href="#rfc.xref.RFC5234.2">1.3</a>, <a class="iref" href="#RFC5234"><b>10.1</b></a><ul class="ind">
                         <li class="indline1"><em>Appendix B.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5234.2">1.3</a></li>
                      </ul>
                   </li>
-                  <li class="indline1"><em>RFC5322</em>&nbsp;&nbsp;<a class="iref" href="#RFC5322"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC5322.1">A</a></li>
-                  <li class="indline1"><em>RFC5646</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5646.1">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.2">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.3">2.4</a>, <a class="iref" href="#RFC5646"><b>9.1</b></a><ul class="ind">
+                  <li class="indline1"><em>RFC5322</em>&nbsp;&nbsp;<a class="iref" href="#RFC5322"><b>10.2</b></a>, <a class="iref" href="#rfc.xref.RFC5322.1">A</a></li>
+                  <li class="indline1"><em>RFC5646</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5646.1">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.2">2.4</a>, <a class="iref" href="#rfc.xref.RFC5646.3">2.4</a>, <a class="iref" href="#RFC5646"><b>10.1</b></a><ul class="ind">
                         <li class="indline1"><em>Section 2.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC5646.2">2.4</a></li>
                      </ul>

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

@@ -627 +627 @@
       <div id="rfc.figure.u.2"></div><pre class="inline">  <a href="#abnf.dependencies" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>&gt;
 </pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="entity.tags" href="#entity.tags">Entity-Tags</a></h1>
-      <p id="rfc.section.2.p.1">Entity-tags are used for comparing two or more representations from the same requested resource. HTTP/1.1 uses entity-tags
-         in the ETag (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;6.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section&nbsp;6.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section&nbsp;6.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
+      <p id="rfc.section.2.p.1">Entity-tags are used for comparing two or more representations of the same resource. HTTP/1.1 uses entity-tags in the ETag
+         (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;6.1</a>), If-Match (<a href="#header.if-match" id="rfc.xref.header.if-match.1" title="If-Match">Section&nbsp;6.2</a>), If-None-Match (<a href="#header.if-none-match" id="rfc.xref.header.if-none-match.1" title="If-None-Match">Section&nbsp;6.4</a>), and If-Range (<a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) header fields. The definition of how they are used and compared as cache validators is in <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
       </p>
       <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span>  <a href="#entity.tags" class="smpl">entity-tag</a> = [ <a href="#entity.tags" class="smpl">weak</a> ] <a href="#entity.tags" class="smpl">opaque-tag</a>
@@ -642 +642 @@
       </p>
       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="example.entity.tag.vs.conneg" href="#example.entity.tag.vs.conneg">Example: Entity-tags varying on Content-Negotiated Resources</a></h2>
-      <p id="rfc.section.2.1.p.1">Consider a resource that is subject to content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>):
+      <p id="rfc.section.2.1.p.1">Consider a resource that is subject to content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), and where the representations returned upon a GET request vary based on the Accept-Encoding request header field (<a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>):
       </p>
       <div id="rfc.figure.u.4"></div>
@@ -893 +893 @@
       <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
       <p id="rfc.section.6.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to conditional requests.</p>
-      <p id="rfc.section.6.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
-         receives the message.
-      </p>
       <div id="rfc.iref.e.1"></div>
       <div id="rfc.iref.h.1"></div>
       <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
-      <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section&nbsp;2</a>) for one representation of the resource identified by the Effective Request URI. An entity-tag is intended for use as a resource-local
+      <p id="rfc.section.6.1.p.1">The "ETag" response-header field provides the current value of the entity-tag (see <a href="#entity.tags" title="Entity-Tags">Section&nbsp;2</a>) for one representation of the resource identified by the effective request URI. An entity-tag is intended for use as a resource-local
          identifier for differentiating between representations of the same resource that vary over time or via content negotiation
          (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
@@ -1063 +1060 @@
       <div id="rfc.iref.h.6"></div>
       <h2 id="rfc.section.6.6"><a href="#rfc.section.6.6">6.6</a>&nbsp;<a id="header.last-modified" href="#header.last-modified">Last-Modified</a></h2>
-      <p id="rfc.section.6.6.p.1">The "Last-Modified" entity-header field indicates the date and time at which the origin server believes the representation
-         was last modified.
+      <p id="rfc.section.6.6.p.1">The "Last-Modified" header field indicates the date and time at which the origin server believes the representation was last
+         modified.
       </p>
       <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span>  <a href="#header.last-modified" class="smpl">Last-Modified</a>   = "Last-Modified" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.last-modified" class="smpl">Last-Modified-v</a>
@@ -1084 +1081 @@
       <p id="rfc.section.6.6.p.8">HTTP/1.1 servers <em class="bcp14">SHOULD</em> send Last-Modified whenever feasible.
       </p>
-      <p id="rfc.section.6.6.p.9">The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered
-         to be valid if the representation has not been modified since the Last-Modified value.
+      <p id="rfc.section.6.6.p.9">The Last-Modified header field value is often used as a cache validator. In simple terms, a cache entry is considered to be
+         valid if the representation has not been modified since the Last-Modified value.
       </p>
       <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
@@ -1450 +1447 @@
                   </li>
                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">2.1</a>, <a class="iref" href="#rfc.xref.Part3.2">2.1</a>, <a class="iref" href="#Part3"><b>10.1</b></a><ul class="ind">
-                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">2.1</a></li>
-                        <li class="indline1"><em>Section 5.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">2.1</a></li>
+                        <li class="indline1"><em>Section 5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">2.1</a></li>
+                        <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">2.1</a></li>
                      </ul>
                   </li>

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

@@ -676 +676 @@
          </li>
       </ul>
-      <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <em class="bcp14">SHOULD NOT</em> include other entity-headers. Otherwise, the response <em class="bcp14">MUST</em> include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.
+      <p id="rfc.section.3.1.p.3">If the 206 response is the result of an If-Range request, the response <em class="bcp14">SHOULD NOT</em> include other representation header fields. Otherwise, the response <em class="bcp14">MUST</em> include all of the representation header fields that would have been returned with a 200 (OK) response to the same request.
       </p>
       <p id="rfc.section.3.1.p.4">A cache <em class="bcp14">MUST NOT</em> combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see <a href="#combining.byte.ranges" title="Combining Ranges">Section&nbsp;4</a>.
@@ -690 +690 @@
          length of the selected resource.)
       </p>
-      <p id="rfc.section.3.2.p.2">When this status code is returned for a byte-range request, the response <em class="bcp14">SHOULD</em> include a Content-Range entity-header field specifying the current length of the selected resource (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section&nbsp;5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges content-type.
+      <p id="rfc.section.3.2.p.2">When this status code is returned for a byte-range request, the response <em class="bcp14">SHOULD</em> include a Content-Range header field specifying the current length of the representation (see <a href="#header.content-range" id="rfc.xref.header.content-range.3" title="Content-Range">Section&nbsp;5.2</a>). This response <em class="bcp14">MUST NOT</em> use the multipart/byteranges content-type.
       </p>
       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Ranges</a></h1>
@@ -710 +710 @@
       <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
       <p id="rfc.section.5.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to range requests and partial responses.</p>
-      <p id="rfc.section.5.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
-         receives the message.
-      </p>
       <div id="rfc.iref.a.1"></div>
       <div id="rfc.iref.h.1"></div>
@@ -732 +729 @@
       <div id="rfc.iref.h.2"></div>
       <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.content-range" href="#header.content-range">Content-Range</a></h2>
-      <p id="rfc.section.5.2.p.1">The "Content-Range" entity-header field is sent with a partial representation to specify where in the full representation
-         the partial body should be applied.
+      <p id="rfc.section.5.2.p.1">The "Content-Range" header field is sent with a partial representation to specify where in the full representation the payload
+         body should be applied.
       </p>
       <p id="rfc.section.5.2.p.2">Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
@@ -1351 +1348 @@
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>&gt;: "Clarify entity / representation / variant terminology"
-         </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "Clarify entity / representation / variant terminology"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "consider removing the 'changes from 2068' sections"

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

@@ -762 +762 @@
       </p>
       <ul>
-         <li>The presented Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and
+         <li>The presented effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and that of the stored response match, and
          </li>
          <li>the request method associated with the stored response allows it to be used for the presented request, and</li>
@@ -946 +946 @@
          <li>POST</li>
       </ul>
-      <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
-      </p>
-      <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
-      </p>
-      <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the Effective Request URI, or will
+      <p id="rfc.section.2.5.p.3">An invalidation based on a URI from a Location or Content-Location header <em class="bcp14">MUST NOT</em> be performed if the host part of that URI differs from the host part in the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). This helps prevent denial of service attacks.
+      </p>
+      <p id="rfc.section.2.5.p.4">A cache that passes through requests for methods it does not understand <em class="bcp14">SHOULD</em> invalidate the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
+      </p>
+      <p id="rfc.section.2.5.p.5">Here, "invalidate" means that the cache will either remove all stored responses related to the effective request URI, or will
          mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request.
       </p>
@@ -1012 +1012 @@
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
       <p id="rfc.section.3.p.1">This section defines the syntax and semantics of HTTP/1.1 header fields related to caching.</p>
-      <p id="rfc.section.3.p.2">For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who
-         receives the message.
-      </p>
       <div id="rfc.iref.a.2"></div>
       <div id="rfc.iref.h.2"></div>
@@ -1257 +1254 @@
       <div id="rfc.iref.h.4"></div>
       <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="header.expires" href="#header.expires">Expires</a></h2>
-      <p id="rfc.section.3.3.p.1">The "Expires" entity-header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the freshness model.
+      <p id="rfc.section.3.3.p.1">The "Expires" header field gives the date/time after which the response is considered stale. See <a href="#expiration.model" title="Freshness Model">Section&nbsp;2.3</a> for further discussion of the freshness model.
       </p>
       <p id="rfc.section.3.3.p.2">The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after
@@ -1899 +1896 @@
       <p id="rfc.section.C.12.p.1">Closed issues: </p>
       <ul>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>&gt;: "Clarify entity / representation / variant terminology"
+         </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/220">http://tools.ietf.org/wg/httpbis/trac/ticket/220</a>&gt;: "consider removing the 'changes from 2068' sections"
          </li>

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

@@ -613 +613 @@
       <div id="rfc.iref.s.1"></div>
       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="status.401" href="#status.401">401 Unauthorized</a></h2>
-      <p id="rfc.section.2.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;3.4</a>) containing a challenge applicable to the requested resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;3.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been
+      <p id="rfc.section.2.1.p.1">The request requires user authentication. The response <em class="bcp14">MUST</em> include a WWW-Authenticate header field (<a href="#header.www-authenticate" id="rfc.xref.header.www-authenticate.1" title="WWW-Authenticate">Section&nbsp;3.4</a>) containing a challenge applicable to the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Authorization header field (<a href="#header.authorization" id="rfc.xref.header.authorization.1" title="Authorization">Section&nbsp;3.1</a>). If the request already included Authorization credentials, then the 401 response indicates that authorization has been
          refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has
          already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the representation that was given in the response, since that representation might include relevant diagnostic
@@ -622 +622 @@
       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2>
       <p id="rfc.section.2.2.p.1">This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The
-         proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;3.2</a>) containing a challenge applicable to the proxy for the requested resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;3.3</a>). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.6"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.
+         proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section&nbsp;3.2</a>) containing a challenge applicable to the proxy for the target resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section&nbsp;3.3</a>). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.6"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.
       </p>
       <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
@@ -655 +655 @@
       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="header.proxy-authenticate" href="#header.proxy-authenticate">Proxy-Authenticate</a></h2>
       <p id="rfc.section.3.2.p.1">The "Proxy-Authenticate" response-header field consists of a challenge that indicates the authentication scheme and parameters
-         applicable to the proxy for this Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
+         applicable to the proxy for this effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included as part of a 407 (Proxy Authentication Required) response.
       </p>
       <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.proxy-authenticate" class="smpl">Proxy-Authenticate</a>   = "Proxy-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a>
@@ -683 +683 @@
       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.www-authenticate" href="#header.www-authenticate">WWW-Authenticate</a></h2>
       <p id="rfc.section.3.4.p.1">The "WWW-Authenticate" response-header field consists of at least one challenge that indicates the authentication scheme(s)
-         and parameters applicable to the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.
+         and parameters applicable to the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It <em class="bcp14">MUST</em> be included in 401 (Unauthorized) response messages.
       </p>
       <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.www-authenticate" class="smpl">WWW-Authenticate</a>   = "WWW-Authenticate" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.www-authenticate" class="smpl">WWW-Authenticate-v</a>