Ignore:
Timestamp:
12/03/12 05:00:28 (9 years ago)
Author:
fielding@…
Message:

Move the IANA registry definitions to IANA considerations and
make them a bit more readable. Add responsible party and
expected versions to the HTTP token registration.

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r1583 r1584  
    696696                  </ul>
    697697               </li>
    698                <li>4.3&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a></li>
    699                <li>4.4&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a><ul>
    700                      <li>4.4.1&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li>
     698               <li>4.3&nbsp;&nbsp;&nbsp;<a href="#header.te">TE</a><ul>
     699                     <li>4.3.1&nbsp;&nbsp;&nbsp;<a href="#quality.values">Quality Values</a></li>
    701700                  </ul>
    702701               </li>
    703                <li>4.5&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
     702               <li>4.4&nbsp;&nbsp;&nbsp;<a href="#header.trailer">Trailer</a></li>
    704703            </ul>
    705704         </li>
    … …  
    739738                  </ul>
    740739               </li>
    741                <li>6.5&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a><ul>
    742                      <li>6.5.1&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
    743                   </ul>
    744                </li>
     740               <li>6.5&nbsp;&nbsp;&nbsp;<a href="#header.upgrade">Upgrade</a></li>
    745741            </ul>
    746742         </li>
    … …  
    753749                  </ul>
    754750               </li>
    755                <li>7.4&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Transfer Coding Registry</a></li>
    756                <li>7.5&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registration">Upgrade Token Registration</a></li>
     751               <li>7.4&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registry">Transfer Coding Registry</a></li>
     752               <li>7.5&nbsp;&nbsp;&nbsp;<a href="#transfer.coding.registration">Transfer Coding Registrations</a></li>
     753               <li>7.6&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registry">Upgrade Token Registry</a></li>
     754               <li>7.7&nbsp;&nbsp;&nbsp;<a href="#upgrade.token.registration">Upgrade Token Registration</a></li>
    757755            </ul>
    758756         </li>
    … …  
    16321630  <a href="#rule.parameter" class="smpl">attribute</a>          = <a href="#rule.token.separators" class="smpl">token</a>
    16331631  <a href="#rule.parameter" class="smpl">value</a>              = <a href="#rule.token.separators" class="smpl">word</a>
    1634 </pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;4.4</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>).
     1632</pre><p id="rfc.section.4.p.5">All transfer-coding values are case-insensitive. The HTTP Transfer Coding registry is defined in <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;7.4</a>. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;4.3</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;3.3.1</a>).
    16351633      </p>
    16361634      <div id="rfc.iref.c.7"></div>
    … …  
    16641662      </p>
    16651663      <p id="rfc.section.4.1.p.4">The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field
    1666          can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;4.5</a>).
     1664         can be used to indicate which header fields are included in a trailer (see <a href="#header.trailer" id="rfc.xref.header.trailer.1" title="Trailer">Section&nbsp;4.4</a>).
    16671665      </p>
    16681666      <p id="rfc.section.4.1.p.5">A server using chunked transfer-coding in a response <em class="bcp14">MUST NOT</em> use the trailer for any header fields unless at least one of the following is true:
    … …  
    16701668      <ol>
    16711669         <li>the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as
    1672             described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;4.4</a>; or,
     1670            described in <a href="#header.te" id="rfc.xref.header.te.2" title="TE">Section&nbsp;4.3</a>; or,
    16731671         </li>
    16741672         <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable
    … …  
    17331731      <p id="rfc.section.4.2.3.p.1">The "gzip" format is 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.
    17341732      </p>
    1735       <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h2>
    1736       <p id="rfc.section.4.3.p.1">The HTTP Transfer Coding Registry defines the name space for the transfer coding names.</p>
    1737       <p id="rfc.section.4.3.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
    1738       </p>
    1739       <ul>
    1740          <li>Name</li>
    1741          <li>Description</li>
    1742          <li>Pointer to specification text</li>
    1743       </ul>
    1744       <p id="rfc.section.4.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>).
    1745       </p>
    1746       <p id="rfc.section.4.3.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
    1747       </p>
    1748       <p id="rfc.section.4.3.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
    1749       </p>
    17501733      <div id="rfc.iref.t.5"></div>
    17511734      <div id="rfc.iref.h.8"></div>
    1752       <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
    1753       <p id="rfc.section.4.4.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether
     1735      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="header.te" href="#header.te">TE</a></h2>
     1736      <p id="rfc.section.4.3.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether
    17541737         or not it is willing to accept trailer fields in a chunked transfer-coding.
    17551738      </p>
    1756       <p id="rfc.section.4.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
     1739      <p id="rfc.section.4.3.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional
    17571740         accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    17581741      </p>
    … …  
    17611744  <a href="#header.te" class="smpl">te-params</a> = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> "q=" <a href="#quality.values" class="smpl">qvalue</a> *( <a href="#header.te" class="smpl">te-ext</a> )
    17621745  <a href="#header.te" class="smpl">te-ext</a>    = <a href="#rule.whitespace" class="smpl">OWS</a> ";" <a href="#rule.whitespace" class="smpl">OWS</a> <a href="#rule.token.separators" class="smpl">token</a> [ "=" <a href="#rule.token.separators" class="smpl">word</a> ]
    1763 </pre><p id="rfc.section.4.4.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
     1746</pre><p id="rfc.section.4.3.p.4">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
    17641747         as defined in <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
    17651748      </p>
    1766       <p id="rfc.section.4.4.p.5">Examples of its use are:</p>
     1749      <p id="rfc.section.4.3.p.5">Examples of its use are:</p>
    17671750      <div id="rfc.figure.u.42"></div><pre class="text">  TE: deflate
    17681751  TE:
    17691752  TE: trailers, deflate;q=0.5
    1770 </pre><p id="rfc.section.4.4.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;6.1</a>) whenever TE is present in an HTTP/1.1 message.
    1771       </p>
    1772       <p id="rfc.section.4.4.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
     1753</pre><p id="rfc.section.4.3.p.7">The TE header field only applies to the immediate connection. Therefore, the keyword <em class="bcp14">MUST</em> be supplied within a Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.4" title="Connection">Section&nbsp;6.1</a>) whenever TE is present in an HTTP/1.1 message.
     1754      </p>
     1755      <p id="rfc.section.4.3.p.8">A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules: </p>
    17731756      <ol>
    17741757         <li>
    … …  
    17841767         <li>
    17851768            <p>If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it
    1786                is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;4.4.1</a>, a qvalue of 0 means "not acceptable".)
     1769               is accompanied by a qvalue of 0. (As defined in <a href="#quality.values" title="Quality Values">Section&nbsp;4.3.1</a>, a qvalue of 0 means "not acceptable".)
    17871770            </p>
    17881771         </li>
    … …  
    17931776         </li>
    17941777      </ol>
    1795       <p id="rfc.section.4.4.p.9">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with
     1778      <p id="rfc.section.4.3.p.9">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with
    17961779         no transfer-coding is always acceptable.
    17971780      </p>
    1798       <h3 id="rfc.section.4.4.1"><a href="#rfc.section.4.4.1">4.4.1</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h3>
    1799       <p id="rfc.section.4.4.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;4.4</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
     1781      <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="quality.values" href="#quality.values">Quality Values</a></h3>
     1782      <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section&nbsp;4.3</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight
    18001783         is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has
    18011784         a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion.
    … …  
    18031786      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.77"></span>  <a href="#quality.values" class="smpl">qvalue</a>         = ( "0" [ "." 0*3<a href="#core.rules" class="smpl">DIGIT</a> ] )
    18041787                 / ( "1" [ "." 0*3("0") ] )
    1805 </pre><div class="note" id="rfc.section.4.4.1.p.3">
     1788</pre><div class="note" id="rfc.section.4.3.1.p.3">
    18061789         <p> <b>Note:</b> "Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.
    18071790         </p>
    … …  
    18091792      <div id="rfc.iref.t.6"></div>
    18101793      <div id="rfc.iref.h.9"></div>
    1811       <h2 id="rfc.section.4.5"><a href="#rfc.section.4.5">4.5</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
    1812       <p id="rfc.section.4.5.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with
     1794      <h2 id="rfc.section.4.4"><a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="header.trailer" href="#header.trailer">Trailer</a></h2>
     1795      <p id="rfc.section.4.4.p.1">The "Trailer" header field indicates that the given set of header fields is present in the trailer of a message encoded with
    18131796         chunked transfer-coding.
    18141797      </p>
    18151798      <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.78"></span>  <a href="#header.trailer" class="smpl">Trailer</a> = 1#<a href="#header.fields" class="smpl">field-name</a>
    1816 </pre><p id="rfc.section.4.5.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient
     1799</pre><p id="rfc.section.4.4.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient
    18171800         to know which header fields to expect in the trailer.
    18181801      </p>
    1819       <p id="rfc.section.4.5.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
    1820       </p>
    1821       <p id="rfc.section.4.5.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:
     1802      <p id="rfc.section.4.4.p.4">If no Trailer header field is present, the trailer <em class="bcp14">SHOULD NOT</em> include any header fields. See <a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a> for restrictions on the use of trailer fields in a "chunked" transfer-coding.
     1803      </p>
     1804      <p id="rfc.section.4.4.p.5">Message header fields listed in the Trailer header field <em class="bcp14">MUST NOT</em> include the following header fields:
    18221805      </p>
    18231806      <ul>
    … …  
    20572040         </p>
    20582041      </div>
    2059       <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
     2042      <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    20602043      </p>
    20612044      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2>
    … …  
    23482331      <p id="rfc.section.6.5.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined
    23492332         by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined
    2350          below.
    2351       </p>
    2352       <h3 id="rfc.section.6.5.1"><a href="#rfc.section.6.5.1">6.5.1</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>
    2353       <p id="rfc.section.6.5.1.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade
    2354          header field. Each registered protocol-name is associated with contact information and an optional set of specifications that
    2355          details how the connection will be processed after it has been upgraded.
    2356       </p>
    2357       <p id="rfc.section.6.5.1.p.2">Registrations require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>) and are subject to the following rules:
    2358       </p>
    2359       <ol>
    2360          <li>A protocol-name token, once registered, stays registered forever.</li>
    2361          <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration.
    2362          </li>
    2363          <li>The registration <em class="bcp14">MUST</em> name a point of contact.
    2364          </li>
    2365          <li>The registration <em class="bcp14">MAY</em> name a set of specifications associated with that token. Such specifications need not be publicly available.
    2366          </li>
    2367          <li>The registration <em class="bcp14">SHOULD</em> name a set of expected "protocol-version" tokens associated with that token at the time of registration.
    2368          </li>
    2369          <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request.
    2370          </li>
    2371          <li>The IESG <em class="bcp14">MAY</em> reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot
    2372             be contacted.
    2373          </li>
    2374       </ol>
     2333         in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>.
     2334      </p>
    23752335      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    23762336      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    2377       <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     2337      <p id="rfc.section.7.1.p.1">HTTP header fields are registered within the Message Header Field Registry <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a> maintained by IANA at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt;.
     2338      </p>
     2339      <p id="rfc.section.7.1.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to
     2340         the permanent registrations below:
    23782341      </p>
    23792342      <div id="rfc.table.1">
    … …  
    24142377                  <td class="left">http</td>
    24152378                  <td class="left">standard</td>
    2416                   <td class="left"> <a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;4.4</a>
     2379                  <td class="left"> <a href="#header.te" id="rfc.xref.header.te.4" title="TE">Section&nbsp;4.3</a>
    24172380                  </td>
    24182381               </tr>
    … …  
    24212384                  <td class="left">http</td>
    24222385                  <td class="left">standard</td>
    2423                   <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;4.5</a>
     2386                  <td class="left"> <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;4.4</a>
    24242387                  </td>
    24252388               </tr>
    … …  
    24482411         </table>
    24492412      </div>
    2450       <p id="rfc.section.7.1.p.2">Furthermore, the header field name "Close" shall be registered as "reserved", as its use as HTTP header field would be in
    2451          conflict with the use of the "close" connection option for the "Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;6.1</a>).
     2413      <p id="rfc.section.7.1.p.3">Furthermore, the header field-name "Close" shall be registered as "reserved", since using that name as an HTTP header field
     2414         might conflict with the "close" connection option of the "Connection" header field (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section&nbsp;6.1</a>).
    24522415      </p>
    24532416      <div id="rfc.table.u.1">
    … …  
    24722435         </table>
    24732436      </div>
    2474       <p id="rfc.section.7.1.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
     2437      <p id="rfc.section.7.1.p.4">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    24752438      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2>
    2476       <p id="rfc.section.7.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; shall be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.7.1</a> and <a href="#https.uri" title="https URI scheme">2.7.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).
    2477       </p>
     2439      <p id="rfc.section.7.2.p.1">IANA maintains the registry of URI Schemes <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a> at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt;.
     2440      </p>
     2441      <p id="rfc.section.7.2.p.2">This document defines the following URI schemes, so their associated registry entries shall be updated according to the permanent
     2442         registrations below:
     2443      </p>
     2444      <div id="rfc.table.u.2">
     2445         <table class="tt full left" cellpadding="3" cellspacing="0">
     2446            <thead>
     2447               <tr>
     2448                  <th>URI Scheme</th>
     2449                  <th>Description</th>
     2450                  <th>Reference</th>
     2451               </tr>
     2452            </thead>
     2453            <tbody>
     2454               <tr>
     2455                  <td class="left">http</td>
     2456                  <td class="left">Hypertext Transfer Protocol</td>
     2457                  <td class="left"><a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a></td>
     2458               </tr>
     2459               <tr>
     2460                  <td class="left">https</td>
     2461                  <td class="left">Hypertext Transfer Protocol Secure</td>
     2462                  <td class="left"><a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a></td>
     2463               </tr>
     2464            </tbody>
     2465         </table>
     2466      </div>
    24782467      <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2>
    24792468      <p id="rfc.section.7.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following
    … …  
    25902579         <dd>IESG</dd>
    25912580      </dl>
    2592       <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registry</a></h2>
    2593       <p id="rfc.section.7.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;4.3</a> of this document.
    2594       </p>
    2595       <p id="rfc.section.7.4.p.2">The HTTP Transfer Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registrations below:
    2596       </p>
     2581      <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h2>
     2582      <p id="rfc.section.7.4.p.1">The HTTP Transfer Coding Registry defines the name space for transfer coding names.</p>
     2583      <p id="rfc.section.7.4.p.2">Registrations <em class="bcp14">MUST</em> include the following fields:
     2584      </p>
     2585      <ul>
     2586         <li>Name</li>
     2587         <li>Description</li>
     2588         <li>Pointer to specification text</li>
     2589      </ul>
     2590      <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) unless the encoding transformation is identical, as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section&nbsp;4.2</a>.
     2591      </p>
     2592      <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.
     2593      </p>
     2594      <p id="rfc.section.7.4.p.5">The registry itself is maintained at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt;.
     2595      </p>
     2596      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registrations</a></h2>
     2597      <p id="rfc.section.7.5.p.1">The HTTP Transfer Coding Registry shall be updated with the registrations below:</p>
    25972598      <div id="rfc.table.2">
    25982599         <div id="iana.transfer.coding.registration.table"></div>
    … …  
    26342635         </table>
    26352636      </div>
    2636       <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2>
    2637       <p id="rfc.section.7.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;6.5.1</a> of this document.
    2638       </p>
    2639       <p id="rfc.section.7.5.p.2">The HTTP Upgrade Token Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; shall be updated with the registration below:
    2640       </p>
    2641       <div id="rfc.table.u.2">
     2637      <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h2>
     2638      <p id="rfc.section.7.6.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the Upgrade
     2639         header field. Each registered protocol-name is associated with contact information and an optional set of specifications that
     2640         details how the connection will be processed after it has been upgraded.
     2641      </p>
     2642      <p id="rfc.section.7.6.p.2">Registrations require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>) and are subject to the following rules:
     2643      </p>
     2644      <ol>
     2645         <li>A protocol-name token, once registered, stays registered forever.</li>
     2646         <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration.
     2647         </li>
     2648         <li>The registration <em class="bcp14">MUST</em> name a point of contact.
     2649         </li>
     2650         <li>The registration <em class="bcp14">MAY</em> name a set of specifications associated with that token. Such specifications need not be publicly available.
     2651         </li>
     2652         <li>The registration <em class="bcp14">SHOULD</em> name a set of expected "protocol-version" tokens associated with that token at the time of registration.
     2653         </li>
     2654         <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request.
     2655         </li>
     2656         <li>The IESG <em class="bcp14">MAY</em> reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot
     2657            be contacted.
     2658         </li>
     2659      </ol>
     2660      <p id="rfc.section.7.6.p.3">This registration procedure for HTTP Upgrade Tokens replaces that previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>.
     2661      </p>
     2662      <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2>
     2663      <p id="rfc.section.7.7.p.1">The HTTP Upgrade Token Registry shall be updated with the registration below:</p>
     2664      <div id="rfc.table.u.3">
    26422665         <table class="tt full left" cellpadding="3" cellspacing="0">
    26432666            <thead>
    … …  
    26452668                  <th>Value</th>
    26462669                  <th>Description</th>
     2670                  <th>Expected Version Tokens</th>
    26472671                  <th>Reference</th>
    26482672               </tr>
    … …  
    26522676                  <td class="left">HTTP</td>
    26532677                  <td class="left">Hypertext Transfer Protocol</td>
    2654                   <td class="left"><a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a> of this specification
    2655                   </td>
     2678                  <td class="left">any DIGIT.DIGIT (e.g, "2.0")</td>
     2679                  <td class="left"><a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a></td>
    26562680               </tr>
    26572681            </tbody>
    26582682         </table>
    26592683      </div>
     2684      <p id="rfc.section.7.7.p.2">The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    26602685      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    26612686      <p id="rfc.section.8.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1
    … …  
    30383063         disallowed line folding in chunk extensions, and deprecate their use. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>)
    30393064      </p>
    3040       <p id="rfc.section.A.2.p.10">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;4.3</a>)
     3065      <p id="rfc.section.A.2.p.10">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;7.4</a>)
    30413066      </p>
    30423067      <p id="rfc.section.A.2.p.11">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent.
    … …  
    30513076      </p>
    30523077      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="changes.from.rfc.2817" href="#changes.from.rfc.2817">Changes from RFC 2817</a></h2>
    3053       <p id="rfc.section.A.3.p.1">Registration of Upgrade tokens now requires IETF Review (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;6.5.1</a>)
     3078      <p id="rfc.section.A.3.p.1">Registration of Upgrade tokens now requires IETF Review (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;7.6</a>)
    30543079      </p>
    30553080      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    36083633                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.9">4.2.1</a></li>
    36093634                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3610                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.4</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
     3635                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.c.13"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
    36113636                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.6"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">7.1</a></li>
    36123637               </ul>
    … …  
    36853710                        <li><tt>quoted-str-nf</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.70"><b>4.1</b></a></li>
    36863711                        <li><tt>quoted-string</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.44"><b>3.2.4</b></a></li>
    3687                         <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>4.4.1</b></a></li>
     3712                        <li><tt>qvalue</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.77"><b>4.3.1</b></a></li>
    36883713                        <li><tt>reason-phrase</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.31"><b>3.1.2</b></a></li>
    36893714                        <li><tt>received-by</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.91"><b>6.2</b></a></li>
    … …  
    36973722                        <li><tt>status-code</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.30"><b>3.1.2</b></a></li>
    36983723                        <li><tt>status-line</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.29"><b>3.1.2</b></a></li>
    3699                         <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>4.4</b></a></li>
     3724                        <li><tt>t-codings</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.74"><b>4.3</b></a></li>
    37003725                        <li><tt>tchar</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.42"><b>3.2.4</b></a></li>
    3701                         <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>4.4</b></a></li>
    3702                         <li><tt>te-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>4.4</b></a></li>
    3703                         <li><tt>te-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>4.4</b></a></li>
     3726                        <li><tt>TE</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.73"><b>4.3</b></a></li>
     3727                        <li><tt>te-ext</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.76"><b>4.3</b></a></li>
     3728                        <li><tt>te-params</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.75"><b>4.3</b></a></li>
    37043729                        <li><tt>token</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.41"><b>3.2.4</b></a></li>
    3705                         <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>4.5</b></a></li>
     3730                        <li><tt>Trailer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.78"><b>4.4</b></a></li>
    37063731                        <li><tt>trailer-part</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.69"><b>4.1</b></a></li>
    37073732                        <li><tt>transfer-coding</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.54"><b>4</b></a></li>
    … …  
    37253750                  <li>Header Fields&nbsp;&nbsp;
    37263751                     <ul>
    3727                         <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.4</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.h.12"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
     3752                        <li>Connection&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">2.3</a>, <a href="#rfc.xref.header.connection.2">2.6</a>, <a href="#rfc.xref.header.connection.3">3.2</a>, <a href="#rfc.xref.header.connection.4">4.3</a>, <a href="#rfc.xref.header.connection.5">5.6</a>, <a href="#rfc.xref.header.connection.6">5.6.1</a>, <a href="#rfc.iref.h.12"><b>6.1</b></a>, <a href="#rfc.xref.header.connection.7">6.3.2</a>, <a href="#rfc.xref.header.connection.8">6.5</a>, <a href="#rfc.xref.header.connection.9">7.1</a>, <a href="#rfc.xref.header.connection.10">7.1</a>, <a href="#rfc.xref.header.connection.11">A.2</a></li>
    37283753                        <li>Content-Length&nbsp;&nbsp;<a href="#rfc.iref.h.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">3.3.2</a>, <a href="#rfc.xref.header.content-length.2">7.1</a></li>
    37293754                        <li>Host&nbsp;&nbsp;<a href="#rfc.xref.header.host.1">5.3</a>, <a href="#rfc.iref.h.11"><b>5.4</b></a>, <a href="#rfc.xref.header.host.2">7.1</a>, <a href="#rfc.xref.header.host.3">A.1.1</a></li>
    3730                         <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.h.8"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">7.1</a></li>
    3731                         <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.h.9"><b>4.5</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li>
     3755                        <li>TE&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.h.8"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">4.3.1</a>, <a href="#rfc.xref.header.te.4">7.1</a></li>
     3756                        <li>Trailer&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.h.9"><b>4.4</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li>
    37323757                        <li>Transfer-Encoding&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.h.6"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a></li>
    37333758                        <li>Upgrade&nbsp;&nbsp;<a href="#rfc.iref.h.14"><b>6.5</b></a>, <a href="#rfc.xref.header.upgrade.1">7.1</a>, <a href="#rfc.xref.header.upgrade.2">A.2</a></li>
    … …  
    37953820                     </ul>
    37963821                  </li>
    3797                   <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">4.3</a>, <a href="#rfc.xref.Part3.4">4.4.1</a>, <a href="#rfc.xref.Part3.5">5.6.2</a>, <a href="#Part3"><b>10.1</b></a><ul>
    3798                         <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">4.3</a></li>
    3799                         <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.4">4.4.1</a></li>
     3822                  <li><em>Part3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">4.3.1</a>, <a href="#rfc.xref.Part3.4">5.6.2</a>, <a href="#rfc.xref.Part3.5">7.4</a>, <a href="#Part3"><b>10.1</b></a><ul>
     3823                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.5">7.4</a></li>
     3824                        <li><em>Section 5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.3">4.3.1</a></li>
    38003825                        <li><em>Appendix A</em>&nbsp;&nbsp;<a href="#rfc.xref.Part3.1">1</a></li>
    38013826                     </ul>
    … …  
    38203845                  <li><em>RFC1919</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>10.2</b></a></li>
    38213846                  <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#RFC1945"><b>10.2</b></a>, <a href="#rfc.xref.RFC1945.2">A</a></li>
    3822                   <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">4.2.2</a>, <a href="#rfc.xref.RFC1950.2">7.4</a>, <a href="#RFC1950"><b>10.1</b></a></li>
    3823                   <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">7.4</a>, <a href="#RFC1951"><b>10.1</b></a></li>
    3824                   <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">4.2.3</a>, <a href="#rfc.xref.RFC1952.2">7.4</a>, <a href="#RFC1952"><b>10.1</b></a></li>
     3847                  <li><em>RFC1950</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1950.1">4.2.2</a>, <a href="#rfc.xref.RFC1950.2">7.5</a>, <a href="#RFC1950"><b>10.1</b></a></li>
     3848                  <li><em>RFC1951</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">7.5</a>, <a href="#RFC1951"><b>10.1</b></a></li>
     3849                  <li><em>RFC1952</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1952.1">4.2.3</a>, <a href="#rfc.xref.RFC1952.2">7.5</a>, <a href="#RFC1952"><b>10.1</b></a></li>
    38253850                  <li><em>RFC2045</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.1">1</a>, <a href="#rfc.xref.RFC2045.2">3.3.1</a>, <a href="#RFC2045"><b>10.2</b></a><ul>
    38263851                        <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2045.2">3.3.1</a></li>
    … …  
    38383863                     </ul>
    38393864                  </li>
    3840                   <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">7.5</a>, <a href="#RFC2817"><b>10.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a><ul>
    3841                         <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.2">7.5</a></li>
     3865                  <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">7.6</a>, <a href="#RFC2817"><b>10.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a><ul>
     3866                        <li><em>Section 7.2</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.2">7.6</a></li>
    38423867                     </ul>
    38433868                  </li>
    … …  
    38653890                  <li><em>RFC4395</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4395.1">7.2</a>, <a href="#RFC4395"><b>10.2</b></a></li>
    38663891                  <li><em>RFC4559</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>10.2</b></a></li>
    3867                   <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">6.5.1</a>, <a href="#RFC5226"><b>10.2</b></a><ul>
    3868                         <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">4.3</a>, <a href="#rfc.xref.RFC5226.2">6.5.1</a></li>
     3892                  <li><em>RFC5226</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a>, <a href="#RFC5226"><b>10.2</b></a><ul>
     3893                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a></li>
    38693894                     </ul>
    38703895                  </li>
    … …  
    38903915                  <li>target resource&nbsp;&nbsp;<a href="#rfc.iref.t.7"><b>5.1</b></a></li>
    38913916                  <li>target URI&nbsp;&nbsp;<a href="#rfc.iref.t.8"><b>5.1</b></a></li>
    3892                   <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.t.5"><b>4.4</b></a>, <a href="#rfc.xref.header.te.3">4.4.1</a>, <a href="#rfc.xref.header.te.4">7.1</a></li>
     3917                  <li>TE header field&nbsp;&nbsp;<a href="#rfc.xref.header.te.1">4</a>, <a href="#rfc.xref.header.te.2">4.1</a>, <a href="#rfc.iref.t.5"><b>4.3</b></a>, <a href="#rfc.xref.header.te.3">4.3.1</a>, <a href="#rfc.xref.header.te.4">7.1</a></li>
    38933918                  <li><em>Tou1998</em>&nbsp;&nbsp;<a href="#rfc.xref.Tou1998.1">6.3.1</a>, <a href="#Tou1998"><b>10.2</b></a></li>
    3894                   <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.t.6"><b>4.5</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li>
     3919                  <li>Trailer header field&nbsp;&nbsp;<a href="#rfc.xref.header.trailer.1">4.1</a>, <a href="#rfc.iref.t.6"><b>4.4</b></a>, <a href="#rfc.xref.header.trailer.2">7.1</a></li>
    38953920                  <li>Transfer-Encoding header field&nbsp;&nbsp;<a href="#rfc.xref.header.transfer-encoding.1">3.3</a>, <a href="#rfc.iref.t.4"><b>3.3.1</b></a>, <a href="#rfc.xref.header.transfer-encoding.2">4</a>, <a href="#rfc.xref.header.transfer-encoding.3">7.1</a></li>
    38963921                  <li>transforming proxy&nbsp;&nbsp;<a href="#rfc.iref.t.1"><b>2.3</b></a></li>

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

    r1583 r1584  
    19441944</artwork></figure>
    19451945<t>
    1946    All transfer-coding values are case-insensitive. HTTP/1.1 uses
    1947    transfer-coding values in the TE header field (<xref target="header.te"/>) and in
    1948    the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
     1946   All transfer-coding values are case-insensitive.
     1947   The HTTP Transfer Coding registry is defined in
     1948   <xref target="transfer.coding.registry"/>.
     1949   HTTP/1.1 uses transfer-coding values in the TE header field
     1950   (<xref target="header.te"/>) and in the Transfer-Encoding header field
     1951   (<xref target="header.transfer-encoding"/>).
    19491952</t>
    19501953
    … …  
    21122115</section>
    21132116
    2114 </section>
    2115 
    2116 <section title="Transfer Coding Registry" anchor="transfer.coding.registry">
    2117 <t>
    2118    The HTTP Transfer Coding Registry defines the name space for the transfer
    2119    coding names.
    2120 </t>
    2121 <t>
    2122    Registrations &MUST; include the following fields:
    2123    <list style="symbols">
    2124      <t>Name</t>
    2125      <t>Description</t>
    2126      <t>Pointer to specification text</t>
    2127    </list>
    2128 </t>
    2129 <t>
    2130    Names of transfer codings &MUST-NOT; overlap with names of content codings
    2131    (&content-codings;), unless the encoding transformation is identical (as it
    2132    is the case for the compression codings defined in
    2133    <xref target="compression.codings"/>).
    2134 </t>
    2135 <t>
    2136    Values to be added to this name space require IETF Review (see
    2137    <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;
    2138    conform to the purpose of transfer coding defined in this section.
    2139 </t>
    2140 <t>
    2141    The registry itself is maintained at
    2142    <eref target="http://www.iana.org/assignments/http-parameters"/>.
    2143 </t>
    21442117</section>
    21452118
    … …  
    33953368   version rules of <xref target="http.version"/> and future updates to this
    33963369   specification. Additional tokens can be registered with IANA using the
    3397    registration procedure defined below. 
    3398 </t>
    3399 
    3400 <section title="Upgrade Token Registry" anchor="upgrade.token.registry">
    3401 <t>
    3402    The HTTP Upgrade Token Registry defines the name space for protocol-name
    3403    tokens used to identify protocols in the Upgrade header field.
    3404    Each registered protocol-name is associated with contact information and
    3405    an optional set of specifications that details how the connection
    3406    will be processed after it has been upgraded.
    3407 </t>
    3408 <t>
    3409    Registrations require IETF Review (see
    3410    <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>) and are subject to the
    3411    following rules:
    3412   <list style="numbers">
    3413     <t>A protocol-name token, once registered, stays registered forever.</t>
    3414     <t>The registration &MUST; name a responsible party for the
    3415        registration.</t>
    3416     <t>The registration &MUST; name a point of contact.</t>
    3417     <t>The registration &MAY; name a set of specifications associated with
    3418        that token. Such specifications need not be publicly available.</t>
    3419     <t>The registration &SHOULD; name a set of expected "protocol-version"
    3420        tokens associated with that token at the time of registration.</t>
    3421     <t>The responsible party &MAY; change the registration at any time.
    3422        The IANA will keep a record of all such changes, and make them
    3423        available upon request.</t>
    3424     <t>The IESG &MAY; reassign responsibility for a protocol token.
    3425        This will normally only be used in the case when a
    3426        responsible party cannot be contacted.</t>
    3427   </list>
    3428 </t>
    3429 </section>
     3370   registration procedure defined in <xref target="upgrade.token.registry"/>.
     3371</t>
    34303372</section>
    34313373
    … …  
    34363378<section title="Header Field Registration" anchor="header.field.registration">
    34373379<t>
    3438    The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
    3439    with the permanent registrations below (see <xref target="RFC3864"/>):
     3380   HTTP header fields are registered within the Message Header Field Registry
     3381   <xref target="RFC3864"/> maintained by IANA at
     3382   <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>.
     3383</t>
     3384<t>
     3385   This document defines the following HTTP header fields, so their
     3386   associated registry entries shall be updated according to the permanent
     3387   registrations below:
    34403388</t>
    34413389<?BEGININC p1-messaging.iana-headers ?>
    … …  
    34993447<?ENDINC p1-messaging.iana-headers ?>
    35003448<t>
    3501    Furthermore, the header field name "Close" shall be registered as "reserved", as its use as
    3502    HTTP header field would be in conflict with the use of the "close" connection
    3503    option for the "Connection" header field (<xref target="header.connection"/>).
     3449   Furthermore, the header field-name "Close" shall be registered as
     3450   "reserved", since using that name as an HTTP header field might
     3451   conflict with the "close" connection option of the "Connection"
     3452   header field (<xref target="header.connection"/>).
    35043453</t>
    35053454<texttable align="left" suppress-title="true">
    … …  
    35233472<section title="URI Scheme Registration" anchor="uri.scheme.registration">
    35243473<t>
    3525    The entries for the "http" and "https" URI Schemes in the registry located at
    3526    <eref target="http://www.iana.org/assignments/uri-schemes.html"/>
    3527    shall be updated to point to Sections <xref target="http.uri" format="counter"/>
    3528    and <xref target="https.uri" format="counter"/> of this document
    3529    (see <xref target="RFC4395"/>).
    3530 </t>
     3474   IANA maintains the registry of URI Schemes <xref target="RFC4395"/> at
     3475   <eref target="http://www.iana.org/assignments/uri-schemes.html"/>.
     3476</t>
     3477<t>
     3478   This document defines the following URI schemes, so their
     3479   associated registry entries shall be updated according to the permanent
     3480   registrations below:
     3481</t>
     3482<texttable align="left" suppress-title="true">
     3483   <ttcol>URI Scheme</ttcol>
     3484   <ttcol>Description</ttcol>
     3485   <ttcol>Reference</ttcol>
     3486
     3487   <c>http</c>
     3488   <c>Hypertext Transfer Protocol</c>
     3489   <c><xref target="http.uri"/></c>
     3490
     3491   <c>https</c>
     3492   <c>Hypertext Transfer Protocol Secure</c>
     3493   <c><xref target="https.uri"/></c>
     3494</texttable>
    35313495</section>
    35323496
    … …  
    36813645</section>
    36823646
    3683 <section title="Transfer Coding Registry" anchor="transfer.coding.registration">
    3684 <t>
    3685    The registration procedure for HTTP Transfer Codings is now defined by
    3686    <xref target="transfer.coding.registry"/> of this document.
    3687 </t>
    3688 <t>
    3689    The HTTP Transfer Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/>
    3690    shall be updated with the registrations below:
     3647<section title="Transfer Coding Registry" anchor="transfer.coding.registry">
     3648<t>
     3649   The HTTP Transfer Coding Registry defines the name space for transfer
     3650   coding names.
     3651</t>
     3652<t>
     3653   Registrations &MUST; include the following fields:
     3654   <list style="symbols">
     3655     <t>Name</t>
     3656     <t>Description</t>
     3657     <t>Pointer to specification text</t>
     3658   </list>
     3659</t>
     3660<t>
     3661   Names of transfer codings &MUST-NOT; overlap with names of content codings
     3662   (&content-codings;) unless the encoding transformation is identical, as it
     3663   is the case for the compression codings defined in
     3664   <xref target="compression.codings"/>.
     3665</t>
     3666<t>
     3667   Values to be added to this name space require IETF Review (see
     3668   <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;
     3669   conform to the purpose of transfer coding defined in this section.
     3670</t>
     3671<t>
     3672   The registry itself is maintained at
     3673   <eref target="http://www.iana.org/assignments/http-parameters"/>.
     3674</t>
     3675</section>
     3676
     3677<section title="Transfer Coding Registrations" anchor="transfer.coding.registration">
     3678<t>
     3679   The HTTP Transfer Coding Registry shall be updated with the registrations
     3680   below:
    36913681</t>
    36923682<texttable align="left" suppress-title="true" anchor="iana.transfer.coding.registration.table">
    … …  
    37193709</section>
    37203710
     3711<section title="Upgrade Token Registry" anchor="upgrade.token.registry">
     3712<t>
     3713   The HTTP Upgrade Token Registry defines the name space for protocol-name
     3714   tokens used to identify protocols in the Upgrade header field.
     3715   Each registered protocol-name is associated with contact information and
     3716   an optional set of specifications that details how the connection
     3717   will be processed after it has been upgraded.
     3718</t>
     3719<t>
     3720   Registrations require IETF Review (see
     3721   <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>) and are subject to the
     3722   following rules:
     3723  <list style="numbers">
     3724    <t>A protocol-name token, once registered, stays registered forever.</t>
     3725    <t>The registration &MUST; name a responsible party for the
     3726       registration.</t>
     3727    <t>The registration &MUST; name a point of contact.</t>
     3728    <t>The registration &MAY; name a set of specifications associated with
     3729       that token. Such specifications need not be publicly available.</t>
     3730    <t>The registration &SHOULD; name a set of expected "protocol-version"
     3731       tokens associated with that token at the time of registration.</t>
     3732    <t>The responsible party &MAY; change the registration at any time.
     3733       The IANA will keep a record of all such changes, and make them
     3734       available upon request.</t>
     3735    <t>The IESG &MAY; reassign responsibility for a protocol token.
     3736       This will normally only be used in the case when a
     3737       responsible party cannot be contacted.</t>
     3738  </list>
     3739</t>
     3740<t>
     3741   This registration procedure for HTTP Upgrade Tokens replaces that
     3742   previously defined in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/>.
     3743</t>
     3744</section>
     3745
    37213746<section title="Upgrade Token Registration" anchor="upgrade.token.registration">
    37223747<t>
    3723    The registration procedure for HTTP Upgrade Tokens &mdash; previously defined
    3724    in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/> &mdash; is now defined
    3725    by <xref target="upgrade.token.registry"/> of this document.
    3726 </t>
    3727 <t>
    3728    The HTTP Upgrade Token Registry located at <eref target="http://www.iana.org/assignments/http-upgrade-tokens/"/>
    3729    shall be updated with the registration below:
     3748   The HTTP Upgrade Token Registry shall be updated with the registration
     3749   below:
    37303750</t>
    37313751<texttable align="left" suppress-title="true">
    37323752   <ttcol>Value</ttcol>
    37333753   <ttcol>Description</ttcol>
     3754   <ttcol>Expected Version Tokens</ttcol>
    37343755   <ttcol>Reference</ttcol>
    37353756
    37363757   <c>HTTP</c>
    3737    <c>Hypertext Transfer Protocol</c> 
    3738    <c><xref target="http.version"/> of this specification</c>
    3739 
     3758   <c>Hypertext Transfer Protocol</c>
     3759   <c>any DIGIT.DIGIT (e.g, "2.0")</c>
     3760   <c><xref target="http.version"/></c>
    37403761</texttable>
     3762<t>
     3763   The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
     3764</t>
    37413765</section>
    37423766
Note: See TracChangeset for help on using the changeset viewer.