Context Navigation

← Previous Changeset
Next Changeset →

Changeset 97

Timestamp:

23/12/07 13:22:38 (15 years ago)

Author:

julian.reschke@…

Message:

Cleanup references after switch to symbolic references (removing duplicated RFC numbers), clean up some of the references XML code.

Location:

draft-ietf-httpbis/latest

Files:

: 14 edited

p1-messaging.html (modified) (24 diffs)
p1-messaging.xml (modified) (30 diffs)
p2-semantics.html (modified) (7 diffs)
p2-semantics.xml (modified) (5 diffs)
p3-payload.html (modified) (6 diffs)
p3-payload.xml (modified) (18 diffs)
p4-conditional.html (modified) (3 diffs)
p4-conditional.xml (modified) (3 diffs)
p5-range.html (modified) (1 diff)
p5-range.xml (modified) (2 diffs)
p6-cache.html (modified) (5 diffs)
p6-cache.xml (modified) (6 diffs)
p7-auth.html (modified) (1 diff)
p7-auth.xml (modified) (1 diff)

Legend:

: Unmodified
: Added
: Removed

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

-                      r96
+                      r97
       <p id="rfc.section.1.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information
          systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, referred
          to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by RFC 1945 <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the
+         to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the
          data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration
          the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation
 …
       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="notation.abnf" href="#notation.abnf">Augmented BNF</a></h2>
       <p id="rfc.section.2.1.p.1">All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar
          to that used by RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.2"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes
+         to that used by <a href="#RFC822" id="rfc.xref.RFC822.2"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes
          the following constructs:
       </p>
 …
       <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span>    LWS            = [CRLF] 1*( SP | HT )
 </pre><p id="rfc.section.2.2.p.7">The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message
          parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859" id="rfc.xref.ISO-8859.1"><cite title="Information technology - 8-bit single byte coded graphic - character sets">[ISO-8859]</cite></a> only when encoded according to the rules of RFC 2047 <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.
+         parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859" id="rfc.xref.ISO-8859.1"><cite title="Information technology - 8-bit single byte coded graphic - character sets">[ISO-8859]</cite></a> only when encoded according to the rules of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.
       </p>
       <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.15"></span>    TEXT           = &lt;any OCTET except CTLs,
 …
          when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may
          add to the message semantics and imply additional capabilities of the sender. The &lt;major&gt; number is incremented when the format
          of a message within the protocol is changed. See RFC 2145 <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> for a fuller explanation.
+         of a message within the protocol is changed. See <a href="#RFC2145" id="rfc.xref.RFC2145.1"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> for a fuller explanation.
       </p>
       <p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p>
 …
       <p id="rfc.section.3.1.p.5">An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" <em class="bcp14">MUST</em> be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this
          specification <em class="bcp14">SHOULD</em> use an HTTP-Version of "HTTP/1.1" in their messages, and <em class="bcp14">MUST</em> do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values,
          see RFC 2145 <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>.
+         see <a href="#RFC2145" id="rfc.xref.RFC2145.2"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>.
       </p>
       <p id="rfc.section.3.1.p.6">The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.</p>
 …
          the proxy/gateway <em class="bcp14">MUST</em> either downgrade the request version, or respond with an error, or switch to tunnel behavior.
       </p>
       <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request.
+      <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request.
       </p>
       <p id="rfc.section.3.1.p.9"> </p>
 …
       <p id="rfc.section.3.2.1.p.1">URIs in HTTP can be represented in absolute form or relative to some known base URI <a href="#RFC1808" id="rfc.xref.RFC1808.1"><cite title="Relative Uniform Resource Locators">[RFC1808]</cite></a>, depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs always begin with
          a scheme name followed by a colon. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers
          (URI): Generic Syntax and Semantics," RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> (which replaces RFCs 1738 <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and RFC 1808 <a href="#RFC1808" id="rfc.xref.RFC1808.2"><cite title="Relative Uniform Resource Locators">[RFC1808]</cite></a>). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path",
+         (URI): Generic Syntax and Semantics," <a href="#RFC2396" id="rfc.xref.RFC2396.1"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a> (which replaces <a href="#RFC1738" id="rfc.xref.RFC1738.3"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and <a href="#RFC1808" id="rfc.xref.RFC1808.2"><cite title="Relative Uniform Resource Locators">[RFC1808]</cite></a>). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path",
          "rel_path", and "authority" from that specification.
       </p>
 …
       <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.25"></span>http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
 </pre><p id="rfc.section.3.2.2.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server
          listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see RFC 1900 <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the abs_path is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
+         listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the abs_path is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
       </p>
       <h3 id="rfc.section.3.2.3"><a href="#rfc.section.3.2.3">3.2.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3>
 …
          <li>An empty abs_path is equivalent to an abs_path of "/".</li>
       </ul>
       <p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" set (see RFC 2396 <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>) are equivalent to their ""%" HEX HEX" encoding.
+      <p id="rfc.section.3.2.3.p.2">Characters other than those in the "reserved" set (see <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[RFC2396]</cite></a>) are equivalent to their ""%" HEX HEX" encoding.
       </p>
       <p id="rfc.section.3.2.3.p.3">For example, the following three URIs are equivalent:</p>
 …
    Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
 </pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>). The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers
+</pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>). The other formats are described here only for compatibility with obsolete implementations. HTTP/1.1 clients and servers
          that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;B</a> for further information.
       </p>
 …
       <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p>
       <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.51"></span>    HTTP-message   = Request | Response     ; HTTP/1.1 messages
 </pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section&nbsp;5</a>) and Response (<a href="#response" title="Response">Section&nbsp;6</a>) messages use the generic message format of RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.4"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header
+</pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section&nbsp;5</a>) and Response (<a href="#response" title="Response">Section&nbsp;6</a>) messages use the generic message format of <a href="#RFC822" id="rfc.xref.RFC822.4"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header
          fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header
          fields, and possibly a message-body.
 …
       </p>
       <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="message.headers" href="#message.headers">Message Headers</a></h2>
       <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</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>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc822#section-3.1" id="rfc.xref.RFC822.5">Section 3.1</a> of RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.6"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The
+      <p id="rfc.section.4.2.p.1">HTTP header fields, which include general-header (<a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>), request-header (<a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), response-header (<a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), and entity-header (<a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</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>) fields, follow the same generic format as that given in <a href="http://tools.ietf.org/html/rfc822#section-3.1">Section 3.1</a> of <a href="#RFC822" id="rfc.xref.RFC822.5"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The
          field value <em class="bcp14">MAY</em> be preceded by any amount of LWS, though a single SP is preferred. Header fields can be extended over multiple lines by preceding
          each extra line with at least one SP or HT. Applications ought to follow "common form", where one is known or indicated, when
 …
          servers and causing congestion on the Internet. The use of inline images and other associated data often require a client
          to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results
          from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a>  <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 (RFC 2068) implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.
+         from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a>  <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 (<cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2068.2">RFC 2068</cite>) implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>.
       </p>
       <p id="rfc.section.7.1.1.p.2">Persistent HTTP connections have a number of advantages: </p>
 …
          to. Each persistent connection applies to only one transport link.
       </p>
       <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).
+      <p id="rfc.section.7.1.3.p.3">A proxy server <em class="bcp14">MUST NOT</em> establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).
       </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>
 …
          <li>An origin server <em class="bcp14">SHOULD NOT</em> send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue"
             expectation, and <em class="bcp14">MUST NOT</em> send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this
             rule: for compatibility with RFC 2068, a server <em class="bcp14">MAY</em> send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header
+            rule: for compatibility with <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, a server <em class="bcp14">MAY</em> send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header
             field with the "100-continue" expectation. This exception, the purpose of which is to minimize any client processing delays
             associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with
 …
       <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h2>
       <p id="rfc.section.8.3.p.1">The Date general-header field represents the date and time at which the message was originated, having the same semantics
          as orig-date in RFC 822. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section&nbsp;3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
+         as orig-date in <a href="#RFC822" id="rfc.xref.RFC822.6"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section&nbsp;3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
       </p>
       <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span>    Date  = "Date" ":" HTTP-date
 …
          requested by the proxy. All Internet-based HTTP/1.1 servers <em class="bcp14">MUST</em> respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.
       </p>
       <p id="rfc.section.8.4.p.6">See sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.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">D.1.1</a> for other requirements relating to Host.
+      <p id="rfc.section.8.4.p.6">See Sections <a href="#the.resource.identified.by.a.request" title="The Resource Identified by a Request">5.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">D.1.1</a> for other requirements relating to Host.
       </p>
       <div id="rfc.iref.t.2"></div>
 …
       <h2 id="rfc.section.8.9"><a href="#rfc.section.8.9">8.9</a>&nbsp;<a id="header.via" href="#header.via">Via</a></h2>
       <p id="rfc.section.8.9.p.1">The Via general-header field <em class="bcp14">MUST</em> be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server
          on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.7"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
+         on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of <a href="#RFC822" id="rfc.xref.RFC822.7"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities
          of all senders along the request/response chain.
       </p>
 …
       <p id="rfc.section.10.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>
       <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a>&nbsp;<a id="ack" href="#ack">Acknowledgments</a></h1>
       <p id="rfc.section.11.p.1">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.8"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and
+      <p id="rfc.section.11.p.1">This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for <a href="#RFC822" id="rfc.xref.RFC822.8"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and
          Internet mail message formats.
       </p>
 …
       <p id="rfc.section.D.p.3">For most implementations of HTTP/1.0, each connection is established by the client prior to the request and closed by the
          server after sending the response. Some implementations implement the Keep-Alive version of persistent connections described
          in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1" id="rfc.xref.RFC2068.3">Section 19.7.1</a> of RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
+         in <a href="http://tools.ietf.org/html/rfc2068#section-19.7.1">Section 19.7.1</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
       </p>
       <h2 id="rfc.section.D.1"><a href="#rfc.section.D.1">D.1</a>&nbsp;<a id="changes.from.1.0" href="#changes.from.1.0">Changes from HTTP/1.0</a></h2>
 …
          a new keyword (Connection: close) for declaring non-persistence. See <a href="#header.connection" id="rfc.xref.header.connection.6" title="Connection">Section&nbsp;8.1</a>.
       </p>
+      <p id="rfc.section.D.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in RFC
+. <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>
+      <p id="rfc.section.D.2.p.3">The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in <a href="#RFC2068" id="rfc.xref.RFC2068.6"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
       </p>
       <h2 id="rfc.section.D.3"><a href="#rfc.section.D.3">D.3</a>&nbsp;<a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h2>
       <p id="rfc.section.D.3.p.1">This specification has been carefully audited to correct and disambiguate key word usage; RFC 2068 had many problems in respect
          to the conventions laid out in RFC 2119 <a href="#RFC2119" id="rfc.xref.RFC2119.2"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
+         to the conventions laid out in <a href="#RFC2119" id="rfc.xref.RFC2119.2"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
       </p>
       <p id="rfc.section.D.3.p.2">Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow
 …
          computed.
       </p>
       <p id="rfc.section.D.3.p.3">The use and interpretation of HTTP version numbers has been clarified by RFC 2145. Require proxies to upgrade requests to
          highest protocol version they support to deal with problems discovered in HTTP/1.0 implementations (<a href="#http.version" title="HTTP Version">Section&nbsp;3.1</a>)
+      <p id="rfc.section.D.3.p.3">The use and interpretation of HTTP version numbers has been clarified by <a href="#RFC2145" id="rfc.xref.RFC2145.3"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a>. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0
+         implementations (<a href="#http.version" title="HTTP Version">Section&nbsp;3.1</a>)
       </p>
       <p id="rfc.section.D.3.p.4">Proxies should be able to add Content-Length when appropriate.</p>
 …
                   <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2045.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">3.4</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12</b></a></li>
                   <li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2047.1">2.2</a>, <a class="iref" href="#RFC2047"><b>12</b></a></li>
                   <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.3</a>, <a class="iref" href="#RFC2068"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2068.3">D</a>, <a class="iref" href="#rfc.xref.RFC2068.4">D</a>, <a class="iref" href="#rfc.xref.RFC2068.5">D.2</a><ul class="ind">
                         <li class="indline1"><em>Section 19.7.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.3">D</a></li>
+                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">7.1.1</a>, <a class="iref" href="#rfc.xref.RFC2068.3">7.1.3</a>, <a class="iref" href="#rfc.xref.RFC2068.4">7.2.3</a>, <a class="iref" href="#RFC2068"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2068.5">D</a>, <a class="iref" href="#rfc.xref.RFC2068.6">D.2</a><ul class="ind">
+                        <li class="indline1"><em>Section 19.7.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.5">D</a></li>
                      </ul>
                   </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>12</b></a>, <a class="iref" href="#rfc.xref.RFC2119.2">D.3</a></li>
                   <li class="indline1"><em>RFC2145</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2145.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2145.2">3.1</a>, <a class="iref" href="#RFC2145"><b>12</b></a></li>
+                  <li class="indline1"><em>RFC2145</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2145.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2145.2">3.1</a>, <a class="iref" href="#RFC2145"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC2145.3">D.3</a></li>
                   <li class="indline1"><em>RFC2324</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2324.1">1.1</a>, <a class="iref" href="#RFC2324"><b>12</b></a></li>
                   <li class="indline1"><em>RFC2396</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2396.1">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC2396.2">3.2.3</a>, <a class="iref" href="#rfc.xref.RFC2396.3">5.1.2</a>, <a class="iref" href="#RFC2396"><b>12</b></a></li>
 …
                   <li class="indline1"><em>RFC4288</em>&nbsp;&nbsp;<a class="iref" href="#RFC4288"><b>12</b></a>, <a class="iref" href="#rfc.xref.RFC4288.1">A</a></li>
                   <li class="indline1"><em>RFC821</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC821.1">1.1</a>, <a class="iref" href="#RFC821"><b>12</b></a></li>
                   <li class="indline1"><em>RFC822</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC822.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC822.3">3.3.1</a>, <a class="iref" href="#rfc.xref.RFC822.4">4.1</a>, <a class="iref" href="#rfc.xref.RFC822.5">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.6">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.7">8.9</a>, <a class="iref" href="#rfc.xref.RFC822.8">11</a>, <a class="iref" href="#RFC822"><b>12</b></a><ul class="ind">
+                  <li class="indline1"><em>RFC822</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC822.2">2.1</a>, <a class="iref" href="#rfc.xref.RFC822.3">3.3.1</a>, <a class="iref" href="#rfc.xref.RFC822.4">4.1</a>, <a class="iref" href="#rfc.xref.RFC822.5">4.2</a>, <a class="iref" href="#rfc.xref.RFC822.6">8.3</a>, <a class="iref" href="#rfc.xref.RFC822.7">8.9</a>, <a class="iref" href="#rfc.xref.RFC822.8">11</a>, <a class="iref" href="#RFC822"><b>12</b></a><ul class="ind">
                         <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC822.5">4.2</a></li>
                      </ul>

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

-                      r96
+                      r97
    information initiative since 1990. The first version of HTTP,
    referred to as HTTP/0.9, was a simple protocol for raw data transfer
    across the Internet. HTTP/1.0, as defined by RFC 1945 <xref target="RFC1945"/>, improved
+   across the Internet. HTTP/1.0, as defined by <xref target="RFC1945"/>, improved
    the protocol by allowing messages to be in the format of MIME-like
    messages, containing metainformation about the data transferred and
 …
    All of the mechanisms specified in this document are described in
    both prose and an augmented Backus-Naur Form (BNF) similar to that
    used by RFC 822 <xref target="RFC822"/>. Implementors will need to be familiar with the
+   used by <xref target="RFC822"/>. Implementors will need to be familiar with the
    notation in order to understand this specification. The augmented BNF
    includes the following constructs:
 …
    that are not intended to be interpreted by the message parser. Words
    of *TEXT &MAY; contain characters from character sets other than ISO-8859-1
    <xref target="ISO-8859"/> only when encoded according to the rules of RFC 2047
+   <xref target="ISO-8859"/> only when encoded according to the rules of
    <xref target="RFC2047"/>.
 </t>
 …
    additional capabilities of the sender. The &lt;major&gt; number is
    incremented when the format of a message within the protocol is
    changed. See RFC 2145 <xref target="RFC2145"/> for a fuller explanation.
+   changed. See <xref target="RFC2145"/> for a fuller explanation.
 </t>
 <t>
 …
    "HTTP/1.1" in their messages, and &MUST; do so for any message that is
    not compatible with HTTP/1.0. For more details on when to send
    specific HTTP-Version values, see RFC 2145 <xref target="RFC2145"/>.
+   specific HTTP-Version values, see <xref target="RFC2145"/>.
 </t>
 <t>
 …
 <t>
    Due to interoperability problems with HTTP/1.0 proxies discovered
    since the publication of RFC 2068 <xref target="RFC2068"/>, caching proxies &MUST;, gateways
+   since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways
    &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version
    they support. The proxy/gateway's response to that request &MUST; be in
 …
    with a scheme name followed by a colon. For definitive information on
    URL syntax and semantics, see "Uniform Resource Identifiers (URI):
    Generic Syntax and Semantics," RFC 2396 <xref target="RFC2396"/> (which replaces RFCs
 <xref target="RFC1738"/> and RFC 1808 <xref target="RFC1808"/>). This specification adopts the
+   Generic Syntax and Semantics," <xref target="RFC2396"/> (which replaces <xref target="RFC1738"/>
+   and <xref target="RFC1808"/>). This specification adopts the
    definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
    "host","abs_path", "rel_path", and "authority" from that
 …
    for TCP connections on that port of that host, and the Request-URI
    for the resource is abs_path (<xref target="request-uri"/>). The use of IP addresses
    in URLs &SHOULD; be avoided whenever possible (see RFC 1900 <xref target="RFC1900"/>). If
+   in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If
    the abs_path is not present in the URL, it &MUST; be given as "/" when
    used as a Request-URI for a resource (<xref target="request-uri"/>). If a proxy
 …
 <t>
    Characters other than those in the "reserved" set (see
    RFC 2396 <xref target="RFC2396"/>) are equivalent to their ""%" HEX HEX" encoding.
+   <xref target="RFC2396"/>) are equivalent to their ""%" HEX HEX" encoding.
 </t>
 <t>
 …
 <t>
    The first format is preferred as an Internet standard and represents
    a fixed-length subset of that defined by RFC 1123 <xref target="RFC1123"/> (an update to
    RFC 822 <xref target="RFC822"/>). The other formats are described here only for
+   a fixed-length subset of that defined by <xref target="RFC1123"/> (an update to
+   <xref target="RFC822"/>). The other formats are described here only for
    compatibility with obsolete implementations.
    HTTP/1.1 clients and servers that parse the date value &MUST; accept
 …
 <t>
    Request (<xref target="request"/>) and Response (<xref target="response"/>) messages use the generic
    message format of RFC 822 <xref target="RFC822"/> for transferring entities (the payload
+   message format of <xref target="RFC822"/> for transferring entities (the payload
    of the message). Both types of message consist of a start-line, zero
    or more header fields (also known as "headers"), an empty line (i.e.,
 …
    request-header (&request-header-fields;), response-header (&response-header-fields;), and
    entity-header (&entity-header-fields;) fields, follow the same generic format as
    that given in <xref target="RFC822" x:fmt="sec" x:sec="3.1"/> of RFC 822 <xref target="RFC822"/>. Each header field consists
+   that given in <xref target="RFC822" x:fmt="of" x:sec="3.1"/>. Each header field consists
    of a name followed by a colon (":") and the field value. Field names
    are case-insensitive. The field value &MAY; be preceded by any amount
 …
    these performance problems and results from a prototype
    implementation are available <xref target="Pad1995"/> <xref target="Spe"/>. Implementation experience and
    measurements of actual HTTP/1.1 (RFC 2068) implementations show good
+   measurements of actual HTTP/1.1 (<xref target="RFC2068" x:fmt="none">RFC 2068</xref>) implementations show good
    results <xref target="Nie1997"/>. Alternatives have also been explored, for example,
    T/TCP <xref target="Tou1998"/>.
 …
 <t>
    A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection
    with an HTTP/1.0 client (but see RFC 2068 <xref target="RFC2068"/> for information and
+   with an HTTP/1.0 client (but see <xref target="RFC2068"/> for information and
    discussion of the problems with the Keep-Alive header implemented by
    many HTTP/1.0 clients).
 …
 (Continue) response if such a request comes from an HTTP/1.0
         (or earlier) client. There is an exception to this rule: for
         compatibility with RFC 2068, a server &MAY; send a 100 (Continue)
+        compatibility with <xref target="RFC2068"/>, a server &MAY; send a 100 (Continue)
         status in response to an HTTP/1.1 PUT or POST request that does
         not include an Expect request-header field with the "100-continue"
 …
    The Date general-header field represents the date and time at which
    the message was originated, having the same semantics as orig-date in
    RFC 822. The field value is an HTTP-date, as described in <xref target="full.date"/>;
+   <xref target="RFC822"/>. The field value is an HTTP-date, as described in <xref target="full.date"/>;
    it &MUST; be sent in rfc1123-date format.
 </t>
 …
 </t>
 <t>
    See sections <xref target="the.resource.identified.by.a.request" format="counter"/>
+   See Sections <xref target="the.resource.identified.by.a.request" format="counter"/>
    and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/>
    for other requirements relating to Host.
 …
    agent and the server on requests, and between the origin server and
    the client on responses. It is analogous to the "Received" field of
    RFC 822 <xref target="RFC822"/> and is intended to be used for tracking message forwards,
+   <xref target="RFC822"/> and is intended to be used for tracking message forwards,
    avoiding request loops, and identifying the protocol capabilities of
    all senders along the request/response chain.
 …
 <t>
    This specification makes heavy use of the augmented BNF and generic
    constructs defined by David H. Crocker for RFC 822 <xref target="RFC822"/>. Similarly, it
+   constructs defined by David H. Crocker for <xref target="RFC822"/>. Similarly, it
    reuses many of the definitions provided by Nathaniel Borenstein and
    Ned Freed for MIME <xref target="RFC2045"/>. We hope that their inclusion in this
 …
 <reference anchor="RFC1738">
+<front>
+<title>Uniform Resource Locators (URL)</title>
+<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+<organization>CERN, World-Wide Web project</organization>
+<address>
+<postal>
+<street>1211 Geneva 23</street>
+<city/>
+<region/>
+<code/>
+<country>CH</country></postal>
+<phone>+41 22 7673755</phone>
+<facsimile>+41 22 7677155</facsimile>
+<email>timbl@info.cern.ch</email></address></author>
+<author initials="L." surname="Masinter" fullname="Larry Masinter">
+<organization>Xerox PARC</organization>
+<address>
+<postal>
+<street>3333 Coyote Hill Road</street>
+<city>Palo Alto</city>
+<region>CA</region>
+<code>94034</code>
+<country>US</country></postal>
+<phone>+1 415 812 4365</phone>
+<facsimile>+1 415 812 4333</facsimile>
+<email>masinter@parc.xerox.com</email></address></author>
+<author initials="M." surname="McCahill" fullname="Mark McCahill">
+<organization>University of Minnesota, Computer and Information Services</organization>
+<address>
+<postal>
+<street>100 Union Street SE, Shepherd Labs</street>
+<street>Room 152</street>
+<city>Minneapolis</city>
+<region>MN</region>
+<code>55455</code>
+<country>US</country></postal>
+<phone>+1 612 625 1300</phone>
+<email>mpm@boombox.micro.umn.edu</email></address></author>
+<date month="December" year="1994"/>
+</front>
+<seriesInfo name="RFC" value="1738"/>
+  <front>
+    <title>Uniform Resource Locators (URL)</title>
+    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+      <organization>CERN, World-Wide Web project</organization>
+      <address><email>timbl@info.cern.ch</email></address>
+    </author>
+    <author initials="L." surname="Masinter" fullname="Larry Masinter">
+      <organization>Xerox PARC</organization>
+      <address><email>masinter@parc.xerox.com</email></address>
+    </author>
+    <author initials="M." surname="McCahill" fullname="Mark McCahill">
+      <organization>University of Minnesota, Computer and Information Services</organization>
+      <address><email>mpm@boombox.micro.umn.edu</email></address>
+    </author>
+    <date month="December" year="1994"/>
+  </front>
+  <seriesInfo name="RFC" value="1738"/>
 </reference>
 <reference anchor="RFC1945">
+<front>
+<title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title>
+<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+<organization>MIT, Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<phone/>
+<facsimile>+1 617 258 8682</facsimile>
+<email>timbl@w3.org</email></address></author>
+<author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+<organization>University of California, Irvine, Department of Information and Computer Science</organization>
+<address>
+<postal>
+<street/>
+<city>Irvine</city>
+<region>CA</region>
+<code>92717-3425</code>
+<country>US</country></postal>
+<phone/>
+<facsimile>+1 714 824 4056</facsimile>
+<email>fielding@ics.uci.edu</email></address></author>
+<author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+<organization>W3 Consortium, MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<phone/>
+<facsimile>+1 617 258 8682</facsimile>
+<email>frystyk@w3.org</email></address></author>
+<date month="May" year="1996"/>
+</front>
+<seriesInfo name="RFC" value="1945"/>
+  <front>
+    <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title>
+    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+      <organization>MIT, Laboratory for Computer Science</organization>
+      <address><email>timbl@w3.org</email></address>
+    </author>
+    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
+      <address><email>fielding@ics.uci.edu</email></address>
+    </author>
+    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+      <organization>W3 Consortium, MIT Laboratory for Computer Science</organization>
+      <address><email>frystyk@w3.org</email></address>
+    </author>
+    <date month="May" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="1945"/>
 </reference>
 <reference anchor="RFC2045">
+<front>
+<title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
+<author initials="N." surname="Freed" fullname="Ned Freed">
+<organization>Innosoft International, Inc.</organization>
+<address>
+<postal>
+<street>1050 East Garvey Avenue South</street>
+<city>West Covina</city>
+<region>CA</region>
+<code>91790</code>
+<country>US</country></postal>
+<phone>+1 818 919 3600</phone>
+<facsimile>+1 818 919 3614</facsimile>
+<email>ned@innosoft.com</email></address></author>
+<author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+<organization>First Virtual Holdings</organization>
+<address>
+<postal>
+<street>25 Washington Avenue</street>
+<city>Morristown</city>
+<region>NJ</region>
+<code>07960</code>
+<country>US</country></postal>
+<phone>+1 201 540 8967</phone>
+<facsimile>+1 201 993 3032</facsimile>
+<email>nsb@nsb.fv.com</email></address></author>
+<date month="November" year="1996"/>
+</front>
+<seriesInfo name="RFC" value="2045"/>
+  <front>
+    <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
+    <author initials="N." surname="Freed" fullname="Ned Freed">
+      <organization>Innosoft International, Inc.</organization>
+      <address><email>ned@innosoft.com</email></address>
+    </author>
+    <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+      <organization>First Virtual Holdings</organization>
+      <address><email>nsb@nsb.fv.com</email></address>
+    </author>
+    <date month="November" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="2045"/>
 </reference>
 <reference anchor="RFC1123">
+<front>
+<title>Requirements for Internet Hosts - Application and Support</title>
+<author initials="R." surname="Braden" fullname="Robert Braden">
+<organization>University of Southern California (USC), Information Sciences Institute</organization>
+<address>
+<postal>
+<street>4676 Admiralty Way</street>
+<city>Marina del Rey</city>
+<region>CA</region>
+<code>90292-6695</code>
+<country>US</country></postal>
+<phone>+1 213 822 1511</phone>
+<email>Braden@ISI.EDU</email></address></author>
+<date month="October" year="1989"/></front>
+<seriesInfo name="STD" value="3"/>
+<seriesInfo name="RFC" value="1123"/>
+  <front>
+    <title>Requirements for Internet Hosts - Application and Support</title>
+    <author initials="R." surname="Braden" fullname="Robert Braden">
+      <organization>University of Southern California (USC), Information Sciences Institute</organization>
+      <address><email>Braden@ISI.EDU</email></address>
+    </author>
+    <date month="October" year="1989"/>
+  </front>
+  <seriesInfo name="STD" value="3"/>
+  <seriesInfo name="RFC" value="1123"/>
 </reference>
 <reference anchor="RFC822">
+<front>
+<title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title>
+<author initials="D.H." surname="Crocker" fullname="David H. Crocker">
+<organization>University of Delaware, Dept. of Electrical Engineering</organization>
+<address>
+<postal>
+<street/>
+<city>Newark</city>
+<region>DE</region>
+<code>19711</code>
+<country>US</country></postal>
+<email>DCrocker@UDel-Relay</email></address></author>
+<date month="August" day="13" year="1982"/></front>
+<seriesInfo name="STD" value="11"/>
+<seriesInfo name="RFC" value="822"/>
+  <front>
+    <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title>
+    <author initials="D.H." surname="Crocker" fullname="David H. Crocker">
+      <organization>University of Delaware, Dept. of Electrical Engineering</organization>
+      <address><email>DCrocker@UDel-Relay</email></address>
+    </author>
+    <date month="August" day="13" year="1982"/>
+  </front>
+  <seriesInfo name="STD" value="11"/>
+  <seriesInfo name="RFC" value="822"/>
 </reference>
 …
 <reference anchor="RFC1808">
+<front>
+<title>Relative Uniform Resource Locators</title>
+<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
+<organization>University of California Irvine, Department of Information and Computer Science</organization>
+<address>
+<postal>
+<street/>
+<city>Irvine</city>
+<region>CA</region>
+<code>92717-3425</code>
+<country>US</country></postal>
+<phone>+1 714 824 4049</phone>
+<facsimile>+1 714 824 4056</facsimile>
+<email>fielding@ics.uci.edu</email></address></author>
+<date month="June" year="1995"/>
+</front>
+<seriesInfo name="RFC" value="1808"/>
+  <front>
+    <title>Relative Uniform Resource Locators</title>
+    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
+      <organization>University of California Irvine, Department of Information and Computer Science</organization>
+      <address><email>fielding@ics.uci.edu</email></address>
+    </author>
+    <date month="June" year="1995"/>
+  </front>
+  <seriesInfo name="RFC" value="1808"/>
 </reference>
 …
 <reference anchor="RFC2047">
+<front>
+<title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
+<author initials="K." surname="Moore" fullname="Keith Moore">
+<organization>University of Tennessee</organization>
+<address>
+<postal>
+<street>107 Ayres Hall</street>
+<street>Knoxville TN 37996-1301</street></postal>
+<email>moore@cs.utk.edu</email></address></author>
+<date month="November" year="1996"/>
+<area>Applications</area>
+<keyword>Amercian Standard Code for Information Interchange</keyword>
+<keyword>mail</keyword>
+<keyword>multipurpose internet mail extensions</keyword>
+</front>
+<seriesInfo name="RFC" value="2047"/>
+  <front>
+    <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
+    <author initials="K." surname="Moore" fullname="Keith Moore">
+      <organization>University of Tennessee</organization>
+      <address><email>moore@cs.utk.edu</email></address>
+    </author>
+    <date month="November" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="2047"/>
 </reference>
 …
 <reference anchor="RFC1900">
+<front>
+<title>Renumbering Needs Work</title>
+<author initials="B." surname="Carpenter" fullname="Brian E. Carpenter">
+<organization>CERN, Computing and Networks Division</organization>
+<address>
+<postal>
+<street>1211 Geneva 23</street>
+<country>CH</country></postal>
+<phone>+41 22 7674967</phone>
+<facsimile>+41 22 7677155</facsimile>
+<email>brian@dxcoms.cern.ch</email></address></author>
+<author initials="Y." surname="Rekhter" fullname="Yakov Rekhter">
+<organization>cisco Systems</organization>
+<address>
+<postal>
+<street>170 West Tasman Drive</street>
+<city>San Jose</city>
+<region>CA</region>
+<code>95134</code>
+<country>US</country></postal>
+<phone>+1 914 528 0090</phone>
+<email>yakov@cisco.com</email></address></author>
+<date month="February" year="1996"/>
+</front>
+<seriesInfo name="RFC" value="1900"/>
+  <front>
+    <title>Renumbering Needs Work</title>
+    <author initials="B." surname="Carpenter" fullname="Brian E. Carpenter">
+      <organization>CERN, Computing and Networks Division</organization>
+      <address><email>brian@dxcoms.cern.ch</email></address>
+    </author>
+    <author initials="Y." surname="Rekhter" fullname="Yakov Rekhter">
+      <organization>cisco Systems</organization>
+      <address><email>yakov@cisco.com</email></address>
+    </author>
+    <date month="February" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="1900"/>
 </reference>
 …
 <reference anchor="RFC2068">
+<front>
+<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
+<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
+<organization>University of California, Irvine, Department of Information and Computer Science</organization>
+<address>
+<postal>
+<street/>
+<city>Irvine</city>
+<region>CA</region>
+<code>92717-3425</code>
+<country>US</country></postal>
+<facsimile>+1 714 824 4056</facsimile>
+<email>fielding@ics.uci.edu</email></address></author>
+<author initials="J." surname="Gettys" fullname="Jim Gettys">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>jg@w3.org</email></address></author>
+<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+<organization>Digital Equipment Corporation, Western Research Laboratory</organization>
+<address>
+<postal>
+<street>250 University Avenue</street>
+<city>Palo Alto</city>
+<region>CA</region>
+<code>94301</code>
+<country>US</country></postal>
+<email>mogul@wrl.dec.com</email></address></author>
+<author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>frystyk@w3.org</email></address></author>
+<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>timbl@w3.org</email></address></author>
+<date month="January" year="1997"/>
+<abstract>
+<t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t>
+<t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".</t></abstract></front>
+<seriesInfo name="RFC" value="2068"/>
+  <front>
+    <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
+    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
+      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
+      <address><email>fielding@ics.uci.edu</email></address>
+    </author>
+    <author initials="J." surname="Gettys" fullname="Jim Gettys">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>jg@w3.org</email></address>
+    </author>
+    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+      <organization>Digital Equipment Corporation, Western Research Laboratory</organization>
+      <address><email>mogul@wrl.dec.com</email></address>
+    </author>
+    <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>frystyk@w3.org</email></address>
+    </author>
+    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>timbl@w3.org</email></address>
+    </author>
+    <date month="January" year="1997"/>
+  </front>
+  <seriesInfo name="RFC" value="2068"/>
 </reference>
 …
 <reference anchor="RFC2145">
+<front>
+<title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title>
+<author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
+<organization>Western Research Laboratory</organization>
+<address>
+<postal>
+<street>Digital Equipment Corporation</street>
+<street>250 University Avenue</street>
+<street>Palo Alto</street>
+<street>California</street>
+<street>94305</street>
+<country>USA</country></postal>
+<email>mogul@wrl.dec.com</email></address></author>
+<author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+<organization>Department of Information and Computer Science</organization>
+<address>
+<postal>
+<street>University of California</street>
+<street>Irvine</street>
+<street>CA 92717-3425</street>
+<country>USA</country></postal>
+<facsimile>+1 (714) 824-4056</facsimile>
+<email>fielding@ics.uci.edu</email></address></author>
+<author initials="J." surname="Gettys" fullname="Jim Gettys">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<street>Cambridge</street>
+<street>MA 02139</street>
+<country>USA</country></postal>
+<facsimile>+1 (617) 258 8682</facsimile>
+<email>jg@w3.org</email></address></author>
+<author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+<organization>W3 Consortium</organization>
+<address>
+<postal>
+<street>MIT Laboratory for Computer Science</street>
+<street>545 Technology Square</street>
+<street>Cambridge</street>
+<street>MA 02139</street>
+<country>USA</country></postal>
+<facsimile>+1 (617) 258 8682</facsimile>
+<email>frystyk@w3.org</email></address></author>
+<date month="May" year="1997"/>
+<area>Applications</area>
+<keyword>HTTP</keyword>
+<keyword>hypertext transfer protocol</keyword>
+<abstract>
+<t>
+   HTTP request and response messages include an HTTP protocol version
+   number.  Some confusion exists concerning the proper use and
+   interpretation of HTTP version numbers, and concerning
+   interoperability of HTTP implementations of different protocol
+   versions.  This document is an attempt to clarify the situation.  It
+   is not a modification of the intended meaning of the existing
+   HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention
+   of the authors of those documents, and can be considered definitive
+   when there is any ambiguity in those documents concerning HTTP
+   version numbers, for all versions of HTTP.
+</t></abstract></front>
+<seriesInfo name="RFC" value="2145"/>
+  <front>
+    <title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title>
+    <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
+      <organization>Western Research Laboratory</organization>
+      <address><email>mogul@wrl.dec.com</email></address>
+    </author>
+    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+      <organization>Department of Information and Computer Science</organization>
+      <address><email>fielding@ics.uci.edu</email></address>
+    </author>
+    <author initials="J." surname="Gettys" fullname="Jim Gettys">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>jg@w3.org</email></address>
+    </author>
+    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+      <organization>W3 Consortium</organization>
+      <address><email>frystyk@w3.org</email></address>
+    </author>
+    <date month="May" year="1997"/>
+  </front>
+  <seriesInfo name="RFC" value="2145"/>
 </reference>
 …
 <reference anchor="RFC2396">
+<front>
+<title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title>
+<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+<organization abbrev="MIT/LCS">World Wide Web Consortium</organization>
+<address>
+<postal>
+<street>MIT Laboratory for Computer Science, NE43-356</street>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code></postal>
+<facsimile>+1(617)258-8682</facsimile>
+<email>timbl@w3.org</email></address></author>
+<author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+<organization abbrev="U.C. Irvine">Department of Information and Computer Science</organization>
+<address>
+<postal>
+<street>University of California, Irvine</street>
+<city>Irvine</city>
+<region>CA</region>
+<code>92697-3425</code></postal>
+<facsimile>+1(949)824-1715</facsimile>
+<email>fielding@ics.uci.edu</email></address></author>
+<author initials="L." surname="Masinter" fullname="Larry Masinter">
+<organization abbrev="Xerox Corporation">Xerox PARC</organization>
+<address>
+<postal>
+<street>3333 Coyote Hill Road</street>
+<city>Palo Alto</city>
+<region>CA</region>
+<code>94034</code></postal>
+<facsimile>+1(415)812-4333</facsimile>
+<email>masinter@parc.xerox.com</email></address></author>
+<date month="August" year="1998"/>
+<area>Applications</area>
+<keyword>uniform resource</keyword>
+<keyword>URI</keyword>
+</front>
+<seriesInfo name="RFC" value="2396"/>
+  <front>
+    <title abbrev="URI Generic Syntax">Uniform Resource Identifiers (URI): Generic Syntax</title>
+    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+      <organization abbrev="MIT/LCS">World Wide Web Consortium</organization>
+      <address><email>timbl@w3.org</email></address>
+    </author>
+    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+      <organization abbrev="U.C. Irvine">Department of Information and Computer Science</organization>
+      <address><email>fielding@ics.uci.edu</email></address>
+    </author>
+    <author initials="L." surname="Masinter" fullname="Larry Masinter">
+      <organization abbrev="Xerox Corporation">Xerox PARC</organization>
+      <address><email>masinter@parc.xerox.com</email></address>
+    </author>
+    <date month="August" year="1998"/>
+  </front>
+  <seriesInfo name="RFC" value="2396"/>
 </reference>
 …
    by the client prior to the request and closed by the server after
    sending the response. Some implementations implement the Keep-Alive
+   version of persistent connections described in <xref x:sec="19.7.1" x:fmt="sec" target="RFC2068"/> of RFC
+<xref target="RFC2068"/>.
+   version of persistent connections described in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>.
 </t>
 …
 <t>
    The original HTTP/1.0 form of persistent connections (the Connection:
    Keep-Alive and Keep-Alive header) is documented in RFC 2068. <xref target="RFC2068"/>
+   Keep-Alive and Keep-Alive header) is documented in <xref target="RFC2068"/>.
 </t>
 </section>
 …
    This specification has been carefully audited to correct and
    disambiguate key word usage; RFC 2068 had many problems in respect to
    the conventions laid out in RFC 2119 <xref target="RFC2119"/>.
+   the conventions laid out in <xref target="RFC2119"/>.
 </t>
 <t>
 …
 <t>
    The use and interpretation of HTTP version numbers has been clarified
    by RFC 2145. Require proxies to upgrade requests to highest protocol
+   by <xref target="RFC2145"/>. Require proxies to upgrade requests to highest protocol
    version they support to deal with problems discovered in HTTP/1.0
    implementations (<xref target="http.version"/>)

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

-                      r96
+                      r97
       </p>
       <dl class="empty">
          <dd> <b>Note:</b> RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most
             existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless
             of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear
             which kind of reaction is expected of the client.
+         <dd> <b>Note:</b>  <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations
+            treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method.
+            The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected
+            of the client.
          </dd>
       </dl>
 …
       </p>
       <dl class="empty">
          <dd> <b>Note:</b> RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not
             observing these limitations has significant security consequences.
+         <dd> <b>Note:</b>  <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing
+            these limitations has significant security consequences.
          </dd>
       </dl>
 …
       <div id="rfc.iref.h.4"></div>
       <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="header.from" href="#header.from">From</a></h2>
       <p id="rfc.section.10.3.p.1">The From request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> as updated by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>:
+      <p id="rfc.section.10.3.p.1">The From request-header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a> as updated by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>:
       </p>
       <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.16"></span>    From   = "From" ":" mailbox
 …
       <h1 id="rfc.references"><a href="#rfc.section.14" id="rfc.section.14">14.</a> References
       </h1>
       <table summary="References">
+      <table summary="References">
          <tr>
             <td class="reference"><b id="Luo1998">[Luo1998]</b></td>
 …
             <td class="reference"><b id="RFC1123">[RFC1123]</b></td>
             <td class="top"><a title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD&nbsp;3, RFC&nbsp;1123, October&nbsp;1989.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC1945">[RFC1945]</b></td>
+            <td class="top"><a title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.T.</a>, and <a title="W3 Consortium, MIT Laboratory for Computer Science">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC&nbsp;1945, May&nbsp;1996.
             </td>
          </tr>
 …
       <p id="rfc.section.A.p.5">Clean up confusion between 403 and 404 responses. (Section <a href="#status.403" id="rfc.xref.status.403.2" title="403 Forbidden">9.4.4</a>, <a href="#status.404" id="rfc.xref.status.404.2" title="404 Not Found">9.4.5</a>, and <a href="#status.410" id="rfc.xref.status.410.2" title="410 Gone">9.4.11</a>)
       </p>
       <p id="rfc.section.A.p.6">The PATCH<span id="rfc.iref.p.3"></span><span id="rfc.iref.m.10"></span>, LINK<span id="rfc.iref.l.2"></span><span id="rfc.iref.m.11"></span>, UNLINK<span id="rfc.iref.u.2"></span><span id="rfc.iref.m.12"></span> methods were defined but not commonly implemented in previous versions of this specification. See RFC 2068 <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
+      <p id="rfc.section.A.p.6">The PATCH<span id="rfc.iref.p.3"></span><span id="rfc.iref.m.10"></span>, LINK<span id="rfc.iref.l.2"></span><span id="rfc.iref.m.11"></span>, UNLINK<span id="rfc.iref.u.2"></span><span id="rfc.iref.m.12"></span> methods were defined but not commonly implemented in previous versions of this specification. See <a href="#RFC2068" id="rfc.xref.RFC2068.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
       </p>
       <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
 …
                   <li class="indline1">Retry-After header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.header.retry-after.1">6</a>, <a class="iref" href="#rfc.iref.r.2"><b>10.7</b></a></li>
                   <li class="indline1"><em>RFC1123</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1123.1">10.3</a>, <a class="iref" href="#RFC1123"><b>14</b></a></li>
+                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#RFC2068"><b>14</b></a>, <a class="iref" href="#rfc.xref.RFC2068.1">A</a></li>
+                  <li class="indline1"><em>RFC1945</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1945.1">9.3.3</a>, <a class="iref" href="#RFC1945"><b>14</b></a></li>
+                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">9.3.3</a>, <a class="iref" href="#rfc.xref.RFC2068.2">9.3.6</a>, <a class="iref" href="#RFC2068"><b>14</b></a>, <a class="iref" href="#rfc.xref.RFC2068.3">A</a></li>
                   <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>14</b></a></li>
                   <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">§</a>, <a class="iref" href="#RFC2616"><b>14</b></a></li>

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

-                      r96
+                      r97
    change the conditions under which the request was issued.
   <list><t>
       <x:h>Note:</x:h> RFC 1945 and RFC 2068 specify that the client is not allowed
+      <x:h>Note:</x:h> <xref target="RFC1945"/> and <xref target="RFC2068"/> specify that the client is not allowed
       to change the method on the redirected request.  However, most
       existing user agent implementations treat 302 as if it were a 303
 …
    proxy. 305 responses &MUST; only be generated by origin servers.
   <list><t>
       <x:h>Note:</x:h> RFC 2068 was not clear that 305 was intended to redirect a
+      <x:h>Note:</x:h> <xref target="RFC2068"/> was not clear that 305 was intended to redirect a
       single request, and to be generated by origin servers only.  Not
       observing these limitations has significant security consequences.
 …
    e-mail address for the human user who controls the requesting user
    agent. The address &SHOULD; be machine-usable, as defined by "mailbox"
    in RFC 822 <xref target="RFC822"/> as updated by RFC 1123 <xref target="RFC1123"/>:
+   in <xref target="RFC822"/> as updated by <xref target="RFC1123"/>:
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="From"/>
 …
 <reference anchor="RFC1123">
+<front>
+<title>Requirements for Internet Hosts - Application and Support</title>
+<author initials="R." surname="Braden" fullname="Robert Braden">
+<organization>University of Southern California (USC), Information Sciences Institute</organization>
+<address>
+<postal>
+<street>4676 Admiralty Way</street>
+<city>Marina del Rey</city>
+<region>CA</region>
+<code>90292-6695</code>
+<country>US</country></postal>
+<phone>+1 213 822 1511</phone>
+<email>Braden@ISI.EDU</email></address></author>
+<date month="October" year="1989"/></front>
+<seriesInfo name="STD" value="3"/>
+<seriesInfo name="RFC" value="1123"/>
+  <front>
+    <title>Requirements for Internet Hosts - Application and Support</title>
+    <author initials="R." surname="Braden" fullname="Robert Braden">
+      <organization>University of Southern California (USC), Information Sciences Institute</organization>
+      <address><email>Braden@ISI.EDU</email></address>
+    </author>
+    <date month="October" year="1989"/>
+  </front>
+  <seriesInfo name="STD" value="3"/>
+  <seriesInfo name="RFC" value="1123"/>
 </reference>
 <reference anchor="RFC822">
+<front>
+<title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title>
+<author initials="D.H." surname="Crocker" fullname="David H. Crocker">
+<organization>University of Delaware, Dept. of Electrical Engineering</organization>
+<address>
+<postal>
+<street/>
+<city>Newark</city>
+<region>DE</region>
+<code>19711</code>
+<country>US</country></postal>
+<email>DCrocker@UDel-Relay</email></address></author>
+<date month="August" day="13" year="1982"/></front>
+<seriesInfo name="STD" value="11"/>
+<seriesInfo name="RFC" value="822"/>
+  <front>
+    <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title>
+    <author initials="D.H." surname="Crocker" fullname="David H. Crocker">
+      <organization>University of Delaware, Dept. of Electrical Engineering</organization>
+      <address><email>DCrocker@UDel-Relay</email></address>
+    </author>
+    <date month="August" day="13" year="1982"/>
+  </front>
+  <seriesInfo name="STD" value="11"/>
+  <seriesInfo name="RFC" value="822"/>
 </reference>
+<reference anchor="RFC1945">
+  <front>
+    <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title>
+    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+      <organization>MIT, Laboratory for Computer Science</organization>
+      <address><email>timbl@w3.org</email></address>
+    </author>
+    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
+      <address><email>fielding@ics.uci.edu</email></address>
+    </author>
+    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+      <organization>W3 Consortium, MIT Laboratory for Computer Science</organization>
+      <address><email>frystyk@w3.org</email></address>
+    </author>
+    <date month="May" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="1945"/>
+</reference>
 <reference anchor="RFC2068">
+<front>
+<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
+<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
+<organization>University of California, Irvine, Department of Information and Computer Science</organization>
+<address>
+<postal>
+<street/>
+<city>Irvine</city>
+<region>CA</region>
+<code>92717-3425</code>
+<country>US</country></postal>
+<facsimile>+1 714 824 4056</facsimile>
+<email>fielding@ics.uci.edu</email></address></author>
+<author initials="J." surname="Gettys" fullname="Jim Gettys">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>jg@w3.org</email></address></author>
+<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+<organization>Digital Equipment Corporation, Western Research Laboratory</organization>
+<address>
+<postal>
+<street>250 University Avenue</street>
+<city>Palo Alto</city>
+<region>CA</region>
+<code>94301</code>
+<country>US</country></postal>
+<email>mogul@wrl.dec.com</email></address></author>
+<author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>frystyk@w3.org</email></address></author>
+<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>timbl@w3.org</email></address></author>
+<date month="January" year="1997"/>
+<abstract>
+<t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t>
+<t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".</t></abstract></front>
+<seriesInfo name="RFC" value="2068"/>
+  <front>
+    <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
+    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
+      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
+      <address><email>fielding@ics.uci.edu</email></address>
+    </author>
+    <author initials="J." surname="Gettys" fullname="Jim Gettys">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>jg@w3.org</email></address>
+    </author>
+    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+      <organization>Digital Equipment Corporation, Western Research Laboratory</organization>
+      <address><email>mogul@wrl.dec.com</email></address>
+    </author>
+    <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>frystyk@w3.org</email></address>
+    </author>
+    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>timbl@w3.org</email></address>
+    </author>
+    <date month="January" year="1997"/>
+  </front>
+  <seriesInfo name="RFC" value="2068"/>
 </reference>
 …
 <t>
    The PATCH<iref item="PATCH method" primary="true"/><iref item="Methods" subitem="PATCH" primary="true"/>, LINK<iref item="LINK method" primary="true"/><iref item="Methods" subitem="LINK" primary="true"/>, UNLINK<iref item="UNLINK method" primary="true"/><iref item="Methods" subitem="UNLINK" primary="true"/> methods were defined but not commonly
+   implemented in previous versions of this specification. See RFC 2068
+   <xref target="RFC2068"/>.
+   implemented in previous versions of this specification. See <xref target="RFC2068"/>.
 </t>
 </section>

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

-                      r96
+                      r97
       </p>
       <dl class="empty">
          <dd>An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
+         <dd>An encoding format produced by the file compression program "gzip" (GNU zip) as described in <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
          </dd>
       </dl>
 …
       </p>
       <dl class="empty">
          <dd>The "zlib" format defined in RFC 1950 <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a> in combination with the "deflate" compression mechanism described in RFC 1951 <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>.
+         <dd>The "zlib" format defined in <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a> in combination with the "deflate" compression mechanism described in <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>.
          </dd>
       </dl>
 …
       <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="multipart.types" href="#multipart.types">Multipart Types</a></h3>
       <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All
          multipart types share a common syntax, as defined in section <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1" id="rfc.xref.RFC2046.1">5.1.1</a> of RFC 2046 <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts. Unlike in RFC 2046, the epilogue of any multipart message <em class="bcp14">MUST</em> be empty; HTTP applications <em class="bcp14">MUST NOT</em> transmit the epilogue (even if the original multipart contains an epilogue). These restrictions exist in order to preserve
+         multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts. Unlike in RFC 2046, the epilogue of any multipart message <em class="bcp14">MUST</em> be empty; HTTP applications <em class="bcp14">MUST NOT</em> transmit the epilogue (even if the original multipart contains an epilogue). These restrictions exist in order to preserve
          the self-delimiting nature of a multipart message-body, wherein the "end" of the message-body is indicated by the ending multipart
          boundary.
       </p>
       <p id="rfc.section.2.3.2.p.2">In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception
+         is the "multipart/byteranges" type (<a href="p5-range.html#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</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>) when it appears in a 206 (Partial Content) response. In all other cases, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within
+         each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by their MIME semantics.
+         is the "multipart/byteranges" type (<a href="p5-range.html#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</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>) when it appears in a 206 (Partial Content) response.
       </p>
       <p id="rfc.section.2.3.2.p.3">In general, an HTTP user agent <em class="bcp14">SHOULD</em> follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. If an application receives
 …
       <dl class="empty">
          <dd> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request
             method, as described in RFC 1867 <a href="#RFC1867" id="rfc.xref.RFC1867.1"><cite title="Form-based File Upload in HTML">[RFC1867]</cite></a>.
+            method, as described in <a href="#RFC1867" id="rfc.xref.RFC1867.1"><cite title="Form-based File Upload in HTML">[RFC1867]</cite></a>.
          </dd>
       </dl>
 …
          Content-Language fields.
       </p>
       <p id="rfc.section.2.5.p.2">The syntax and registry of HTTP language tags is the same as that defined by RFC 1766 <a href="#RFC1766" id="rfc.xref.RFC1766.1"><cite title="Tags for the Identification of Languages">[RFC1766]</cite></a>. In summary, a language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags:
+      <p id="rfc.section.2.5.p.2">The syntax and registry of HTTP language tags is the same as that defined by <a href="#RFC1766" id="rfc.xref.RFC1766.1"><cite title="Tags for the Identification of Languages">[RFC1766]</cite></a>. In summary, a language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags:
       </p>
       <div id="rfc.figure.u.6"></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>     language-tag  = primary-tag *( "-" subtag )
 …
       </p>
       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span>    Accept-Encoding  = "Accept-Encoding" ":"
+#( codings [ ";" "q" "=" qvalue ] )
+    codings          = ( content-coding | "*" )
+</pre><p id="rfc.section.5.3.p.3">Examples of its use are:</p>
+      <div id="rfc.figure.u.21"></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.5">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
+            is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;2.4</a>, a qvalue of 0 means "not acceptable.")
+         </li>
+         <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header
+            field.
+         </li>
+         <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li>
+         <li>The "identity" content-coding is always acceptable, unless specifically refused because the Accept-Encoding field includes
+            "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the
+            Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.
+         </li>
+      </ol>
+      <p id="rfc.section.5.3.p.6">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.7">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>
+      <dl class="empty">
+         <dd> <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
+            messages sent with other content-codings. The server might also make this decision based on information about the particular
+            user-agent or client.
+         </dd>
+         <dd> <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.
+         </dd>
+      </dl>
+      <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 is similar to Accept, but restricts the set of natural languages that are preferred
+         as a response to the request. Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.5</a>.
+      </p>
+      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.24"></span><span id="rfc.iref.g.25"></span>    Accept-Language = "Accept-Language" ":"
+#( language-range [ ";" "q" "=" qvalue ] )
+    language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
+</pre><p id="rfc.section.5.4.p.3">Each language-range <em class="bcp14">MAY</em> 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.23"></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." A language-range matches a language-tag
+         if it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first tag character following the
+         prefix is "-". The special range "*", if present in the Accept-Language field, matches every tag not matched by any other
+         range present in the Accept-Language field.
+      </p>
+      <dl class="empty">
+         <dd> <b>Note:</b> This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always
+            true that if a user understands a language with a certain tag, then this user will also understand all languages with tags
+            for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case.
+         </dd>
+      </dl>
+      <p id="rfc.section.5.4.p.6">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range
+         in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor
+         assigned is 0. If no Accept-Language header is present in the request, the server <em class="bcp14">SHOULD</em> assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages which are assigned
+         a quality factor greater than 0 are acceptable.
+      </p>
+      <p id="rfc.section.5.4.p.7">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.8">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>
+      <dl class="empty">
+         <dd> <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,
+            users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available.
+            A user agent might suggest in such a case to add "en" to get the best matching behavior.
+         </dd>
+      </dl>
+      <div id="rfc.iref.c.2"></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 is used as a modifier to the media-type. When present, its value indicates what additional
+         content codings have been applied to the entity-body, 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 document to be compressed
+         without losing the identity of its underlying media type.
+      </p>
+      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.26"></span>    Content-Encoding  = "Content-Encoding" ":" 1#content-coding
+</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.25"></div><pre class="text">    Content-Encoding: gzip
+</pre><p id="rfc.section.5.5.p.5">The content-coding is a characteristic of the entity identified by the Request-URI. Typically, the entity-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 an entity is not "identity", then the response <em class="bcp14">MUST</em> include a Content-Encoding entity-header (<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 an entity 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 an entity, 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 entity-header fields not defined by this specification.
+      </p>
+      <div id="rfc.iref.c.3"></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 enclosed entity.
+         Note that this might not be equivalent to all the languages used within the entity-body.
+      </p>
+      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.27"></span>    Content-Language  = "Content-Language" ":" 1#language-tag
+</pre><p id="rfc.section.5.6.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;2.5</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate entities 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.27"></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
+         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
+         simultaneously in the original Maori and English versions, would call for
+      </p>
+      <div id="rfc.figure.u.28"></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 an entity 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>
+      <div id="rfc.iref.c.4"></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 entity-header field <em class="bcp14">MAY</em> be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location
+         separate from the requested resource's URI. A server <em class="bcp14">SHOULD</em> provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has
+         multiple entities associated with it, and those entities actually have separate locations by which they might be individually
+         accessed, the server <em class="bcp14">SHOULD</em> provide a Content-Location for the particular variant which is returned.
+      </p>
+      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.28"></span>    Content-Location = "Content-Location" ":"
+                      ( absoluteURI | relativeURI )
+</pre><p id="rfc.section.5.7.p.3">The value of Content-Location also defines the base URI for the entity.</p>
+      <p id="rfc.section.5.7.p.4">The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of
+         the resource corresponding to this particular entity at the time of the request. Future requests <em class="bcp14">MAY</em> specify the Content-Location URI as the request-URI if the desire is to identify the source of that particular entity.
+      </p>
+      <p id="rfc.section.5.7.p.5">A cache cannot assume that an entity 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. However, the Content-Location can be used to differentiate between multiple
+         entities retrieved from a single requested resource, as described in <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
+      </p>
+      <p id="rfc.section.5.7.p.6">If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.</p>
+      <p id="rfc.section.5.7.p.7">The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases.</p>
+      <div id="rfc.iref.c.5"></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 entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body.
+         (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious
+         attacks.)
+      </p>
+      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span>     Content-MD5   = "Content-MD5" ":" md5-digest
+     md5-digest   = &lt;base64 of 128 bit MD5 digest as per RFC 1864&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 entity-body. Only origin servers or clients <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 of the entity-body, including
+         gateways and proxies, <em class="bcp14">MAY</em> check that the digest value in this header field matches that of the entity-body as received.
+      </p>
+      <p id="rfc.section.5.8.p.4">The MD5 digest is computed based on the content of the entity-body, including any content-coding that has been applied, but
+         not including any transfer-encoding applied to the message-body. If the message is received with a transfer-encoding, that
+         encoding <em class="bcp14">MUST</em> be removed prior to checking the Content-MD5 value against the received entity.
+      </p>
+      <p id="rfc.section.5.8.p.5">This has the result that the digest is computed on the octets of the entity-body exactly as, and in the order that, they would
+         be sent if no transfer-encoding were being applied.
+      </p>
+      <p id="rfc.section.5.8.p.6">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.7">There are several consequences of this. The entity-body 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.8">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>
+      <dl class="empty">
+         <dd> <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
+            is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another
+            is that HTTP more frequently uses binary content types than MIME, so it is worth noting that, in such cases, the byte order
+            used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types
+            with any of several line break conventions and not just the canonical form using CRLF.
+         </dd>
+      </dl>
+      <div id="rfc.iref.c.6"></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 entity-body sent to the recipient or, in the case of
+         the HEAD method, the media type that would have been sent had the request been a GET.
+      </p>
+      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.31"></span>    Content-Type   = "Content-Type" ":" media-type
+</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.32"></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 an entity 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>
+      <p id="rfc.section.6.p.1">TBD.</p>
+      <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
+         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
+         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
+         to configure the contents of an Accept-Language header to be sent in every request are strongly encouraged to let the configuration
+         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,
+         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
+         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
+         of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will
+         also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to
+         be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could
+         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="#RFC1806" id="rfc.xref.RFC1806.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[RFC1806]</cite></a>, from which the often implemented Content-Disposition (see <a href="#content-disposition" id="rfc.xref.content-disposition.1" 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="#RFC2183" id="rfc.xref.RFC2183.1"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field">[RFC2183]</cite></a> (which updates <a href="#RFC1806" id="rfc.xref.RFC1806.2"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[RFC1806]</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 href="#rfc.section.9" id="rfc.section.9">9.</a> References
+      </h1>
+      <table summary="References">
+         <tr>
+            <td class="reference"><b id="Part1">[Part1]</b></td>
+            <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, <a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-latest">HTTP/1.1, part 1: URIs, Connections, and Message Parsing</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p1-messaging-latest (work in progress), December&nbsp;2007.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="Part2">[Part2]</b></td>
+            <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, <a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">HTTP/1.1, part 2: Message Semantics</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p2-semantics-latest (work in progress), December&nbsp;2007.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="Part4">[Part4]</b></td>
+            <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, <a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-latest">HTTP/1.1, part 4: Conditional Requests</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p4-conditional-latest (work in progress), December&nbsp;2007.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="Part5">[Part5]</b></td>
+            <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, <a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-latest">HTTP/1.1, part 5: Range Requests and Partial Responses</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p5-range-latest (work in progress), December&nbsp;2007.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="Part6">[Part6]</b></td>
+            <td class="top"><a title="Day Software">Fielding, R., Ed.</a>, <a title="One Laptop per Child">Gettys, J.</a>, <a title="Hewlett-Packard Company">Mogul, J.</a>, <a title="Microsoft Corporation">Frystyk, H.</a>, <a title="Adobe Systems, Incorporated">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, <a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a title="greenbytes GmbH">J. F. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-latest">HTTP/1.1, part 6: Caching</a>”, Internet-Draft&nbsp;draft-ietf-httpbis-p6-cache-latest (work in progress), December&nbsp;2007.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC1766">[RFC1766]</b></td>
+            <td class="top"><a title="UNINETT">Alvestrand, H.</a>, “<a href="http://tools.ietf.org/html/rfc1766">Tags for the Identification of Languages</a>”, RFC&nbsp;1766, March&nbsp;1995.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC1806">[RFC1806]</b></td>
+            <td class="top"><a title="New Century Systems">Troost, R.</a> and <a title="QUALCOMM Incorporated">S. Dorner</a>, “<a href="http://tools.ietf.org/html/rfc1806">Communicating Presentation Information in Internet Messages: The Content-Disposition Header</a>”, RFC&nbsp;1806, June&nbsp;1995.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC1864">[RFC1864]</b></td>
+            <td class="top"><a title="Carnegie Mellon University">Myers, J.</a> and <a title="Dover Beach Consulting, Inc.">M. Rose</a>, “<a href="http://tools.ietf.org/html/rfc1864">The Content-MD5 Header Field</a>”, RFC&nbsp;1864, October&nbsp;1995.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC1867">[RFC1867]</b></td>
+            <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a> and <a title="XSoft, Xerox Corporation">E. Nebel</a>, “<a href="http://tools.ietf.org/html/rfc1867">Form-based File Upload in HTML</a>”, RFC&nbsp;1867, November&nbsp;1995.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC1945">[RFC1945]</b></td>
+            <td class="top"><a title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.T.</a>, and <a title="W3 Consortium, MIT Laboratory for Computer Science">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC&nbsp;1945, May&nbsp;1996.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC1950">[RFC1950]</b></td>
+            <td class="top"><a title="Aladdin Enterprises">Deutsch, L.P.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC&nbsp;1950, May&nbsp;1996.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC1951">[RFC1951]</b></td>
+            <td class="top"><a title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="http://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC&nbsp;1951, May&nbsp;1996.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC1952">[RFC1952]</b></td>
+            <td class="top"><a title="Aladdin Enterprises">Deutsch, P.</a>, <a>Gailly, J-L.</a>, <a>Adler, M.</a>, <a>Deutsch, L.P.</a>, and <a>G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC&nbsp;1952, May&nbsp;1996.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC2045">[RFC2045]</b></td>
+            <td class="top"><a title="Innosoft International, Inc.">Freed, N.</a> and <a title="First Virtual Holdings">N.S. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC&nbsp;2045, November&nbsp;1996.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC2046">[RFC2046]</b></td>
+            <td class="top"><a title="Innosoft International, Inc.">Freed, N.</a> and <a title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>”, RFC&nbsp;2046, November&nbsp;1996.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC2049">[RFC2049]</b></td>
+            <td class="top"><a title="Innosoft International, Inc.">Freed, N.</a> and <a title="First Virtual Holdings">N.S. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</a>”, RFC&nbsp;2049, November&nbsp;1996.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC2068">[RFC2068]</b></td>
+            <td class="top"><a title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2068, January&nbsp;1997.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC2076">[RFC2076]</b></td>
+            <td class="top"><a title="Stockholm University/KTH">Palme, J.</a>, “<a href="http://tools.ietf.org/html/rfc2076">Common Internet Message Headers</a>”, RFC&nbsp;2076, February&nbsp;1997.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC2110">[RFC2110]</b></td>
+            <td class="top"><a title="Stockholm University and KTH">Palme, J.</a> and <a title="Microsoft Corporation">A. Hopmann</a>, “<a href="http://tools.ietf.org/html/rfc2110">MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)</a>”, RFC&nbsp;2110, March&nbsp;1997.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC2119">[RFC2119]</b></td>
+            <td class="top"><a title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC2183">[RFC2183]</b></td>
+            <td class="top"><a title="New Century Systems">Troost, R.</a>, <a title="QUALCOMM Incorporated">Dorner, S.</a>, and <a title="Department of Computer Science">K. Moore</a>, “<a href="http://tools.ietf.org/html/rfc2183">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a>”, RFC&nbsp;2183, August&nbsp;1997.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC2277">[RFC2277]</b></td>
+            <td class="top"><a title="UNINETT">Alvestrand, H.T.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP&nbsp;18, RFC&nbsp;2277, January&nbsp;1998.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC2279">[RFC2279]</b></td>
+            <td class="top"><a title="Alis Technologies">Yergeau, F.</a>, “<a href="http://tools.ietf.org/html/rfc2279">UTF-8, a transformation format of ISO 10646</a>”, RFC&nbsp;2279, January&nbsp;1998.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
+            <td class="top"><a title="University of California, Irvine">Fielding, R.</a>, <a title="W3C">Gettys, J.</a>, <a title="Compaq Computer Corporation">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a title="Xerox Corporation">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, and <a title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC4288">[RFC4288]</b></td>
+            <td class="top"><a title="Sun Microsystems">Freed, N.</a> and <a>J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP&nbsp;13, RFC&nbsp;4288, December&nbsp;2005.
+            </td>
+         </tr>
+         <tr>
+            <td class="reference"><b id="RFC822">[RFC822]</b></td>
+            <td class="top"><a title="University of Delaware, Dept. of Electrical Engineering">Crocker, D.H.</a>, “<a href="http://tools.ietf.org/html/rfc822">Standard for the format of ARPA Internet text messages</a>”, STD&nbsp;11, RFC&nbsp;822, August&nbsp;1982.
+            </td>
+         </tr>
+      </table>
+      <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
+      <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span>
+            (editor)
+            <span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Day Software</span><span class="adr"><span class="street-address vcardline">23 Corporate Plaza DR, Suite 280</span><span class="vcardline"><span class="locality">Newport Beach</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">92660</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel">Phone: <a href="tel:+1-949-706-5300"><span class="value">+1-949-706-5300</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1-949-706-5305"><span class="value">+1-949-706-5305</span></a></span><span class="vcardline">EMail: <a><span class="email">fielding@gbiv.com</span></a></span><span class="vcardline">URI: <a href="http://roy.gbiv.com/" class="url">http://roy.gbiv.com/</a></span></address>
+      <address class="vcard"><span class="vcardline"><span class="fn">Jim Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">Jim</span></span></span><span class="org vcardline">One Laptop per Child</span><span class="adr"><span class="street-address vcardline">21 Oak Knoll Road</span><span class="vcardline"><span class="locality">Carlisle</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">01741</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a><span class="email">jg@laptop.org</span></a></span><span class="vcardline">URI: <a href="http://www.laptop.org/" class="url">http://www.laptop.org/</a></span></address>
+      <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Hewlett-Packard Company</span><span class="adr"><span class="street-address vcardline">HP Labs, Large Scale Systems Group</span><span class="street-address vcardline">1501 Page Mill Road, MS 1177</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">94304</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a><span class="email">JeffMogul@acm.org</span></a></span></address>
+      <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span>&nbsp;<span class="postal-code">98052</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a><span class="email">henrikn@microsoft.com</span></a></span></address>
+      <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Adobe Systems, Incorporated</span><span class="adr"><span class="street-address vcardline">345 Park Ave</span><span class="vcardline"><span class="locality">San Jose</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">95110</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a><span class="email">LMM@acm.org</span></a></span><span class="vcardline">URI: <a href="http://larry.masinter.net/" class="url">http://larry.masinter.net/</a></span></address>
+      <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span>&nbsp;<span class="postal-code">98052</span></span></span><span class="vcardline">EMail: <a><span class="email">paulle@microsoft.com</span></a></span></address>
+      <address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Computer Science and Artificial Intelligence Laboratory</span><span class="street-address vcardline">The Stata Center, Building 32</span><span class="street-address vcardline">32 Vassar Street</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a><span class="email">timbl@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.w3.org/People/Berners-Lee/" class="url">http://www.w3.org/People/Berners-Lee/</a></span></address>
+      <address class="vcard"><span class="vcardline"><span class="fn">Yves Lafon</span>
+            (editor)
+            <span class="n hidden"><span class="family-name">Lafon</span><span class="given-name">Yves</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">W3C / ERCIM</span><span class="street-address vcardline">2004, rte des Lucioles</span><span class="vcardline"><span class="locality">Sophia-Antipolis</span>, <span class="region">AM</span>&nbsp;<span class="postal-code">06902</span></span><span class="country-name vcardline">France</span></span><span class="vcardline">EMail: <a><span class="email">ylafon@w3.org</span></a></span><span class="vcardline">URI: <a href="http://www.raubacapeu.net/people/yves/" class="url">http://www.raubacapeu.net/people/yves/</a></span></address>
+      <address class="vcard"><span class="vcardline"><span class="fn">Julian F. Reschke</span>
+            (editor)
+            <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span>&nbsp;<span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">EMail: <a><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address>
+      <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a>&nbsp;<a id="differences.between.http.entities.and.rfc.2045.entities" href="#differences.between.http.entities.and.rfc.2045.entities">Differences Between HTTP Entities and RFC 2045 Entities</a></h1>
+      <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC822" id="rfc.xref.RFC822.1"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, RFC 2045
+         discusses mail, and HTTP has a few features that are different from those described in RFC 2045. These differences were carefully
+         chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date
+         comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
+      </p>
+      <p id="rfc.section.A.p.2">This appendix describes specific areas where HTTP differs from RFC 2045. Proxies and gateways to strict MIME environments <em class="bcp14">SHOULD</em> be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments
+         to HTTP also need to be aware of the differences because some conversions might be required.
+      </p>
+      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="mime-version" href="#mime-version">MIME-Version</a></h2>
+      <p id="rfc.section.A.1.p.1">HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages <em class="bcp14">MAY</em> include a single MIME-Version general-header field to indicate what version of the MIME protocol was used to construct the
+         message. Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol (as
+         defined in RFC 2045<a href="#RFC2045" id="rfc.xref.RFC2045.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME
+         environments.
+      </p>
+      <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.32"></span>    MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+</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
+         document and not the MIME specification.
+      </p>
+      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="conversion.to.canonical.form" href="#conversion.to.canonical.form">Conversion to Canonical Form</a></h2>
+      <p id="rfc.section.A.2.p.1"> <a href="#RFC2045" id="rfc.xref.RFC2045.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> requires that an Internet mail entity be converted to canonical form prior to being transferred, as described in section <a href="http://tools.ietf.org/html/rfc2049#section-4">Section 4</a> of <a href="#RFC2049" id="rfc.xref.RFC2049.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples">[RFC2049]</cite></a>. <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;2.3.1</a> of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line
+         break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted
+         over HTTP.
+      </p>
+      <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;2.3.1</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of
+         a Content-Encoding and by the fact that HTTP allows the use of some character sets which do not use octets 13 and 10 to represent
+         CR and LF, as is the case for some multi-byte character sets.
+      </p>
+      <p id="rfc.section.A.2.p.3">Implementors should note that conversion will break any cryptographic checksums applied to the original content unless the
+         original content is already in canonical form. Therefore, the canonical form is recommended for any content that uses such
+         checksums in HTTP.
+      </p>
+      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="introduction.of.content-encoding" href="#introduction.of.content-encoding">Introduction of Content-Encoding</a></h2>
+      <p id="rfc.section.A.3.p.1">RFC 2045 does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier
+         on the media type, proxies and gateways from HTTP to MIME-compliant protocols <em class="bcp14">MUST</em> either change the value of the Content-Type header field or decode the entity-body before forwarding the message. (Some experimental
+         applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform
+         a function equivalent to Content-Encoding. However, this parameter is not part of RFC 2045).
+      </p>
+      <h2 id="rfc.section.A.4"><a href="#rfc.section.A.4">A.4</a>&nbsp;<a id="no.content-transfer-encoding" href="#no.content-transfer-encoding">No Content-Transfer-Encoding</a></h2>
+      <p id="rfc.section.A.4.p.1">HTTP does not use the Content-Transfer-Encoding field of RFC 2045. Proxies and gateways from MIME-compliant protocols to HTTP <em class="bcp14">MUST</em> remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
+      </p>
+      <p id="rfc.section.A.4.p.2">Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct
+         format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol
+         being used. Such a proxy or gateway <em class="bcp14">SHOULD</em> label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over
+         the destination protocol.
+      </p>
+      <h2 id="rfc.section.A.5"><a href="#rfc.section.A.5">A.5</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h2>
+      <p id="rfc.section.A.5.p.1">HTTP/1.1 introduces the Transfer-Encoding header field (<a href="p1-messaging.html#header.transfer-encoding" title="Transfer-Encoding">Section 8.7</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>). Proxies/gateways <em class="bcp14">MUST</em> remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
+      </p>
+      <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
+      <p id="rfc.section.A.6.p.1">HTTP implementations which share code with MHTML <a href="#RFC2110" id="rfc.xref.RFC2110.1"><cite title="MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2110]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not
+         fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations
+         and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section&nbsp;2.3.2</a>) and does not interpret the content or any MIME header lines that might be contained therein.
+      </p>
+      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="additional.features" href="#additional.features">Additional Features</a></h1>
+      <p id="rfc.section.B.p.1"> <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> document protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.1
+         applications. Implementors are advised to be aware of these features, but cannot rely upon their presence in, or interoperability
+         with, other HTTP/1.1 applications. Some of these describe proposed experimental features, and some describe features that
+         experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification.
+      </p>
+      <p id="rfc.section.B.p.2">A number of other headers, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see <a href="#RFC2076" id="rfc.xref.RFC2076.1"><cite title="Common Internet Message Headers">[RFC2076]</cite></a>).
+      </p>
+      <div id="rfc.iref.h.10"></div>
+      <div id="rfc.iref.c.7"></div>
+      <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;<a id="content-disposition" href="#content-disposition">Content-Disposition</a></h2>
+      <p id="rfc.section.B.1.p.1">The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename
+         if the user requests that the content is saved to a file. This usage is derived from the definition of Content-Disposition
+         in <a href="#RFC1806" id="rfc.xref.RFC1806.3"><cite title="Communicating Presentation Information in Internet Messages: The Content-Disposition Header">[RFC1806]</cite></a>.
+      </p>
+      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span>     content-disposition = "Content-Disposition" ":"
+                           disposition-type *( ";" disposition-parm )
+     disposition-type = "attachment" | disp-extension-token
+     disposition-parm = filename-parm | disp-extension-parm
+     filename-parm = "filename" "=" quoted-string
+     disp-extension-token = token
+     disp-extension-parm = token "=" ( token | quoted-string )
+</pre><p id="rfc.section.B.1.p.3">An example is</p>
+      <div id="rfc.figure.u.35"></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.
+      </p>
+      <p id="rfc.section.B.1.p.6">If this header is used in a response with the application/octet-stream content-type, the implied suggestion is that the user
+         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>
+      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2068" href="#changes.from.rfc.2068">Changes from RFC 2068</a></h1>
+      <p id="rfc.section.C.p.1">Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.2" title="Accept-Charset">Section&nbsp;5.2</a>)
+      </p>
+      <p id="rfc.section.C.p.2">Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce
+         it without a robust extension mechanism. In addition, it is used in a similar, but not identical fashion in MHTML <a href="#RFC2110" id="rfc.xref.RFC2110.2"><cite title="MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2110]</cite></a>.
+      </p>
+      <p id="rfc.section.C.p.3">A content-coding of "identity" was introduced, to solve problems discovered in caching. (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>)
+      </p>
+      <p id="rfc.section.C.p.4">Quality Values of zero should indicate that "I don't want something" to allow clients to refuse a representation. (<a href="#quality.values" title="Quality Values">Section&nbsp;2.4</a>)
+      </p>
+      <p id="rfc.section.C.p.5">The Alternates<span id="rfc.iref.a.5"></span><span id="rfc.iref.h.11"></span>, Content-Version<span id="rfc.iref.c.8"></span><span id="rfc.iref.h.12"></span>, Derived-From<span id="rfc.iref.d.2"></span><span id="rfc.iref.h.13"></span>, Link<span id="rfc.iref.l.1"></span><span id="rfc.iref.h.14"></span>, URI<span id="rfc.iref.u.1"></span><span id="rfc.iref.h.15"></span>, Public<span id="rfc.iref.p.1"></span><span id="rfc.iref.h.16"></span> and Content-Base<span id="rfc.iref.c.9"></span><span id="rfc.iref.h.17"></span> header fields were defined in previous versions of this specification, but not commonly implemented. See <a href="#RFC2068" id="rfc.xref.RFC2068.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
+      </p>
+      <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
+      <p>Copyright © The IETF Trust (2007).</p>
+      <p>This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the
+         authors retain all their rights.
+      </p>
+      <p>This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION
+         HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
+         DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
+         WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+      </p>
+      <h1><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
+      <p>The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might
+         be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any
+         license under such rights might or might not be available; nor does it represent that it has made any independent effort to
+         identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and
+         BCP 79.
+      </p>
+      <p>Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result
+         of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users
+         of this specification can be obtained from the IETF on-line IPR repository at &lt;<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>&gt;.
+      </p>
+      <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
+         rights that may cover technology that may be required to implement this standard. Please address the information to the IETF
+         at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>.
+      </p>
+      <h1>Acknowledgement</h1>
+      <p>Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).</p>
+      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
+      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.U">U</a>
+      </p>
+      <div class="print2col">
+         <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></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">C</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></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></li>
+                  <li class="indline1">Alternates header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.a.5"><b>C</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">compress&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.1">2.2</a></li>
+                  <li class="indline1">Content-Base header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.9"><b>C</b></a></li>
+                  <li class="indline1">Content-Disposition header&nbsp;&nbsp;<a class="iref" href="#rfc.xref.content-disposition.1">7.2</a>, <a class="iref" href="#rfc.iref.c.7"><b>B.1</b></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.2"><b>5.5</b></a>, <a class="iref" href="#rfc.xref.header.content-encoding.3">5.5</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.3"><b>5.6</b></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.4"><b>5.7</b></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.5"><b>5.8</b></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.6"><b>5.9</b></a></li>
+                  <li class="indline1">Content-Version header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.c.8"><b>C</b></a></li>
+               </ul>
+            </li>
+            <li class="indline0"><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul class="ind">
+                  <li class="indline1">deflate&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1">2.2</a></li>
+                  <li class="indline1">Derived-From header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.2"><b>C</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"><tt>Grammar</tt>&nbsp;&nbsp;
+                     <ul class="ind">
+                        <li class="indline1"><tt>Accept</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.17"><b>5.1</b></a></li>
+                        <li class="indline1"><tt>Accept-Charset</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.21"><b>5.2</b></a></li>
+                        <li class="indline1"><tt>Accept-Encoding</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.22"><b>5.3</b></a></li>
+                        <li class="indline1"><tt>accept-extension</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.20"><b>5.1</b></a></li>
+                        <li class="indline1"><tt>Accept-Language</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.19"><b>5.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.23"><b>5.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.33"><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-Language</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.27"><b>5.6</b></a></li>
+                        <li class="indline1"><tt>Content-Location</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.28"><b>5.7</b></a></li>
+                        <li class="indline1"><tt>Content-MD5</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.29"><b>5.8</b></a></li>
+                        <li class="indline1"><tt>Content-Type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.31"><b>5.9</b></a></li>
+                        <li class="indline1"><tt>disp-extension-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.38"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>disp-extension-token</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.37"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>disposition-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.35"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>disposition-type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.34"><b>B.1</b></a></li>
+                        <li class="indline1"><tt>entity-body</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.16"><b>3.2</b></a></li>
+                        <li class="indline1"><tt>entity-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.14"><b>3.1</b></a></li>
+                        <li class="indline1"><tt>extension-header</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.15"><b>3.1</b></a></li>
+                        <li class="indline1"><tt>filename-parm</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.36"><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>language-tag</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.11"><b>2.5</b></a></li>
+                        <li class="indline1"><tt>md5-digest</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.30"><b>5.8</b></a></li>
+                        <li class="indline1"><tt>media-range</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.18"><b>5.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.32"><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>primary-tag</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.12"><b>2.5</b></a></li>
+                        <li class="indline1"><tt>qvalue</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.10"><b>2.4</b></a></li>
+                        <li class="indline1"><tt>subtag</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.13"><b>2.5</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>
+                        <li class="indline1"><tt>type</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.5"><b>2.3</b></a></li>
+                        <li class="indline1"><tt>value</tt>&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.9"><b>2.3</b></a></li>
+                     </ul>
+                  </li>
+                  <li class="indline1">gzip&nbsp;&nbsp;<a class="iref" href="#rfc.iref.g.3">2.2</a></li>
+               </ul>
+            </li>
+            <li class="indline0"><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul class="ind">
+                  <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></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">C</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></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></li>
+                        <li class="indline1">Alternate&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.11"><b>C</b></a></li>
+                        <li class="indline1">Content-Base&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.17"><b>C</b></a></li>
+                        <li class="indline1">Content-Disposition&nbsp;&nbsp;<a class="iref" href="#rfc.xref.content-disposition.1">7.2</a>, <a class="iref" href="#rfc.iref.h.10"><b>B.1</b></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></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></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></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></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></li>
+                        <li class="indline1">Content-Version&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.12"><b>C</b></a></li>
+                        <li class="indline1">Derived-From&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.13"><b>C</b></a></li>
+                        <li class="indline1">Link&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.14"><b>C</b></a></li>
+                        <li class="indline1">Public&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.16"><b>C</b></a></li>
+                        <li class="indline1">URI&nbsp;&nbsp;<a class="iref" href="#rfc.iref.h.15"><b>C</b></a></li>
+                     </ul>
+                  </li>
+               </ul>
+            </li>
+            <li class="indline0"><a id="rfc.index.I" href="#rfc.index.I"><b>I</b></a><ul class="ind">
+                  <li class="indline1">identity&nbsp;&nbsp;<a class="iref" href="#rfc.iref.i.1">2.2</a></li>
+               </ul>
+            </li>
+            <li class="indline0"><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul class="ind">
+                  <li class="indline1">Link header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.l.1"><b>C</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">3.1</a>, <a class="iref" href="#rfc.xref.Part1.2">3.2</a>, <a class="iref" href="#rfc.xref.Part1.3">3.2.2</a>, <a class="iref" href="#Part1"><b>9</b></a>, <a class="iref" href="#rfc.xref.Part1.4">A.5</a><ul class="ind">
+                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">3.2</a></li>
+                        <li class="indline1"><em>Section 4.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.3">3.2.2</a></li>
+                        <li class="indline1"><em>Section 8.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">3.1</a></li>
+                        <li class="indline1"><em>Section 8.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.4">A.5</a></li>
+                     </ul>
+                  </li>
+                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">3.1</a>, <a class="iref" href="#rfc.xref.Part2.2">4.1</a>, <a class="iref" href="#Part2"><b>9</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 10.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">3.1</a></li>
+                        <li class="indline1"><em>Section 10.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">4.1</a></li>
+                     </ul>
+                  </li>
+                  <li class="indline1"><em>Part4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">3.1</a>, <a class="iref" href="#Part4"><b>9</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 6.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part4.1">3.1</a></li>
+                     </ul>
+                  </li>
+                  <li class="indline1"><em>Part5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">2.3.2</a>, <a class="iref" href="#rfc.xref.Part5.2">3.1</a>, <a class="iref" href="#Part5"><b>9</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 5.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.2">3.1</a></li>
+                        <li class="indline1"><em>Section A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part5.1">2.3.2</a></li>
+                     </ul>
+                  </li>
+                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">3.1</a>, <a class="iref" href="#rfc.xref.Part6.2">4.1</a>, <a class="iref" href="#rfc.xref.Part6.3">5.7</a>, <a class="iref" href="#Part6"><b>9</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">3.1</a></li>
+                     </ul>
+                  </li>
+                  <li class="indline1">Public header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1"><b>C</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"><em>RFC1766</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1766.1">2.5</a>, <a class="iref" href="#RFC1766"><b>9</b></a></li>
+                  <li class="indline1"><em>RFC1806</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1806.1">7.2</a>, <a class="iref" href="#rfc.xref.RFC1806.2">7.2</a>, <a class="iref" href="#RFC1806"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC1806.3">B.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="#RFC1864"><b>9</b></a></li>
+                  <li class="indline1"><em>RFC1867</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1867.1">2.3.2</a>, <a class="iref" href="#RFC1867"><b>9</b></a></li>
+                  <li class="indline1"><em>RFC1945</em>&nbsp;&nbsp;<a class="iref" href="#RFC1945"><b>9</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">2.2</a>, <a class="iref" href="#RFC1950"><b>9</b></a></li>
+                  <li class="indline1"><em>RFC1951</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1951.1">2.2</a>, <a class="iref" href="#RFC1951"><b>9</b></a></li>
+                  <li class="indline1"><em>RFC1952</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1952.1">2.2</a>, <a class="iref" href="#RFC1952"><b>9</b></a></li>
+                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<a class="iref" href="#RFC2045"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2045.1">A</a>, <a class="iref" href="#rfc.xref.RFC2045.2">A.1</a>, <a class="iref" href="#rfc.xref.RFC2045.3">A.2</a></li>
+                  <li class="indline1"><em>RFC2046</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.1">2.3.2</a>, <a class="iref" href="#RFC2046"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2046.2">A.2</a><ul class="ind">
+                        <li class="indline1"><em>Section 5.1.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2046.1">2.3.2</a></li>
+                     </ul>
+                  </li>
+                  <li class="indline1"><em>RFC2049</em>&nbsp;&nbsp;<a class="iref" href="#RFC2049"><b>9</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="#RFC2068"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2068.1">B</a>, <a class="iref" href="#rfc.xref.RFC2068.2">C</a></li>
+                  <li class="indline1"><em>RFC2076</em>&nbsp;&nbsp;<a class="iref" href="#RFC2076"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2076.1">B</a></li>
+                  <li class="indline1"><em>RFC2110</em>&nbsp;&nbsp;<a class="iref" href="#RFC2110"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC2110.1">A.6</a>, <a class="iref" href="#rfc.xref.RFC2110.2">C</a></li>
+                  <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>9</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="#RFC2183"><b>9</b></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>9</b></a></li>
+                  <li class="indline1"><em>RFC2279</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2279.1">2.1</a>, <a class="iref" href="#RFC2279"><b>9</b></a></li>
+                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">§</a>, <a class="iref" href="#RFC2616"><b>9</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="#rfc.xref.RFC4288.2">2.3</a>, <a class="iref" href="#RFC4288"><b>9</b></a></li>
+                  <li class="indline1"><em>RFC822</em>&nbsp;&nbsp;<a class="iref" href="#RFC822"><b>9</b></a>, <a class="iref" href="#rfc.xref.RFC822.1">A</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">URI header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.u.1"><b>C</b></a></li>
+               </ul>
+            </li>
+         </ul>
+      </div>
+   </body>
+</html>

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

-                      r96
+                      r97
     <t>
         An encoding format produced by the file compression program
         "gzip" (GNU zip) as described in RFC 1952 <xref target="RFC1952"/>. This format is a
+        "gzip" (GNU zip) as described in <xref target="RFC1952"/>. This format is a
         Lempel-Ziv coding (LZ77) with a 32 bit CRC.
     </t>
 …
    deflate<iref item="deflate"/>
   <list><t>
         The "zlib" format defined in RFC 1950 <xref target="RFC1950"/> in combination with
         the "deflate" compression mechanism described in RFC 1951 <xref target="RFC1951"/>.
+        The "zlib" format defined in <xref target="RFC1950"/> in combination with
+        the "deflate" compression mechanism described in <xref target="RFC1951"/>.
   </t></list>
 </t>
 …
    MIME provides for a number of "multipart" types -- encapsulations of
    one or more entities within a single message-body. All multipart
    types share a common syntax, as defined in section <xref target="RFC2046" x:sec="5.1.1" x:fmt="number"/> of RFC 2046
    <xref target="RFC2046"/>, and &MUST; include a boundary parameter as part of the media type
+   types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>,
+   and &MUST; include a boundary parameter as part of the media type
    value. The message body is itself a protocol element and &MUST;
    therefore use only CRLF to represent line breaks between body-parts.
 …
    any other media type: strictly as payload. The one exception is the
    "multipart/byteranges" type (&multipart-byteranges;) when it appears in a 206
+   (Partial Content) response. In all
+   (Partial Content) response.
+   <!-- jre: re-insert removed text pointing to caching? -->
+   In all
    other cases, an HTTP user agent &SHOULD; follow the same or similar
    behavior as a MIME user agent would upon receipt of a multipart type.
 …
       <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined
       for carrying form data suitable for processing via the POST
       request method, as described in RFC 1867 <xref target="RFC1867"/>.
+      request method, as described in <xref target="RFC1867"/>.
 </t></list></t>
 </section>
 …
 <t>
    The syntax and registry of HTTP language tags is the same as that
    defined by RFC 1766 <xref target="RFC1766"/>. In summary, a language tag is composed of 1
+   defined by <xref target="RFC1766"/>. In summary, a language tag is composed of 1
    or more parts: A primary language tag and a possibly empty series of
    subtags:
 …
   <iref primary="true" item="Headers" subitem="Content-MD5" x:for-anchor=""/>
 <t>
    The Content-MD5 entity-header field, as defined in RFC 1864 <xref target="RFC1864"/>, is
+   The Content-MD5 entity-header field, as defined in <xref target="RFC1864"/>, is
    an MD5 digest of the entity-body for the purpose of providing an
    end-to-end message integrity check (MIC) of the entity-body. (Note: a
 …
 <section title="Content-Disposition Issues" anchor="content-disposition.issues">
 <t>
    RFC 1806 <xref target="RFC1806"/>, from which the often implemented Content-Disposition
+   <xref target="RFC1806"/>, from which the often implemented Content-Disposition
    (see <xref target="content-disposition"/>) 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 RFC 2183 <xref target="RFC2183"/>
    (which updates RFC 1806) for details.
+   documenting its use and risks for implementors. See <xref target="RFC2183"/>
+   (which updates <xref target="RFC1806"/>) for details.
 </t>
 </section>
 …
 <reference anchor="RFC1766">
+<front>
+<title abbrev="Language Tag">Tags for the Identification of Languages</title>
+<author initials="H." surname="Alvestrand" fullname="Harald Tveit Alvestrand">
+<organization>UNINETT</organization>
+<address>
+<postal>
+<street>Pb. 6883 Elgeseter</street>
+<city>Trondheim</city>
+<region/>
+<code>N-7002</code>
+<country>NO</country></postal>
+<phone>+47 73 597094</phone>
+<email>Harald.T.Alvestrand@uninett.no</email></address></author>
+<date month="March" year="1995"/>
+</front>
+<seriesInfo name="RFC" value="1766"/>
+  <front>
+    <title abbrev="Language Tag">Tags for the Identification of Languages</title>
+    <author initials="H." surname="Alvestrand" fullname="Harald Tveit Alvestrand">
+      <organization>UNINETT</organization>
+      <address><email>Harald.T.Alvestrand@uninett.no</email></address>
+    </author>
+    <date month="March" year="1995"/>
+  </front>
+  <seriesInfo name="RFC" value="1766"/>
 </reference>
 <reference anchor="RFC2045">
+<front>
+<title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
+<author initials="N." surname="Freed" fullname="Ned Freed">
+<organization>Innosoft International, Inc.</organization>
+<address>
+<postal>
+<street>1050 East Garvey Avenue South</street>
+<city>West Covina</city>
+<region>CA</region>
+<code>91790</code>
+<country>US</country></postal>
+<phone>+1 818 919 3600</phone>
+<facsimile>+1 818 919 3614</facsimile>
+<email>ned@innosoft.com</email></address></author>
+<author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+<organization>First Virtual Holdings</organization>
+<address>
+<postal>
+<street>25 Washington Avenue</street>
+<city>Morristown</city>
+<region>NJ</region>
+<code>07960</code>
+<country>US</country></postal>
+<phone>+1 201 540 8967</phone>
+<facsimile>+1 201 993 3032</facsimile>
+<email>nsb@nsb.fv.com</email></address></author>
+<date month="November" year="1996"/>
+</front>
+<seriesInfo name="RFC" value="2045"/>
+  <front>
+    <title abbrev="Internet Message Bodies">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
+    <author initials="N." surname="Freed" fullname="Ned Freed">
+      <organization>Innosoft International, Inc.</organization>
+      <address><email>ned@innosoft.com</email></address>
+    </author>
+    <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+      <organization>First Virtual Holdings</organization>
+      <address><email>nsb@nsb.fv.com</email></address>
+    </author>
+    <date month="November" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="2045"/>
 </reference>
 <reference anchor="RFC822">
+<front>
+<title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title>
+<author initials="D.H." surname="Crocker" fullname="David H. Crocker">
+<organization>University of Delaware, Dept. of Electrical Engineering</organization>
+<address>
+<postal>
+<street/>
+<city>Newark</city>
+<region>DE</region>
+<code>19711</code>
+<country>US</country></postal>
+<email>DCrocker@UDel-Relay</email></address></author>
+<date month="August" day="13" year="1982"/></front>
+<seriesInfo name="STD" value="11"/>
+<seriesInfo name="RFC" value="822"/>
+  <front>
+    <title abbrev="Standard for ARPA Internet Text Messages">Standard for the format of ARPA Internet text messages</title>
+    <author initials="D.H." surname="Crocker" fullname="David H. Crocker">
+      <organization>University of Delaware, Dept. of Electrical Engineering</organization>
+      <address><email>DCrocker@UDel-Relay</email></address>
+    </author>
+    <date month="August" day="13" year="1982"/>
+  </front>
+  <seriesInfo name="STD" value="11"/>
+  <seriesInfo name="RFC" value="822"/>
 </reference>
 <reference anchor="RFC1867">
+<front>
+<title>Form-based File Upload in HTML</title>
+<author initials="L." surname="Masinter" fullname="Larry Masinter">
+<organization>Xerox Palo Alto Research Center</organization>
+<address>
+<postal>
+<street>3333 Coyote Hill Road</street>
+<city>Palo Alto</city>
+<region>CA</region>
+<code>94304</code>
+<country>US</country></postal>
+<phone>+1 415 812 4365</phone>
+<facsimile>+1 415 812 4333</facsimile>
+<email>masinter@parc.xerox.com</email></address></author>
+<author initials="E." surname="Nebel" fullname="Ernesto Nebel">
+<organization>XSoft, Xerox Corporation</organization>
+<address>
+<postal>
+<street>10875 Rancho Bernardo Road</street>
+<street>Suite 200</street>
+<city>San Diego</city>
+<region>CA</region>
+<code>92127-2116</code>
+<country>US</country></postal>
+<phone>+1 619 676 7817</phone>
+<facsimile>+1 619 676 7865</facsimile>
+<email>nebel@xsoft.sd.xerox.com</email></address></author>
+<date month="November" year="1995"/>
+</front>
+<seriesInfo name="RFC" value="1867"/>
+  <front>
+    <title>Form-based File Upload in HTML</title>
+    <author initials="L." surname="Masinter" fullname="Larry Masinter">
+      <organization>Xerox Palo Alto Research Center</organization>
+      <address><email>masinter@parc.xerox.com</email></address>
+    </author>
+    <author initials="E." surname="Nebel" fullname="Ernesto Nebel">
+      <organization>XSoft, Xerox Corporation</organization>
+      <address><email>nebel@xsoft.sd.xerox.com</email></address>
+    </author>
+    <date month="November" year="1995"/>
+  </front>
+  <seriesInfo name="RFC" value="1867"/>
 </reference>
 …
 <reference anchor="RFC1864">
+<front>
+<title abbrev="Content-MD5 Header Field">The Content-MD5 Header Field</title>
+<author initials="J." surname="Myers" fullname="John G. Myers">
+<organization>Carnegie Mellon University</organization>
+<address>
+<phone/>
+<email>jgm+@cmu.edu</email></address></author>
+<author initials="M." surname="Rose" fullname="Marshall T. Rose">
+<organization>Dover Beach Consulting, Inc.</organization>
+<address>
+<phone/>
+<email>mrose@dbc.mtview.ca.us</email></address></author>
+<date month="October" year="1995"/>
+</front>
+<seriesInfo name="RFC" value="1864"/>
+</reference>
+  <front>
+    <title abbrev="Content-MD5 Header Field">The Content-MD5 Header Field</title>
+    <author initials="J." surname="Myers" fullname="John G. Myers">
+      <organization>Carnegie Mellon University</organization>
+      <address><email>jgm+@cmu.edu</email></address>
+    </author>
+    <author initials="M." surname="Rose" fullname="Marshall T. Rose">
+      <organization>Dover Beach Consulting, Inc.</organization>
+      <address><email>mrose@dbc.mtview.ca.us</email></address>
+    </author>
+    <date month="October" year="1995"/>
+  </front>
+  <seriesInfo name="RFC" value="1864"/>
+</reference>
 <reference anchor="RFC1952">
+<front>
+<title>GZIP file format specification version 4.3</title>
+<author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">
+<organization>Aladdin Enterprises</organization>
+<address>
+<postal>
+<street>203 Santa Margarita Ave.</street>
+<city>Menlo Park</city>
+<region>CA</region>
+<code>94025</code>
+<country>US</country></postal>
+<phone>+1 415 322 0103</phone>
+<facsimile>+1 415 322 1734</facsimile>
+<email>ghost@aladdin.com</email></address></author>
+<author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly">
+<organization/>
+<address>
+<postal>
+<street/>
+<city/>
+<region/>
+<code/>
+<country/></postal>
+<phone/>
+<email>gzip@prep.ai.mit.edu</email></address></author>
+<author initials="M." surname="Adler" fullname="Mark Adler">
+<organization/>
+<address>
+<postal>
+<street/>
+<city/>
+<region/>
+<code/>
+<country/></postal>
+<phone/>
+<email>madler@alumni.caltech.edu</email></address></author>
+<author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">
+<organization/>
+<address>
+<postal>
+<street/>
+<city/>
+<region/>
+<code/>
+<country/></postal>
+<phone/>
+<email>ghost@aladdin.com</email></address></author>
+<author initials="G." surname="Randers-Pehrson" fullname="Glenn Randers-Pehrson">
+<organization/>
+<address>
+<postal>
+<street/>
+<city/>
+<region/>
+<code/>
+<country/></postal>
+<phone/>
+<email>randeg@alumni.rpi.edu</email></address></author>
+<date month="May" year="1996"/>
+</front>
+<seriesInfo name="RFC" value="1952"/>
+  <front>
+    <title>GZIP file format specification version 4.3</title>
+    <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">
+      <organization>Aladdin Enterprises</organization>
+      <address><email>ghost@aladdin.com</email></address>
+    </author>
+    <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly">
+      <organization/>
+      <address><email>gzip@prep.ai.mit.edu</email></address></author>
+    <author initials="M." surname="Adler" fullname="Mark Adler">
+      <organization/>
+      <address><email>madler@alumni.caltech.edu</email></address></author>
+    <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">
+      <organization/>
+      <address><email>ghost@aladdin.com</email></address>
+    </author>
+    <author initials="G." surname="Randers-Pehrson" fullname="Glenn Randers-Pehrson">
+      <organization/>
+      <address><email>randeg@alumni.rpi.edu</email></address>
+    </author>
+    <date month="May" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="1952"/>
 </reference>
 <reference anchor="RFC1951">
+<front>
+<title>DEFLATE Compressed Data Format Specification version 1.3</title>
+<author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">
+<organization>Aladdin Enterprises</organization>
+<address>
+<postal>
+<street>203 Santa Margarita Ave.</street>
+<city>Menlo Park</city>
+<region>CA</region>
+<code>94025</code>
+<country>US</country></postal>
+<phone>+1 415 322 0103</phone>
+<facsimile>+1 415 322 1734</facsimile>
+<email>ghost@aladdin.com</email></address></author>
+<date month="May" year="1996"/>
+<abstract>
+<t>This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.  The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage.  The format can be implemented readily in a manner not covered by patents.</t></abstract></front>
+<seriesInfo name="RFC" value="1951"/>
+  <front>
+    <title>DEFLATE Compressed Data Format Specification version 1.3</title>
+    <author initials="P." surname="Deutsch" fullname="L. Peter Deutsch">
+      <organization>Aladdin Enterprises</organization>
+      <address><email>ghost@aladdin.com</email></address>
+    </author>
+    <date month="May" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="1951"/>
 </reference>
 <reference anchor="RFC1950">
+<front>
+<title>ZLIB Compressed Data Format Specification version 3.3</title>
+<author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">
+<organization>Aladdin Enterprises</organization>
+<address>
+<postal>
+<street>203 Santa Margarita Ave.</street>
+<city>Menlo Park</city>
+<region>CA</region>
+<code>94025</code>
+<country>US</country></postal>
+<phone>+1 415 322 0103</phone>
+<facsimile>+1 415 322 1734</facsimile>
+<email>ghost@aladdin.com</email></address></author>
+<author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly">
+<organization/></author>
+<date month="May" year="1996"/>
+<abstract>
+<t>This specification defines a lossless compressed data format.  The data can be produced or consumed, even for an arbitrarily long sequentially presented input data stream, using only an a priori bounded amount of intermediate storage.  The format presently uses the DEFLATE compression method but can be easily extended to use
+   other compression methods.  It can be implemented readily in a manner not covered by patents.  This specification also defines the ADLER-32 checksum (an extension and improvement of the Fletcher checksum), used for detection of data corruption, and provides an algorithm for computing it.</t></abstract></front>
+<seriesInfo name="RFC" value="1950"/>
+  <front>
+    <title>ZLIB Compressed Data Format Specification version 3.3</title>
+    <author initials="L.P." surname="Deutsch" fullname="L. Peter Deutsch">
+      <organization>Aladdin Enterprises</organization>
+      <address><email>ghost@aladdin.com</email></address>
+    </author>
+    <author initials="J-L." surname="Gailly" fullname="Jean-Loup Gailly">
+      <organization/>
+    </author>
+    <date month="May" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="1950"/>
 </reference>
 <reference anchor="RFC2068">
+<front>
+<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
+<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
+<organization>University of California, Irvine, Department of Information and Computer Science</organization>
+<address>
+<postal>
+<street/>
+<city>Irvine</city>
+<region>CA</region>
+<code>92717-3425</code>
+<country>US</country></postal>
+<facsimile>+1 714 824 4056</facsimile>
+<email>fielding@ics.uci.edu</email></address></author>
+<author initials="J." surname="Gettys" fullname="Jim Gettys">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>jg@w3.org</email></address></author>
+<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+<organization>Digital Equipment Corporation, Western Research Laboratory</organization>
+<address>
+<postal>
+<street>250 University Avenue</street>
+<city>Palo Alto</city>
+<region>CA</region>
+<code>94301</code>
+<country>US</country></postal>
+<email>mogul@wrl.dec.com</email></address></author>
+<author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>frystyk@w3.org</email></address></author>
+<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>timbl@w3.org</email></address></author>
+<date month="January" year="1997"/>
+<abstract>
+<t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t>
+<t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".</t></abstract></front>
+<seriesInfo name="RFC" value="2068"/>
+  <front>
+    <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
+    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
+      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
+      <address><email>fielding@ics.uci.edu</email></address>
+    </author>
+    <author initials="J." surname="Gettys" fullname="Jim Gettys">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>jg@w3.org</email></address>
+    </author>
+    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+      <organization>Digital Equipment Corporation, Western Research Laboratory</organization>
+      <address><email>mogul@wrl.dec.com</email></address>
+    </author>
+    <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>frystyk@w3.org</email></address>
+    </author>
+    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>timbl@w3.org</email></address>
+    </author>
+    <date month="January" year="1997"/>
+  </front>
+  <seriesInfo name="RFC" value="2068"/>
 </reference>
 <reference anchor="RFC1806">
+<front>
+<title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header</title>
+<author initials="R." surname="Troost" fullname="Rens Troost">
+<organization>New Century Systems</organization>
+<address>
+<postal>
+<street>324 East 41st Street #804</street>
+<city>New York</city>
+<region>NY</region>
+<code>10017</code>
+<country>US</country></postal>
+<phone>+1 212 557 2050</phone>
+<facsimile>+1 212 557 2049</facsimile>
+<email>rens@century.com</email></address></author>
+<author initials="S." surname="Dorner" fullname="Steve Dorner">
+<organization>QUALCOMM Incorporated</organization>
+<address>
+<postal>
+<street>6455 Lusk Boulevard</street>
+<city>San Diego</city>
+<region>CA</region>
+<code>92121</code>
+<country>US</country></postal>
+<email>sdorner@qualcomm.com</email></address></author>
+<date month="June" year="1995"/>
+<abstract>
+<t>This memo provides a mechanism whereby messages conforming to the("MIME") specification can convey presentational information.  It specifies a new "Content-Disposition" header, optional and valid for anyentity ("message" or "body part"). Two values for this header are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.</t>
+<t>This document is intended as an extension to. As such, the reader is assumed to be familiar with, and. The information presented herein supplements but does not replace that found in those documents.</t></abstract></front>
+<seriesInfo name="RFC" value="1806"/>
+  <front>
+    <title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header</title>
+    <author initials="R." surname="Troost" fullname="Rens Troost">
+      <organization>New Century Systems</organization>
+      <address><email>rens@century.com</email></address>
+    </author>
+    <author initials="S." surname="Dorner" fullname="Steve Dorner">
+      <organization>QUALCOMM Incorporated</organization>
+      <address><email>sdorner@qualcomm.com</email></address>
+    </author>
+    <date month="June" year="1995"/>
+  </front>
+  <seriesInfo name="RFC" value="1806"/>
+</reference>
+<reference anchor="RFC1945">
+  <front>
+    <title abbrev="HTTP/1.0">Hypertext Transfer Protocol -- HTTP/1.0</title>
+    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+      <organization>MIT, Laboratory for Computer Science</organization>
+      <address><email>timbl@w3.org</email></address>
+    </author>
+    <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
+      <address><email>fielding@ics.uci.edu</email></address>
+    </author>
+    <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+      <organization>W3 Consortium, MIT Laboratory for Computer Science</organization>
+      <address><email>frystyk@w3.org</email></address>
+    </author>
+    <date month="May" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="1945"/>
 </reference>
 <reference anchor="RFC2076">
+<front>
+<title abbrev="Internet Message Headers">Common Internet Message Headers</title>
+<author initials="J." surname="Palme" fullname="Jacob Palme">
+<organization>Stockholm University/KTH</organization>
+<address>
+<postal>
+<street>Electrum 230</street>
+<street>S-164 40 Kista</street>
+<country>SE</country></postal>
+<phone>+46 8 161667</phone>
+<facsimile>+46 8 7830829</facsimile>
+<email>jpalme@dsv.su.se</email></address></author>
+<date month="February" year="1997"/>
+<abstract>
+<t>This memo contains a table of commonly occurring headers in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, RFC 1806, RFC 1864 and RFC 1911. A few commonly occurring headers which are not defined in RFCs are also included. For each header, the memo gives a short description and a reference to the RFC in which the header is defined.</t></abstract></front>
+<seriesInfo name="RFC" value="2076"/>
+  <front>
+    <title abbrev="Internet Message Headers">Common Internet Message Headers</title>
+    <author initials="J." surname="Palme" fullname="Jacob Palme">
+      <organization>Stockholm University/KTH</organization>
+      <address><email>jpalme@dsv.su.se</email></address>
+    </author>
+    <date month="February" year="1997"/>
+  </front>
+  <seriesInfo name="RFC" value="2076"/>
 </reference>
 …
 <reference anchor="RFC2046">
+<front>
+<title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
+<author initials="N." surname="Freed" fullname="Ned Freed">
+<organization>Innosoft International, Inc.</organization>
+<address>
+<postal>
+<street>1050 East Garvey Avenue South</street>
+<city>West Covina</city>
+<region>CA</region>
+<code>91790</code>
+<country>US</country></postal>
+<phone>+1 818 919 3600</phone>
+<facsimile>+1 818 919 3614</facsimile>
+<email>ned@innosoft.com</email></address></author>
+<author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+<organization>First Virtual Holdings</organization>
+<address>
+<postal>
+<street>25 Washington Avenue</street>
+<city>Morristown</city>
+<region>NJ</region>
+<code>07960</code>
+<country>US</country></postal>
+<phone>+1 201 540 8967</phone>
+<facsimile>+1 201 993 3032</facsimile>
+<email>nsb@nsb.fv.com</email></address></author>
+<date month="November" year="1996"/>
+</front>
+<seriesInfo name="RFC" value="2046"/>
+  <front>
+    <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
+    <author initials="N." surname="Freed" fullname="Ned Freed">
+      <organization>Innosoft International, Inc.</organization>
+      <address><email>ned@innosoft.com</email></address>
+    </author>
+    <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+      <organization>First Virtual Holdings</organization>
+      <address><email>nsb@nsb.fv.com</email></address>
+    </author>
+    <date month="November" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="2046"/>
 </reference>
 …
 <reference anchor="RFC2049">
+<front>
+<title abbrev="MIME Conformance">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</title>
+<author initials="N." surname="Freed" fullname="Ned Freed">
+<organization>Innosoft International, Inc.</organization>
+<address>
+<postal>
+<street>1050 East Garvey Avenue South</street>
+<street>West Covina</street>
+<street>CA 91790</street>
+<country>USA</country></postal>
+<phone>+1 818 919 3600</phone>
+<facsimile>+1 818 919 3614</facsimile>
+<email>ned@innosoft.com</email></address></author>
+<author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+<organization>First Virtual Holdings</organization>
+<address>
+<postal>
+<street>25 Washington Avenue</street>
+<street>Morristown</street>
+<street>NJ 07960</street>
+<country>USA</country></postal>
+<phone>+1 201 540 8967</phone>
+<facsimile>+1 201 993 3032</facsimile>
+<email>nsb@nsb.fv.com</email></address></author>
+<date month="November" year="1996"/>
+<area>Applications</area>
+<keyword>mail</keyword>
+<keyword>multipurpose internet mail extensions</keyword>
+</front>
+<seriesInfo name="RFC" value="2049"/>
+  <front>
+    <title abbrev="MIME Conformance">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</title>
+    <author initials="N." surname="Freed" fullname="Ned Freed">
+      <organization>Innosoft International, Inc.</organization>
+      <address><email>ned@innosoft.com</email></address>
+    </author>
+    <author initials="N.S." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+      <organization>First Virtual Holdings</organization>
+      <address><email>nsb@nsb.fv.com</email></address>
+    </author>
+    <date month="November" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="2049"/>
 </reference>
 <reference anchor="RFC2183">
+<front>
+<title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</title>
+<author initials="R." surname="Troost" fullname="Rens Troost">
+<organization>New Century Systems</organization>
+<address>
+<postal>
+<street>324 East 41st Street #804</street>
+<street>New York</street>
+<street>NY</street>
+<street>10017</street>
+<country>USA</country></postal>
+<phone>+1 (212) 557-2050</phone>
+<facsimile>+1 (212) 557-2049</facsimile>
+<email>rens@century.com</email></address></author>
+<author initials="S." surname="Dorner" fullname="Steve Dorner">
+<organization>QUALCOMM Incorporated</organization>
+<address>
+<postal>
+<street>6455 Lusk Boulevard</street>
+<street>San Diego</street>
+<street>CA 92121</street>
+<country>USA</country></postal>
+<email>sdorner@qualcomm.com</email></address></author>
+<author initials="K." surname="Moore" fullname="Keith Moore">
+<organization>Department of Computer Science</organization>
+<address>
+<postal>
+<street>University of Tennessee</street>
+<street>Knoxville</street>
+<street>107 Ayres Hall</street>
+<street>Knoxville TN  37996-1301</street>
+<country>USA</country></postal>
+<phone>+1 (423) 974-5067</phone>
+<facsimile>+1 (423) 974-8296</facsimile>
+<email>moore@cs.utk.edu</email></address></author>
+<date month="August" year="1997"/>
+<area>Applications</area>
+<keyword>MIME</keyword>
+<keyword>internet message</keyword>
+<keyword>multipurpose internet mail extensions</keyword>
+</front>
+<seriesInfo name="RFC" value="2183"/>
+  <front>
+    <title abbrev="Content-Disposition">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</title>
+    <author initials="R." surname="Troost" fullname="Rens Troost">
+      <organization>New Century Systems</organization>
+      <address><email>rens@century.com</email></address>
+    </author>
+    <author initials="S." surname="Dorner" fullname="Steve Dorner">
+      <organization>QUALCOMM Incorporated</organization>
+      <address><email>sdorner@qualcomm.com</email></address>
+    </author>
+    <author initials="K." surname="Moore" fullname="Keith Moore">
+      <organization>Department of Computer Science</organization>
+      <address><email>moore@cs.utk.edu</email></address>
+    </author>
+    <date month="August" year="1997"/>
+  </front>
+  <seriesInfo name="RFC" value="2183"/>
 </reference>
 …
 <section title="Differences Between HTTP Entities and RFC 2045 Entities" anchor="differences.between.http.entities.and.rfc.2045.entities">
 <t>
+   HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
+<xref target="RFC822"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to
+   HTTP/1.1 uses many of the constructs defined for Internet Mail (<xref target="RFC822"/>) and the Multipurpose Internet Mail Extensions (MIME <xref target="RFC2045"/>) to
    allow entities to be transmitted in an open variety of
    representations and with extensible mechanisms. However, RFC 2045
 …
 <section title="Conversion to Canonical Form" anchor="conversion.to.canonical.form">
 <t>
    RFC 2045 <xref target="RFC2045"/> requires that an Internet mail entity be converted to
    canonical form prior to being transferred, as described in section <xref target="RFC2049" x:fmt="number" x:sec="4"/>
    of RFC 2049 <xref target="RFC2049"/>. <xref target="canonicalization.and.text.defaults"/> of this document describes the forms
+   <xref target="RFC2045"/> requires that an Internet mail entity be converted to
+   canonical form prior to being transferred, as described in section <xref target="RFC2049" x:fmt="of" x:sec="4"/>.
+   <xref target="canonicalization.and.text.defaults"/> of this document describes the forms
    allowed for subtypes of the "text" media type when transmitted over
    HTTP. RFC 2046 requires that content with a type of "text" represent
+   HTTP. <xref target="RFC2046"/> requires that content with a type of "text" represent
    line breaks as CRLF and forbids the use of CR or LF outside of line
    break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
 …
 <section title="Additional Features" anchor="additional.features">
 <t>
    RFC 1945 and RFC 2068 document protocol elements used by some
+   <xref target="RFC1945"/> and <xref target="RFC2068"/> document protocol elements used by some
    existing HTTP implementations, but not consistently and correctly
    across most HTTP/1.1 applications. Implementors are advised to be
 …
 <t>
    A number of other headers, such as Content-Disposition and Title,
    from SMTP and MIME are also often implemented (see RFC 2076 <xref target="RFC2076"/>).
+   from SMTP and MIME are also often implemented (see <xref target="RFC2076"/>).
 </t>
 …
    means for the origin server to suggest a default filename if the user
    requests that the content is saved to a file. This usage is derived
    from the definition of Content-Disposition in RFC 1806 <xref target="RFC1806"/>.
+   from the definition of Content-Disposition in <xref target="RFC1806"/>.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="content-disposition"/><iref primary="true" item="Grammar" subitem="disposition-type"/><iref primary="true" item="Grammar" subitem="disposition-parm"/><iref primary="true" item="Grammar" subitem="filename-parm"/><iref primary="true" item="Grammar" subitem="disp-extension-token"/><iref primary="true" item="Grammar" subitem="disp-extension-parm"/>
 …
    The Alternates<iref item="Alternates header" primary="true"/><iref item="Headers" subitem="Alternate" primary="true"/>, Content-Version<iref item="Content-Version header" primary="true"/><iref item="Headers" subitem="Content-Version" primary="true"/>, Derived-From<iref item="Derived-From header" primary="true"/><iref item="Headers" subitem="Derived-From" primary="true"/>, Link<iref item="Link header" primary="true"/><iref item="Headers" subitem="Link" primary="true"/>, URI<iref item="URI header" primary="true"/><iref item="Headers" subitem="URI" primary="true"/>, Public<iref item="Public header" primary="true"/><iref item="Headers" subitem="Public" primary="true"/> and
    Content-Base<iref item="Content-Base header" primary="true"/><iref item="Headers" subitem="Content-Base" primary="true"/> header fields were defined in previous versions of this
    specification, but not commonly implemented. See RFC 2068 <xref target="RFC2068"/>.
+   specification, but not commonly implemented. See <xref target="RFC2068"/>.
 </t>
 </section>

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

-                      r96
+                      r97
       </ul>
       <p id="rfc.section.3.1.p.3">If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without
          one (as already specified by <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, section <a href="http://tools.ietf.org/html/rfc2068#section-14.19" id="rfc.xref.RFC2068.2">14.19</a>), caches will operate correctly.
+         one (as already specified by <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-14.19">Section 14.19</a>), caches will operate correctly.
       </p>
       <ul>
 …
       <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 for the requested variant. The headers used with
          entity tags are described in sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a>, <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> and <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
+         entity tags are described in Sections <a href="#header.if-match" id="rfc.xref.header.if-match.2" title="If-Match">6.2</a>, <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">6.4</a> and <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>. The entity tag <em class="bcp14">MAY</em> be used for comparison with other entities from the same resource (see <a href="#weak.and.strong.validators" title="Weak and Strong Validators">Section&nbsp;4</a>).
       </p>
       <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.4"></span>    ETag = "ETag" ":" entity-tag
 …
             </li>
             <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind">
                   <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#rfc.xref.RFC2068.2">3.1</a>, <a class="iref" href="#RFC2068"><b>10</b></a><ul class="ind">
                         <li class="indline1"><em>Section 14.19</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.2">3.1</a></li>
+                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">3.1</a>, <a class="iref" href="#RFC2068"><b>10</b></a><ul class="ind">
+                        <li class="indline1"><em>Section 14.19</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">3.1</a></li>
                      </ul>
                   </li>

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

-                      r96
+                      r97
    If a clockless origin server obeys these rules, and proxies and
    clients add their own Date to any response received without one (as
    already specified by <xref target="RFC2068" />, section <xref target="RFC2068" x:sec="14.19" x:fmt="number"/>), caches will operate
+   already specified by <xref target="RFC2068" x:sec="14.19" x:fmt=","/>), caches will operate
    correctly.
   <list style="symbols">
 …
    The ETag response-header field provides the current value of the
    entity tag for the requested variant. The headers used with entity
    tags are described in sections <xref target="header.if-match" format="counter"/>, <xref target="header.if-none-match" format="counter"/> and &header-if-range;. The entity tag
+   tags are described in Sections <xref target="header.if-match" format="counter"/>, <xref target="header.if-none-match" format="counter"/> and &header-if-range;. The entity tag
    &MAY; be used for comparison with other entities from the same resource
    (see <xref target="weak.and.strong.validators"/>).
 …
 <reference anchor="RFC2068">
+<front>
+<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
+<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
+<organization>University of California, Irvine, Department of Information and Computer Science</organization>
+<address>
+<postal>
+<street/>
+<city>Irvine</city>
+<region>CA</region>
+<code>92717-3425</code>
+<country>US</country></postal>
+<facsimile>+1 714 824 4056</facsimile>
+<email>fielding@ics.uci.edu</email></address></author>
+<author initials="J." surname="Gettys" fullname="Jim Gettys">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>jg@w3.org</email></address></author>
+<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+<organization>Digital Equipment Corporation, Western Research Laboratory</organization>
+<address>
+<postal>
+<street>250 University Avenue</street>
+<city>Palo Alto</city>
+<region>CA</region>
+<code>94301</code>
+<country>US</country></postal>
+<email>mogul@wrl.dec.com</email></address></author>
+<author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>frystyk@w3.org</email></address></author>
+<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+<organization>MIT Laboratory for Computer Science</organization>
+<address>
+<postal>
+<street>545 Technology Square</street>
+<city>Cambridge</city>
+<region>MA</region>
+<code>02139</code>
+<country>US</country></postal>
+<facsimile>+1 617 258 8682</facsimile>
+<email>timbl@w3.org</email></address></author>
+<date month="January" year="1997"/>
+<abstract>
+<t>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.</t>
+<t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".</t></abstract></front>
+<seriesInfo name="RFC" value="2068"/>
+  <front>
+    <title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
+    <author initials="R." surname="Fielding" fullname="Roy T. Fielding">
+      <organization>University of California, Irvine, Department of Information and Computer Science</organization>
+      <address><email>fielding@ics.uci.edu</email></address>
+    </author>
+    <author initials="J." surname="Gettys" fullname="Jim Gettys">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>jg@w3.org</email></address>
+    </author>
+    <author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
+      <organization>Digital Equipment Corporation, Western Research Laboratory</organization>
+      <address><email>mogul@wrl.dec.com</email></address>
+    </author>
+    <author initials="H." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>frystyk@w3.org</email></address>
+    </author>
+    <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+      <organization>MIT Laboratory for Computer Science</organization>
+      <address><email>timbl@w3.org</email></address>
+    </author>
+    <date month="January" year="1997"/>
+  </front>
+  <seriesInfo name="RFC" value="2068"/>
 </reference>

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

r96	r97
864	864	<ol>
865	865	<li>Additional CRLFs may precede the first boundary string in the entity.</li>
866		<li>Although ~~RFC 2046~~ <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly.
	866	<li>Although <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly.
867	867	</li>
868	868	<li>A number of browsers and servers were coded to an early draft of the byteranges specification to use a media type of multipart/x-byteranges<span id="rfc.iref.m.3"></span><span id="rfc.iref.m.4"></span>, which is almost, but not quite compatible with the version documented in HTTP/1.1.

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

-                      r96
+                      r97
 <reference anchor="RFC2046">
+<front>
+<title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
+<author initials="N." surname="Freed" fullname="Ned Freed">
+<organization>Innosoft International, Inc.</organization>
+<address>
+<postal>
+<street>1050 East Garvey Avenue South</street>
+<city>West Covina</city>
+<region>CA</region>
+<code>91790</code>
+<country>US</country></postal>
+<phone>+1 818 919 3600</phone>
+<facsimile>+1 818 919 3614</facsimile>
+<email>ned@innosoft.com</email></address></author>
+<author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+<organization>First Virtual Holdings</organization>
+<address>
+<postal>
+<street>25 Washington Avenue</street>
+<city>Morristown</city>
+<region>NJ</region>
+<code>07960</code>
+<country>US</country></postal>
+<phone>+1 201 540 8967</phone>
+<facsimile>+1 201 993 3032</facsimile>
+<email>nsb@nsb.fv.com</email></address></author>
+<date month="November" year="1996"/>
+</front>
+<seriesInfo name="RFC" value="2046"/>
+  <front>
+    <title abbrev="Media Types">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
+    <author initials="N." surname="Freed" fullname="Ned Freed">
+      <organization>Innosoft International, Inc.</organization>
+      <address><email>ned@innosoft.com</email></address>
+    </author>
+    <author initials="N." surname="Borenstein" fullname="Nathaniel S. Borenstein">
+      <organization>First Virtual Holdings</organization>
+      <address><email>nsb@nsb.fv.com</email></address>
+    </author>
+    <date month="November" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="2046"/>
 </reference>
 …
          entity.</t>
       <t>Although RFC 2046 <xref target="RFC2046"/> permits the boundary string to be
+      <t>Although <xref target="RFC2046"/> permits the boundary string to be
          quoted, some existing implementations handle a quoted boundary
          string incorrectly.</t>

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

-                      r96
+                      r97
       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
       <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to caching response messages. Right now it only includes the extracted relevant
          sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.2">[RFC2616]</cite> without edit.
+         sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.2">RFC 2616</cite> without edit.
       </p>
       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
 …
       </dl>
       <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="cache.correctness" href="#cache.correctness">Cache Correctness</a></h3>
       <p id="rfc.section.2.1.1.p.1">A correct cache <em class="bcp14">MUST</em> respond to a request with the most up-to-date response held by the cache that is appropriate to the request (see sections <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">2.2.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">2.2.6</a>, and <a href="#cache.replacement" title="Cache Replacement">2.12</a>) which meets one of the following conditions:
+      <p id="rfc.section.2.1.1.p.1">A correct cache <em class="bcp14">MUST</em> respond to a request with the most up-to-date response held by the cache that is appropriate to the request (see Sections <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">2.2.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">2.2.6</a>, and <a href="#cache.replacement" title="Cache Replacement">2.12</a>) which meets one of the following conditions:
       </p>
       <ol>
 …
             cache (see <a href="#header.cache-control" id="rfc.xref.header.cache-control.1" title="Cache-Control">Section&nbsp;3.2</a>); if the origin server so specifies, it is the freshness requirement of the origin server alone. If a stored response is
             not "fresh enough" by the most restrictive freshness requirement of both the client and the origin server, in carefully considered
             circumstances the cache <em class="bcp14">MAY</em> still return the response with the appropriate Warning header (see section <a href="#exceptions.to.the.rules.and.warnings" title="Exceptions to the Rules and Warnings">2.1.5</a> and <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">3.6</a>), unless such a response is prohibited (e.g., by a "no-store" cache-directive, or by a "no-cache" cache-request-directive;
+            circumstances the cache <em class="bcp14">MAY</em> still return the response with the appropriate Warning header (see Sections <a href="#exceptions.to.the.rules.and.warnings" title="Exceptions to the Rules and Warnings">2.1.5</a> and <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">3.6</a>), unless such a response is prohibited (e.g., by a "no-store" cache-directive, or by a "no-cache" cache-request-directive;
             see <a href="#header.cache-control" id="rfc.xref.header.cache-control.2" title="Cache-Control">Section&nbsp;3.2</a>).
          </li>
 …
       </p>
       <h2 id="rfc.section.2.12"><a href="#rfc.section.2.12">2.12</a>&nbsp;<a id="cache.replacement" href="#cache.replacement">Cache Replacement</a></h2>
       <p id="rfc.section.2.12.p.1">If a new cacheable (see sections <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">3.2.2</a>, <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">2.2.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">2.2.6</a> and <a href="#errors.or.incomplete.response.cache.behavior" title="Errors or Incomplete Response Cache Behavior">2.8</a>) response is received from a resource while any existing responses for the same resource are cached, the cache <em class="bcp14">SHOULD</em> use the new response to reply to the current request. It <em class="bcp14">MAY</em> insert it into cache storage and <em class="bcp14">MAY</em>, if it meets all other requirements, use it to respond to any future requests that would previously have caused the old response
+      <p id="rfc.section.2.12.p.1">If a new cacheable (see Sections <a href="#what.may.be.stored.by.caches" title="What May be Stored by Caches">3.2.2</a>, <a href="#disambiguating.expiration.values" title="Disambiguating Expiration Values">2.2.5</a>, <a href="#disambiguating.multiple.responses" title="Disambiguating Multiple Responses">2.2.6</a> and <a href="#errors.or.incomplete.response.cache.behavior" title="Errors or Incomplete Response Cache Behavior">2.8</a>) response is received from a resource while any existing responses for the same resource are cached, the cache <em class="bcp14">SHOULD</em> use the new response to reply to the current request. It <em class="bcp14">MAY</em> insert it into cache storage and <em class="bcp14">MAY</em>, if it meets all other requirements, use it to respond to any future requests that would previously have caused the old response
          to be returned. If it inserts the new response into cache storage the rules in <a href="#combining.headers" title="Combining Headers">Section&nbsp;2.5.3</a> apply.
       </p>
 …
          Content-Language field in a response, etc. The default language is English and the default character set is ISO-8859-1.
       </p>
       <p id="rfc.section.3.6.p.6">If a character set other than ISO-8859-1 is used, it <em class="bcp14">MUST</em> be encoded in the warn-text using the method described in RFC 2047 <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.
+      <p id="rfc.section.3.6.p.6">If a character set other than ISO-8859-1 is used, it <em class="bcp14">MUST</em> be encoded in the warn-text using the method described in <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.
       </p>
       <p id="rfc.section.3.6.p.7">Warning headers can in general be applied to any message, however some specific warn-codes are specific to caches and can

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

-                      r96
+                      r97
    This document will define aspects of HTTP related to caching response
    messages.  Right now it only includes the extracted relevant sections
    of <xref target="RFC2616">RFC 2616</xref> without edit.
+   of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> without edit.
 </t>
 …
    A correct cache &MUST; respond to a request with the most up-to-date
    response held by the cache that is appropriate to the request (see
    sections <xref target="disambiguating.expiration.values" format="counter"/>,
+   Sections <xref target="disambiguating.expiration.values" format="counter"/>,
    <xref target="disambiguating.multiple.responses" format="counter"/>,
    and <xref target="cache.replacement" format="counter"/>) which meets one of the following
 …
          origin server, in carefully considered circumstances the cache
          &MAY; still return the response with the appropriate Warning
          header (see section <xref target="exceptions.to.the.rules.and.warnings" format="counter"/>
+         header (see Sections <xref target="exceptions.to.the.rules.and.warnings" format="counter"/>
          and <xref target="header.warning" format="counter"/>), unless such a response
          is prohibited (e.g., by a "no-store" cache-directive, or by a
 …
 <section title="Cache Replacement" anchor="cache.replacement">
 <t>
    If a new cacheable (see sections <xref target="what.may.be.stored.by.caches" format="counter"/>,
+   If a new cacheable (see Sections <xref target="what.may.be.stored.by.caches" format="counter"/>,
    <xref target="disambiguating.expiration.values" format="counter"/>,
    <xref target="disambiguating.multiple.responses" format="counter"/>
 …
 <t>
    If a character set other than ISO-8859-1 is used, it &MUST; be encoded
    in the warn-text using the method described in RFC 2047 <xref target="RFC2047"/>.
+   in the warn-text using the method described in <xref target="RFC2047"/>.
 </t>
 <t>
 …
 <reference anchor="RFC2047">
+<front>
+<title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
+<author initials="K." surname="Moore" fullname="Keith Moore">
+<organization>University of Tennessee</organization>
+<address>
+<postal>
+<street>107 Ayres Hall</street>
+<street>Knoxville TN 37996-1301</street></postal>
+<email>moore@cs.utk.edu</email></address></author>
+<date month="November" year="1996"/>
+<area>Applications</area>
+<keyword>Amercian Standard Code for Information Interchange</keyword>
+<keyword>mail</keyword>
+<keyword>multipurpose internet mail extensions</keyword>
+</front>
+<seriesInfo name="RFC" value="2047"/>
+  <front>
+    <title abbrev="Message Header Extensions">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
+    <author initials="K." surname="Moore" fullname="Keith Moore">
+      <organization>University of Tennessee</organization>
+      <address><email>moore@cs.utk.edu</email></address>
+    </author>
+    <date month="November" year="1996"/>
+  </front>
+  <seriesInfo name="RFC" value="2047"/>
 </reference>

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

r96	r97
510	510	<h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1>
511	511	<p id="rfc.section.1.p.1">This document will define aspects of HTTP related to access control and authentication. Right now it only includes the extracted
512		relevant sections of <~~a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.2">[RFC2616]~~</cite> with only minor edits.
	512	relevant sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.2">RFC 2616</cite> with only minor edits.
513	513	</p>
514	514	<p id="rfc.section.1.p.2">HTTP provides several <em class="bcp14">OPTIONAL</em> challenge-response authentication mechanisms which can be used by a server to challenge a client request and by a client to

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

r96	r97
210	210	This document will define aspects of HTTP related to access control and
211	211	authentication. Right now it only includes the extracted relevant sections
212		of <xref target="RFC2616">RFC 2616</xref> with only minor edits.
	212	of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> with only minor edits.
213	213	</t>
214	214	<t>

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 97

Legend:

Download in other formats: