Changeset 2246 for draft-ietf-httpbis/latest
- Timestamp:
- 07/05/13 16:47:33 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 12 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2233 r2246 449 449 } 450 450 @bottom-center { 451 content: "Expires November 2, 2013";451 content: "Expires November 8, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2013-05-0 1">493 <meta name="dct.issued" scheme="ISO8601" content="2013-05-07"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">May 1, 2013</td>522 <td class="right">May 7, 2013</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: November 2, 2013</td>525 <td class="left">Expires: November 8, 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on November 2, 2013.</p>553 <p>This Internet-Draft will expire on November 8, 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 665 665 </ul> 666 666 </li> 667 <li><a href="#rfc.section.7.4">7.4</a> <a href="#transfer.coding.registry">Transfer Coding Registry</a></li> 668 <li><a href="#rfc.section.7.5">7.5</a> <a href="#transfer.coding.registration">Transfer Coding Registration</a></li> 669 <li><a href="#rfc.section.7.6">7.6</a> <a href="#upgrade.token.registry">Upgrade Token Registry</a></li> 670 <li><a href="#rfc.section.7.7">7.7</a> <a href="#upgrade.token.registration">Upgrade Token Registration</a></li> 667 <li><a href="#rfc.section.7.4">7.4</a> <a href="#transfer.coding.registry">Transfer Coding Registry</a><ul> 668 <li><a href="#rfc.section.7.4.1">7.4.1</a> <a href="#transfer.coding.registry.procedure">Procedure</a></li> 669 <li><a href="#rfc.section.7.4.2">7.4.2</a> <a href="#transfer.coding.registration">Registration</a></li> 670 </ul> 671 </li> 672 <li><a href="#rfc.section.7.5">7.5</a> <a href="#upgrade.token.registry">Upgrade Token Registry</a><ul> 673 <li><a href="#rfc.section.7.5.1">7.5.1</a> <a href="#upgrade.token.registry.procedure">Procedure</a></li> 674 <li><a href="#rfc.section.7.5.2">7.5.2</a> <a href="#upgrade.token.registration">Upgrade Token Registration</a></li> 675 </ul> 676 </li> 671 677 </ul> 672 678 </li> … … 2137 2143 <p id="rfc.section.6.7.p.10">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2138 2144 by the HTTP version rules of <a href="#http.version" title="Protocol Versioning">Section 2.6</a> and future updates to this specification. Additional tokens ought to be registered with IANA using the registration procedure 2139 defined in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7. 6</a>.2145 defined in <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.5</a>. 2140 2146 </p> 2141 2147 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 2142 2148 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 2143 <p id="rfc.section.7.1.p.1">HTTP header fields are registered within the Message Header Field Registry <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a> maintained by IANAat <<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>>.2149 <p id="rfc.section.7.1.p.1">HTTP header fields are registered within the Message Header Field Registry maintained at <<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>>. 2144 2150 </p> 2145 2151 <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 2146 the permanent registrations below :2152 the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 2147 2153 </p> 2148 2154 <div id="rfc.table.1"> … … 2390 2396 </dl> 2391 2397 <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a> <a id="transfer.coding.registry" href="#transfer.coding.registry">Transfer Coding Registry</a></h2> 2392 <p id="rfc.section.7.4.p.1">The HTTP Transfer Coding Registry defines the name space for transfer coding names.</p> 2393 <p id="rfc.section.7.4.p.2">Registrations <em class="bcp14">MUST</em> include the following fields: 2398 <p id="rfc.section.7.4.p.1">The HTTP Transfer Coding Registry defines the name space for transfer coding names. It is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 2399 </p> 2400 <h3 id="rfc.section.7.4.1"><a href="#rfc.section.7.4.1">7.4.1</a> <a id="transfer.coding.registry.procedure" href="#transfer.coding.registry.procedure">Procedure</a></h3> 2401 <p id="rfc.section.7.4.1.p.1">Registrations <em class="bcp14">MUST</em> include the following fields: 2394 2402 </p> 2395 2403 <ul> … … 2398 2406 <li>Pointer to specification text</li> 2399 2407 </ul> 2400 <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="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2401 </p> 2402 <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. Use of program names for the identification of encoding 2403 formats is not desirable and is discouraged for future encodings. 2404 </p> 2405 <p id="rfc.section.7.4.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 2406 </p> 2407 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="transfer.coding.registration" href="#transfer.coding.registration">Transfer Coding Registration</a></h2> 2408 <p id="rfc.section.7.5.p.1">The HTTP Transfer Coding Registry shall be updated with the registrations below:</p> 2408 <p id="rfc.section.7.4.1.p.2">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 3.1.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.27"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) unless the encoding transformation is identical, as is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 4.2</a>. 2409 </p> 2410 <p id="rfc.section.7.4.1.p.3">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 specification. 2411 </p> 2412 <p id="rfc.section.7.4.1.p.4">Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.</p> 2413 <h3 id="rfc.section.7.4.2"><a href="#rfc.section.7.4.2">7.4.2</a> <a id="transfer.coding.registration" href="#transfer.coding.registration">Registration</a></h3> 2414 <p id="rfc.section.7.4.2.p.1">The HTTP Transfer Coding Registry shall be updated with the registrations below:</p> 2409 2415 <div id="rfc.table.2"> 2410 2416 <div id="iana.transfer.coding.registration.table"></div> … … 2446 2452 </table> 2447 2453 </div> 2448 <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h2> 2449 <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 <a href="#header.upgrade" class="smpl">Upgrade</a> header field. Each registered protocol name is associated with contact information and an optional set of specifications that 2450 details how the connection will be processed after it has been upgraded. 2451 </p> 2452 <p id="rfc.section.7.6.p.2">Registrations happen on a "First Come First Served" basis (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: 2454 <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h2> 2455 <p id="rfc.section.7.5.p.1">The HTTP Upgrade Token Registry defines the name space for protocol-name tokens used to identify protocols in the <a href="#header.upgrade" class="smpl">Upgrade</a> header field. The registry is maintained at <<a href="http://www.iana.org/assignments/http-upgrade-tokens">http://www.iana.org/assignments/http-upgrade-tokens</a>>. 2456 </p> 2457 <h3 id="rfc.section.7.5.1"><a href="#rfc.section.7.5.1">7.5.1</a> <a id="upgrade.token.registry.procedure" href="#upgrade.token.registry.procedure">Procedure</a></h3> 2458 <p id="rfc.section.7.5.1.p.1">Each registered protocol name is associated with contact information and an optional set of specifications that details how 2459 the connection will be processed after it has been upgraded. 2460 </p> 2461 <p id="rfc.section.7.5.1.p.2">Registrations happen on a "First Come First Served" basis (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: 2453 2462 </p> 2454 2463 <ol> … … 2468 2477 </li> 2469 2478 </ol> 2470 <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>.2471 </p> 2472 <h 2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a> <a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2>2473 <p id="rfc.section.7. 7.p.1">The HTTP Upgrade Token Registry shall be updated with the registration below:</p>2479 <p id="rfc.section.7.5.1.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>. 2480 </p> 2481 <h3 id="rfc.section.7.5.2"><a href="#rfc.section.7.5.2">7.5.2</a> <a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h3> 2482 <p id="rfc.section.7.5.2.p.1">The HTTP Upgrade Token Registry shall be updated with the registration below:</p> 2474 2483 <div id="rfc.table.u.3"> 2475 2484 <table class="tt full left" cellpadding="3" cellspacing="0"> … … 2492 2501 </table> 2493 2502 </div> 2494 <p id="rfc.section.7. 7.p.2">The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>2503 <p id="rfc.section.7.5.2.p.2">The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 2495 2504 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 2496 2505 <p id="rfc.section.8.p.1">This section is meant to inform developers, information providers, and users of known security concerns relevant to HTTP/1.1 … … 2921 2930 <p id="rfc.section.A.2.p.34">The meaning of the "deflate" content coding has been clarified. (<a href="#deflate.coding" title="Deflate Coding">Section 4.2.2</a>) 2922 2931 </p> 2923 <p id="rfc.section.A.2.p.35">This specification now defines the Upgrade Token Registry, 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.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7. 6</a>)2932 <p id="rfc.section.A.2.p.35">This specification now defines the Upgrade Token Registry, 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.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.5</a>) 2924 2933 </p> 2925 2934 <p id="rfc.section.A.2.p.36">Empty list elements in list productions (e.g., a list header containing ", ,") have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Appendix B</a>) … … 3324 3333 </li> 3325 3334 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3326 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a>, <a href="#rfc.xref.Part2.25">6.3.2</a>, <a href="#rfc.xref.Part2.26">6.7</a>, <a href="#rfc.xref.Part2.27">7.4 </a>, <a href="#rfc.xref.Part2.28">8.3</a>, <a href="#rfc.xref.Part2.29">8.3</a>, <a href="#Part2"><b>10.1</b></a><ul>3335 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2.1</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">3.3.2</a>, <a href="#rfc.xref.Part2.17">4.3</a>, <a href="#rfc.xref.Part2.18">5.1</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.3</a>, <a href="#rfc.xref.Part2.21">5.6</a>, <a href="#rfc.xref.Part2.22">5.7.2</a>, <a href="#rfc.xref.Part2.23">6.3.1</a>, <a href="#rfc.xref.Part2.24">6.3.2</a>, <a href="#rfc.xref.Part2.25">6.3.2</a>, <a href="#rfc.xref.Part2.26">6.7</a>, <a href="#rfc.xref.Part2.27">7.4.1</a>, <a href="#rfc.xref.Part2.28">8.3</a>, <a href="#rfc.xref.Part2.29">8.3</a>, <a href="#Part2"><b>10.1</b></a><ul> 3327 3336 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">2.7</a></li> 3328 3337 <li><em>Section 3</em> <a href="#rfc.xref.Part2.14">3.3.2</a></li> 3329 <li><em>Section 3.1.2.1</em> <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.27">7.4 </a></li>3338 <li><em>Section 3.1.2.1</em> <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.27">7.4.1</a></li> 3330 3339 <li><em>Section 3.3</em> <a href="#rfc.xref.Part2.22">5.7.2</a></li> 3331 3340 <li><em>Section 4</em> <a href="#rfc.xref.Part2.6">3.1.1</a></li> … … 3373 3382 <li><em>RFC1919</em> <a href="#rfc.xref.RFC1919.1">2.3</a>, <a href="#RFC1919"><b>10.2</b></a></li> 3374 3383 <li><em>RFC1945</em> <a href="#rfc.xref.RFC1945.1">2.6</a>, <a href="#rfc.xref.RFC1945.2">9</a>, <a href="#RFC1945"><b>10.2</b></a>, <a href="#rfc.xref.RFC1945.3">A</a></li> 3375 <li><em>RFC1950</em> <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>3376 <li><em>RFC1951</em> <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>3377 <li><em>RFC1952</em> <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>3384 <li><em>RFC1950</em> <a href="#rfc.xref.RFC1950.1">4.2.2</a>, <a href="#rfc.xref.RFC1950.2">7.4.2</a>, <a href="#RFC1950"><b>10.1</b></a></li> 3385 <li><em>RFC1951</em> <a href="#rfc.xref.RFC1951.1">4.2.2</a>, <a href="#rfc.xref.RFC1951.2">7.4.2</a>, <a href="#RFC1951"><b>10.1</b></a></li> 3386 <li><em>RFC1952</em> <a href="#rfc.xref.RFC1952.1">4.2.3</a>, <a href="#rfc.xref.RFC1952.2">7.4.2</a>, <a href="#RFC1952"><b>10.1</b></a></li> 3378 3387 <li><em>RFC2045</em> <a href="#rfc.xref.RFC2045.1">2.1</a>, <a href="#rfc.xref.RFC2045.2">3.3.1</a>, <a href="#RFC2045"><b>10.2</b></a><ul> 3379 3388 <li><em>Section 6</em> <a href="#rfc.xref.RFC2045.2">3.3.1</a></li> … … 3391 3400 </ul> 3392 3401 </li> 3393 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">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>, <a href="#rfc.xref.RFC2817.4">A.2</a><ul>3394 <li><em>Section 7.2</em> <a href="#rfc.xref.RFC2817.2">7. 6</a>, <a href="#rfc.xref.RFC2817.4">A.2</a></li>3402 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">1</a>, <a href="#rfc.xref.RFC2817.2">7.5.1</a>, <a href="#RFC2817"><b>10.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a>, <a href="#rfc.xref.RFC2817.4">A.2</a><ul> 3403 <li><em>Section 7.2</em> <a href="#rfc.xref.RFC2817.2">7.5.1</a>, <a href="#rfc.xref.RFC2817.4">A.2</a></li> 3395 3404 </ul> 3396 3405 </li> … … 3417 3426 <li><em>RFC4033</em> <a href="#rfc.xref.RFC4033.1">8.1</a>, <a href="#RFC4033"><b>10.2</b></a></li> 3418 3427 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>10.2</b></a></li> 3419 <li><em>RFC5226</em> <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>3420 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">7.4 </a>, <a href="#rfc.xref.RFC5226.2">7.6</a></li>3428 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">7.4.1</a>, <a href="#rfc.xref.RFC5226.2">7.5.1</a>, <a href="#RFC5226"><b>10.2</b></a><ul> 3429 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">7.4.1</a>, <a href="#rfc.xref.RFC5226.2">7.5.1</a></li> 3421 3430 </ul> 3422 3431 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2233 r2246 3160 3160 <t> 3161 3161 HTTP header fields are registered within the Message Header Field Registry 3162 <xref target="BCP90"/> maintained by IANAat3162 maintained at 3163 3163 <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>. 3164 3164 </t> … … 3166 3166 This document defines the following HTTP header fields, so their 3167 3167 associated registry entries shall be updated according to the permanent 3168 registrations below :3168 registrations below (see <xref target="BCP90"/>): 3169 3169 </t> 3170 3170 <?BEGININC p1-messaging.iana-headers ?> … … 3435 3435 <t> 3436 3436 The HTTP Transfer Coding Registry defines the name space for transfer 3437 coding names. 3438 </t> 3437 coding names. It is maintained at <eref target="http://www.iana.org/assignments/http-parameters"/>. 3438 </t> 3439 3440 <section title="Procedure" anchor="transfer.coding.registry.procedure"> 3439 3441 <t> 3440 3442 Registrations &MUST; include the following fields: … … 3454 3456 Values to be added to this name space require IETF Review (see 3455 3457 <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST; 3456 conform to the purpose of transfer coding defined in this section. 3458 conform to the purpose of transfer coding defined in this specification. 3459 </t> 3460 <t> 3457 3461 Use of program names for the identification of encoding formats 3458 3462 is not desirable and is discouraged for future encodings. 3459 3463 </t> 3460 <t> 3461 The registry itself is maintained at 3462 <eref target="http://www.iana.org/assignments/http-parameters"/>. 3463 </t> 3464 </section> 3465 3466 <section title="Transfer Coding Registration" anchor="transfer.coding.registration"> 3464 </section> 3465 3466 <section title="Registration" anchor="transfer.coding.registration"> 3467 3467 <t> 3468 3468 The HTTP Transfer Coding Registry shall be updated with the registrations … … 3497 3497 </texttable> 3498 3498 </section> 3499 </section> 3499 3500 3500 3501 <section title="Upgrade Token Registry" anchor="upgrade.token.registry"> … … 3502 3503 The HTTP Upgrade Token Registry defines the name space for protocol-name 3503 3504 tokens used to identify protocols in the <x:ref>Upgrade</x:ref> header 3504 field. Each registered protocol name is associated with contact information 3505 field. The registry is maintained at <eref target="http://www.iana.org/assignments/http-upgrade-tokens"/>. 3506 </t> 3507 3508 <section title="Procedure" anchor="upgrade.token.registry.procedure"> 3509 <t> 3510 Each registered protocol name is associated with contact information 3505 3511 and an optional set of specifications that details how the connection 3506 3512 will be processed after it has been upgraded. … … 3552 3558 The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force". 3553 3559 </t> 3560 </section> 3554 3561 </section> 3555 3562 -
draft-ietf-httpbis/latest/p2-semantics.html
r2232 r2246 449 449 } 450 450 @bottom-center { 451 content: "Expires November 2, 2013";451 content: "Expires November 8, 2013"; 452 452 } 453 453 @bottom-right { … … 494 494 <meta name="dct.creator" content="Reschke, J. F."> 495 495 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 496 <meta name="dct.issued" scheme="ISO8601" content="2013-05-0 1">496 <meta name="dct.issued" scheme="ISO8601" content="2013-05-07"> 497 497 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 498 498 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 522 522 <tr> 523 523 <td class="left">Intended status: Standards Track</td> 524 <td class="right">May 1, 2013</td>524 <td class="right">May 7, 2013</td> 525 525 </tr> 526 526 <tr> 527 <td class="left">Expires: November 2, 2013</td>527 <td class="left">Expires: November 8, 2013</td> 528 528 <td class="right"></td> 529 529 </tr> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on November 2, 2013.</p>555 <p>This Internet-Draft will expire on November 8, 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 739 739 <li><a href="#rfc.section.8">8.</a> <a href="#IANA.considerations">IANA Considerations</a><ul> 740 740 <li><a href="#rfc.section.8.1">8.1</a> <a href="#method.registry">Method Registry</a><ul> 741 <li><a href="#rfc.section.8.1.1">8.1.1</a> <a href="#method. procedure">Procedure</a></li>741 <li><a href="#rfc.section.8.1.1">8.1.1</a> <a href="#method.registry.procedure">Procedure</a></li> 742 742 <li><a href="#rfc.section.8.1.2">8.1.2</a> <a href="#considerations.for.new.methods">Considerations for New Methods</a></li> 743 743 <li><a href="#rfc.section.8.1.3">8.1.3</a> <a href="#method.registration">Registrations</a></li> … … 745 745 </li> 746 746 <li><a href="#rfc.section.8.2">8.2</a> <a href="#status.code.registry">Status Code Registry</a><ul> 747 <li><a href="#rfc.section.8.2.1">8.2.1</a> <a href="#status.code. procedure">Procedure</a></li>747 <li><a href="#rfc.section.8.2.1">8.2.1</a> <a href="#status.code.registry.procedure">Procedure</a></li> 748 748 <li><a href="#rfc.section.8.2.2">8.2.2</a> <a href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></li> 749 749 <li><a href="#rfc.section.8.2.3">8.2.3</a> <a href="#status.code.registration">Registrations</a></li> … … 3064 3064 <li> 3065 3065 <p>To inform cache recipients that they <em class="bcp14">MUST NOT</em> use this response to satisfy a later request unless the later request has the same values for the listed fields as the original 3066 request (<a href="p6-cache.html#caching.negotiated.responses" title=" Using Negotiated Responses">Section 4.3</a> of <a href="#Part6" id="rfc.xref.Part6.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). In other words, Vary expands the cache key required to match a new request to the stored cache entry.3066 request (<a href="p6-cache.html#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.3</a> of <a href="#Part6" id="rfc.xref.Part6.26"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). In other words, Vary expands the cache key required to match a new request to the stored cache entry. 3067 3067 </p> 3068 3068 </li> … … 3192 3192 <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 3193 3193 <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a> <a id="method.registry" href="#method.registry">Method Registry</a></h2> 3194 <p id="rfc.section.8.1.p.1">The HTTP Method Registry defines the name space for the request method token (<a href="#methods" title="Request Methods">Section 4</a>). The method registry ismaintained at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>>.3195 </p> 3196 <h3 id="rfc.section.8.1.1"><a href="#rfc.section.8.1.1">8.1.1</a> <a id="method. procedure" href="#method.procedure">Procedure</a></h3>3194 <p id="rfc.section.8.1.p.1">The HTTP Method Registry defines the name space for the request method token (<a href="#methods" title="Request Methods">Section 4</a>). The method registry will be created and maintained at <<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>>. 3195 </p> 3196 <h3 id="rfc.section.8.1.1"><a href="#rfc.section.8.1.1">8.1.1</a> <a id="method.registry.procedure" href="#method.registry.procedure">Procedure</a></h3> 3197 3197 <p id="rfc.section.8.1.1.p.1">HTTP method registrations <em class="bcp14">MUST</em> include the following fields: 3198 3198 </p> … … 3304 3304 <p id="rfc.section.8.2.p.1">The HTTP Status Code Registry defines the name space for the response status-code token (<a href="#status.codes" title="Response Status Codes">Section 6</a>). The status code registry is maintained at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>>. 3305 3305 </p> 3306 <p id="rfc.section.8.2.p.2">This section replaces the registration procedure for HTTP Status Codes previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. 3307 </p> 3308 <h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a> <a id="status.code.procedure" href="#status.code.procedure">Procedure</a></h3> 3309 <p id="rfc.section.8.2.1.p.1">Values to be added to the HTTP status code name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). 3306 <p id="rfc.section.8.2.p.2">This Section replaces the registration procedure for HTTP Status Codes previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. 3307 </p> 3308 <h3 id="rfc.section.8.2.1"><a href="#rfc.section.8.2.1">8.2.1</a> <a id="status.code.registry.procedure" href="#status.code.registry.procedure">Procedure</a></h3> 3309 <p id="rfc.section.8.2.1.p.1">A registration <em class="bcp14">MUST</em> include the following fields: 3310 </p> 3311 <ul> 3312 <li>Status Code (3 digits)</li> 3313 <li>Short Description</li> 3314 <li>Pointer to specification text</li> 3315 </ul> 3316 <p id="rfc.section.8.2.1.p.2">Values to be added to the HTTP status code name space require IETF Review (see <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>, <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a>). 3310 3317 </p> 3311 3318 <h3 id="rfc.section.8.2.2"><a href="#rfc.section.8.2.2">8.2.2</a> <a id="considerations.for.new.status.codes" href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></h3> … … 3635 3642 </li> 3636 3643 <li> 3637 <p>That when the header is used in requests and affects response selection (<a href="p6-cache.html#caching.negotiated.responses" title=" Using Negotiated Responses">Section 4.3</a> of <a href="#Part6" id="rfc.xref.Part6.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), it ought to be listed in the <a href="#header.vary" class="smpl">Vary</a> response header field (<a href="#header.vary" id="rfc.xref.header.vary.3" title="Vary">Section 7.1.4</a>).3644 <p>That when the header is used in requests and affects response selection (<a href="p6-cache.html#caching.negotiated.responses" title="Calculating Secondary Keys with Vary">Section 4.3</a> of <a href="#Part6" id="rfc.xref.Part6.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>), it ought to be listed in the <a href="#header.vary" class="smpl">Vary</a> response header field (<a href="#header.vary" id="rfc.xref.header.vary.3" title="Vary">Section 7.1.4</a>). 3638 3645 </p> 3639 3646 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2232 r2246 4175 4175 The HTTP Method Registry defines the name space for the request method 4176 4176 token (<xref target="methods"/>). 4177 The method registry ismaintained at4177 The method registry will be created and maintained at 4178 4178 <eref target="http://www.iana.org/assignments/http-methods"/>. 4179 4179 </t> 4180 4180 4181 <section title="Procedure" anchor="method. procedure">4181 <section title="Procedure" anchor="method.registry.procedure"> 4182 4182 <t> 4183 4183 HTTP method registrations &MUST; include the following fields: … … 4303 4303 <t> 4304 4304 The HTTP Status Code Registry defines the name space for the response 4305 status-code token (<xref target="status.codes"/>). 4306 The status code registry is maintained at 4307 <eref target="http://www.iana.org/assignments/http-status-codes"/>. 4308 </t> 4309 <t> 4310 This section replaces the registration procedure for HTTP Status Codes 4305 status-code token (<xref target="status.codes"/>). The status code registry 4306 is maintained at <eref target="http://www.iana.org/assignments/http-status-codes"/>. 4307 </t> 4308 <t> 4309 This Section replaces the registration procedure for HTTP Status Codes 4311 4310 previously defined in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>. 4312 4311 </t> 4313 4312 4314 <section title="Procedure" anchor="status.code.procedure"> 4313 <section title="Procedure" anchor="status.code.registry.procedure"> 4314 <t> 4315 A registration &MUST; include the following fields: 4316 <list style="symbols"> 4317 <t>Status Code (3 digits)</t> 4318 <t>Short Description</t> 4319 <t>Pointer to specification text</t> 4320 </list> 4321 </t> 4315 4322 <t> 4316 4323 Values to be added to the HTTP status code name space require IETF Review -
draft-ietf-httpbis/latest/p4-conditional.html
r2232 r2246 449 449 } 450 450 @bottom-center { 451 content: "Expires November 2, 2013";451 content: "Expires November 8, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2013-05-0 1">493 <meta name="dct.issued" scheme="ISO8601" content="2013-05-07"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 495 495 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."> … … 517 517 </tr> 518 518 <tr> 519 <td class="left">Expires: November 2, 2013</td>520 <td class="right">May 1, 2013</td>519 <td class="left">Expires: November 8, 2013</td> 520 <td class="right">May 7, 2013</td> 521 521 </tr> 522 522 </tbody> … … 545 545 in progress”. 546 546 </p> 547 <p>This Internet-Draft will expire on November 2, 2013.</p>547 <p>This Internet-Draft will expire on November 8, 2013.</p> 548 548 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 549 549 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1056 1056 cache updates (e.g., <a href="#header.last-modified" class="smpl">Last-Modified</a> might be useful if the response does not have an <a href="#header.etag" class="smpl">ETag</a> field). 1057 1057 </p> 1058 <p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Responses with 304 Not Modified">Section 4.2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional1058 <p id="rfc.section.4.1.p.4">Requirements on a cache that receives a 304 response are defined in <a href="p6-cache.html#freshening.responses" title="Freshening Stored Responses upon Validation">Section 4.2.1</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>. If the conditional request originated with an outbound client, such as a user agent with its own cache sending a conditional 1059 1059 GET to a shared proxy, then the proxy <em class="bcp14">SHOULD</em> forward the 304 response to that client. 1060 1060 </p> … … 1168 1168 </div> 1169 1169 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1170 <p id="rfc.section.6.2.p.1">The Message Header Field Registry located at <<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>> shall be updated with the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 1170 <p id="rfc.section.6.2.p.1">HTTP header fields are registered within the Message Header Field Registry maintained at <<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>>. 1171 </p> 1172 <p id="rfc.section.6.2.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to 1173 the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 1171 1174 </p> 1172 1175 <div id="rfc.table.2"> … … 1227 1230 </table> 1228 1231 </div> 1229 <p id="rfc.section.6.2.p. 2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>1232 <p id="rfc.section.6.2.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1230 1233 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1231 1234 <p id="rfc.section.7.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to the HTTP/1.1 -
draft-ietf-httpbis/latest/p4-conditional.xml
r2232 r2246 1098 1098 <section title="Header Field Registration" anchor="header.field.registration"> 1099 1099 <t> 1100 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 1101 with the permanent registrations below (see <xref target="BCP90"/>): 1100 HTTP header fields are registered within the Message Header Field Registry 1101 maintained at 1102 <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>. 1103 </t> 1104 <t> 1105 This document defines the following HTTP header fields, so their 1106 associated registry entries shall be updated according to the permanent 1107 registrations below (see <xref target="BCP90"/>): 1102 1108 </t> 1103 1109 <?BEGININC p4-conditional.iana-headers ?> -
draft-ietf-httpbis/latest/p5-range.html
r2232 r2246 449 449 } 450 450 @bottom-center { 451 content: "Expires November 2, 2013";451 content: "Expires November 8, 2013"; 452 452 } 453 453 @bottom-right { … … 492 492 <meta name="dct.creator" content="Reschke, J. F."> 493 493 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 494 <meta name="dct.issued" scheme="ISO8601" content="2013-05-0 1">494 <meta name="dct.issued" scheme="ISO8601" content="2013-05-07"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 496 496 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."> … … 518 518 </tr> 519 519 <tr> 520 <td class="left">Expires: November 2, 2013</td>520 <td class="left">Expires: November 8, 2013</td> 521 521 <td class="right">J. Reschke, Editor</td> 522 522 </tr> … … 527 527 <tr> 528 528 <td class="left"></td> 529 <td class="right">May 1, 2013</td>529 <td class="right">May 7, 2013</td> 530 530 </tr> 531 531 </tbody> … … 552 552 in progress”. 553 553 </p> 554 <p>This Internet-Draft will expire on November 2, 2013.</p>554 <p>This Internet-Draft will expire on November 8, 2013.</p> 555 555 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 556 556 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 942 942 <h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a> <a id="range.unit.registry" href="#range.unit.registry">Range Unit Registry</a></h2> 943 943 <p id="rfc.section.5.1.p.1">The HTTP Range Unit Registry defines the name space for the range unit names and refers to their corresponding specifications. 944 The registry ismaintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>.944 The registry will be created and maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. 945 945 </p> 946 946 <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a> <a id="range.unit.registry.procedure" href="#range.unit.registry.procedure">Procedure</a></h3> … … 1011 1011 </div> 1012 1012 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1013 <p id="rfc.section.5.3.p.1">The Message Header Field Registry located at <<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>> shall be updated with the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 1013 <p id="rfc.section.5.3.p.1">HTTP header fields are registered within the Message Header Field Registry maintained at <<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>>. 1014 </p> 1015 <p id="rfc.section.5.3.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to 1016 the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 1014 1017 </p> 1015 1018 <div id="rfc.table.3"> … … 1056 1059 </table> 1057 1060 </div> 1058 <p id="rfc.section.5.3.p. 2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>1061 <p id="rfc.section.5.3.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1059 1062 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1060 1063 <p id="rfc.section.6.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to the HTTP/1.1 -
draft-ietf-httpbis/latest/p5-range.xml
r2232 r2246 844 844 The HTTP Range Unit Registry defines the name space for the range 845 845 unit names and refers to their corresponding specifications. 846 The registry ismaintained at846 The registry will be created and maintained at 847 847 <eref target="http://www.iana.org/assignments/http-parameters"/>. 848 848 </t> … … 915 915 <section title="Header Field Registration" anchor="header.field.registration"> 916 916 <t> 917 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 918 with the permanent registrations below (see <xref target="BCP90"/>): 917 HTTP header fields are registered within the Message Header Field Registry 918 maintained at 919 <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>. 920 </t> 921 <t> 922 This document defines the following HTTP header fields, so their 923 associated registry entries shall be updated according to the permanent 924 registrations below (see <xref target="BCP90"/>): 919 925 </t> 920 926 <?BEGININC p5-range.iana-headers ?> -
draft-ietf-httpbis/latest/p6-cache.html
r2244 r2246 1611 1611 </div> 1612 1612 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="warn.code.registry" href="#warn.code.registry">Warn Code Registry</a></h2> 1613 <p id="rfc.section.9.2.p.1">The HTTP Warn Code Registry defines the value space for warn codes. It will be created and maintained at <<a href="http://www.iana.org/assignments/http-warn-codes">http://www.iana.org/assignments/http-warn-codes</a>>.1613 <p id="rfc.section.9.2.p.1">The HTTP Warn Code Registry defines the name space for warn codes. It will be created and maintained at <<a href="http://www.iana.org/assignments/http-warn-codes">http://www.iana.org/assignments/http-warn-codes</a>>. 1614 1614 </p> 1615 1615 <h3 id="rfc.section.9.2.1"><a href="#rfc.section.9.2.1">9.2.1</a> <a id="warn.code.registry.procedure" href="#warn.code.registry.procedure">Procedure</a></h3> … … 1682 1682 </div> 1683 1683 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1684 <p id="rfc.section.9.3.p.1">The Message Header Field Registry located at <<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>> shall be updated with the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 1684 <p id="rfc.section.9.3.p.1">HTTP header fields are registered within the Message Header Field Registry maintained at <<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>>. 1685 </p> 1686 <p id="rfc.section.9.3.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to 1687 the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 1685 1688 </p> 1686 1689 <div id="rfc.table.3"> … … 1734 1737 </table> 1735 1738 </div> 1736 <p id="rfc.section.9.3.p. 2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>1739 <p id="rfc.section.9.3.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 1737 1740 <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 1738 1741 <p id="rfc.section.10.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP/1.1 -
draft-ietf-httpbis/latest/p6-cache.xml
r2244 r2246 1886 1886 <section title="Warn Code Registry" anchor="warn.code.registry"> 1887 1887 <t> 1888 The HTTP Warn Code Registry defines the value space for warn codes.1888 The HTTP Warn Code Registry defines the name space for warn codes. 1889 1889 It will be created and maintained at 1890 1890 <eref target="http://www.iana.org/assignments/http-warn-codes"/>. … … 1959 1959 <section title="Header Field Registration" anchor="header.field.registration"> 1960 1960 <t> 1961 The Message Header Field Registry located at <eref 1962 target="http://www.iana.org/assignments/message-headers/message-header-index.html" /> 1963 shall be updated with the permanent registrations below (see <xref target="BCP90" />): 1961 HTTP header fields are registered within the Message Header Field Registry 1962 maintained at 1963 <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>. 1964 </t> 1965 <t> 1966 This document defines the following HTTP header fields, so their 1967 associated registry entries shall be updated according to the permanent 1968 registrations below (see <xref target="BCP90"/>): 1964 1969 </t> 1965 1970 <?BEGININC p6-cache.iana-headers ?> -
draft-ietf-httpbis/latest/p7-auth.html
r2245 r2246 882 882 </div> 883 883 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 884 <p id="rfc.section.5.3.p.1">The Message Header Field Registry located at <<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>> shall be updated with the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 884 <p id="rfc.section.5.3.p.1">HTTP header fields are registered within the Message Header Field Registry maintained at <<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>>. 885 </p> 886 <p id="rfc.section.5.3.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to 887 the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 885 888 </p> 886 889 <div id="rfc.table.2"> … … 927 930 </table> 928 931 </div> 929 <p id="rfc.section.5.3.p. 2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>932 <p id="rfc.section.5.3.p.3">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 930 933 <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 931 934 <p id="rfc.section.6.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP/1.1 -
draft-ietf-httpbis/latest/p7-auth.xml
r2245 r2246 625 625 <section title="Header Field Registration" anchor="header.field.registration"> 626 626 <t> 627 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 628 with the permanent registrations below (see <xref target="BCP90"/>): 627 HTTP header fields are registered within the Message Header Field Registry 628 maintained at 629 <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>. 630 </t> 631 <t> 632 This document defines the following HTTP header fields, so their 633 associated registry entries shall be updated according to the permanent 634 registrations below (see <xref target="BCP90"/>): 629 635 </t> 630 636 <?BEGININC p7-auth.iana-headers ?>
Note: See TracChangeset
for help on using the changeset viewer.