Changeset 684
- Timestamp:
- 16/08/09 10:41:56 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r678 r684 400 400 <meta name="DC.Creator" content="Reschke, J. F."> 401 401 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 402 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-08-1 3">402 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-08-16"> 403 403 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 404 404 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 427 427 </tr> 428 428 <tr> 429 <td class="header left">Updates: <a href="http://tools.ietf.org/html/rfc2817">2817</a> (if approved) 430 </td> 431 <td class="header right">J. Mogul</td> 432 </tr> 433 <tr> 429 434 <td class="header left">Intended status: Standards Track</td> 430 <td class="header right">J. Mogul</td>431 </tr>432 <tr>433 <td class="header left">Expires: February 14, 2010</td>434 435 <td class="header right">HP</td> 435 436 </tr> 436 437 <tr> 437 <td class="header left"> </td>438 <td class="header left">Expires: February 17, 2010</td> 438 439 <td class="header right">H. Frystyk</td> 439 440 </tr> … … 484 485 <tr> 485 486 <td class="header left"></td> 486 <td class="header right">August 1 3, 2009</td>487 <td class="header right">August 16, 2009</td> 487 488 </tr> 488 489 </table> … … 508 509 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 509 510 </p> 510 <p>This Internet-Draft will expire in February 1 4, 2010.</p>511 <p>This Internet-Draft will expire in February 17, 2010.</p> 511 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 512 513 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 636 637 <li class="tocline1">9.6 <a href="#header.trailer">Trailer</a></li> 637 638 <li class="tocline1">9.7 <a href="#header.transfer-encoding">Transfer-Encoding</a></li> 638 <li class="tocline1">9.8 <a href="#header.upgrade">Upgrade</a></li> 639 <li class="tocline1">9.8 <a href="#header.upgrade">Upgrade</a><ul class="toc"> 640 <li class="tocline1">9.8.1 <a href="#upgrade.token.registry">Upgrade Token Registry</a></li> 641 </ul> 642 </li> 639 643 <li class="tocline1">9.9 <a href="#header.via">Via</a></li> 640 644 </ul> … … 649 653 </li> 650 654 <li class="tocline1">10.4 <a href="#transfer.coding.registration">Transfer Coding Registry</a></li> 655 <li class="tocline1">10.5 <a href="#upgrade.token.registration">Upgrade Token Registration</a></li> 651 656 </ul> 652 657 </li> … … 2023 2028 </p> 2024 2029 <p id="rfc.section.9.8.p.9">This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined 2025 by the HTTP version rules of <a href="#http.version" title="HTTP Version">Section 2.5</a> and future updates to this specification. Any token can be used as a protocol name; however, it will only be useful if both 2026 the client and server associate the name with the same protocol. 2030 by the HTTP version rules of <a href="#http.version" title="HTTP Version">Section 2.5</a> and future updates to this specification. Additional tokens can be registered with IANA using the registration procedure defined 2031 below. 2032 </p> 2033 <h3 id="rfc.section.9.8.1"><a href="#rfc.section.9.8.1">9.8.1</a> <a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3> 2034 <p id="rfc.section.9.8.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header 2035 field. Each registered token should be associated with one or a set of specifications, and with contact information. 2036 </p> 2037 <p id="rfc.section.9.8.1.p.2">Registrations should be allowed on a First Come First Served basis as described in <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>. These specifications need not be IETF documents or be subject to IESG review, but should obey the following rules: 2038 </p> 2039 <ol> 2040 <li>A token, once registered, stays registered forever.</li> 2041 <li>The registration <em class="bcp14">MUST</em> name a responsible party for the registration. 2042 </li> 2043 <li>The registration <em class="bcp14">MUST</em> name a point of contact. 2044 </li> 2045 <li>The registration <em class="bcp14">MAY</em> name the documentation required for the token. 2046 </li> 2047 <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. 2048 </li> 2049 <li>The responsible party for the first registration of a "product" token <em class="bcp14">MUST</em> approve later registrations of a "version" token together with that "product" token before they can be registered. 2050 </li> 2051 <li>If absolutely required, the IESG <em class="bcp14">MAY</em> reassign the responsibility for a token. This will normally only be used in the case when a responsible party cannot be contacted. 2052 </li> 2053 </ol> 2054 <p id="rfc.section.9.8.1.p.3">It is not required that specifications for upgrade tokens be made publicly available, but the contact information for the 2055 registration should be. 2027 2056 </p> 2028 2057 <div id="rfc.iref.v.1"></div> … … 2314 2343 </table> 2315 2344 </div> 2345 <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a> <a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2> 2346 <p id="rfc.section.10.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.1"><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 9.8.1</a> of this document. 2347 </p> 2348 <p id="rfc.section.10.5.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>> should be updated with the registration below: 2349 </p> 2350 <div id="rfc.table.u.1"> 2351 <table class="tt full left" cellpadding="3" cellspacing="0"> 2352 <thead> 2353 <tr> 2354 <th>Value</th> 2355 <th>Description</th> 2356 <th>Reference</th> 2357 </tr> 2358 </thead> 2359 <tbody> 2360 <tr> 2361 <td>HTTP</td> 2362 <td>Hypertext Transfer Protocol</td> 2363 <td><a href="#http.version" title="HTTP Version">Section 2.5</a> of this specification 2364 </td> 2365 </tr> 2366 </tbody> 2367 </table> 2368 </div> 2316 2369 <h1 id="rfc.section.11"><a href="#rfc.section.11">11.</a> <a id="security.considerations" href="#security.considerations">Security Considerations</a></h1> 2317 2370 <p id="rfc.section.11.p.1">This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 … … 2479 2532 <h2 id="rfc.references.2"><a href="#rfc.section.13.2" id="rfc.section.13.2">13.2</a> Informative References 2480 2533 </h2> 2481 <table summary="Informative References"> 2534 <table summary="Informative References"> 2482 2535 <tr> 2483 2536 <td class="reference"><b id="BCP97">[BCP97]</b></td> … … 2549 2602 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 2550 2603 <td class="top"><a title="University of California, Irvine">Fielding, R.</a>, <a title="W3C">Gettys, J.</a>, <a title="Compaq Computer Corporation">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a title="Xerox Corporation">Masinter, L.</a>, <a title="Microsoft Corporation">Leach, P.</a>, and <a title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. 2604 </td> 2605 </tr> 2606 <tr> 2607 <td class="reference"><b id="RFC2817">[RFC2817]</b></td> 2608 <td class="top"><a title="4K Associates / UC Irvine">Khare, R.</a> and <a title="Agranat Systems, Inc.">S. Lawrence</a>, “<a href="http://tools.ietf.org/html/rfc2817">Upgrading to TLS Within HTTP/1.1</a>”, RFC 2817, May 2000. 2551 2609 </td> 2552 2610 </tr> … … 3146 3204 </li> 3147 3205 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/157">http://tools.ietf.org/wg/httpbis/trac/ticket/157</a>>: "IP addresses in URLs" 3206 </li> 3207 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/172">http://tools.ietf.org/wg/httpbis/trac/ticket/172</a>>: "take over HTTP Upgrade Token Registry" 3148 3208 </li> 3149 3209 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/188">http://tools.ietf.org/wg/httpbis/trac/ticket/188</a>>: "pick IANA policy (RFC5226) for Transfer Coding / Content Coding" … … 3427 3487 <li class="indline1"><em>RFC2145</em> <a class="iref" href="#rfc.xref.RFC2145.1">2.5</a>, <a class="iref" href="#rfc.xref.RFC2145.2">2.5</a>, <a class="iref" href="#RFC2145"><b>13.2</b></a>, <a class="iref" href="#rfc.xref.RFC2145.3">B.3</a></li> 3428 3488 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">12</a>, <a class="iref" href="#RFC2616"><b>13.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">D.1</a></li> 3489 <li class="indline1"><em>RFC2817</em> <a class="iref" href="#rfc.xref.RFC2817.1">10.5</a>, <a class="iref" href="#RFC2817"><b>13.2</b></a><ul class="ind"> 3490 <li class="indline1"><em>Section 7.2</em> <a class="iref" href="#rfc.xref.RFC2817.1">10.5</a></li> 3491 </ul> 3492 </li> 3429 3493 <li class="indline1"><em>RFC2818</em> <a class="iref" href="#rfc.xref.RFC2818.1">2.6.2</a>, <a class="iref" href="#RFC2818"><b>13.2</b></a></li> 3430 3494 <li class="indline1"><em>RFC2965</em> <a class="iref" href="#rfc.xref.RFC2965.1">3.2</a>, <a class="iref" href="#RFC2965"><b>13.2</b></a></li> … … 3446 3510 <li class="indline1"><em>RFC4288</em> <a class="iref" href="#rfc.xref.RFC4288.1">10.3</a>, <a class="iref" href="#RFC4288"><b>13.2</b></a></li> 3447 3511 <li class="indline1"><em>RFC4395</em> <a class="iref" href="#rfc.xref.RFC4395.1">10.2</a>, <a class="iref" href="#RFC4395"><b>13.2</b></a></li> 3448 <li class="indline1"><em>RFC5226</em> <a class="iref" href="#rfc.xref.RFC5226.1">6.2.3</a>, <a class="iref" href="# RFC5226"><b>13.2</b></a><ul class="ind">3449 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.RFC5226.1">6.2.3</a> </li>3512 <li class="indline1"><em>RFC5226</em> <a class="iref" href="#rfc.xref.RFC5226.1">6.2.3</a>, <a class="iref" href="#rfc.xref.RFC5226.2">9.8.1</a>, <a class="iref" href="#RFC5226"><b>13.2</b></a><ul class="ind"> 3513 <li class="indline1"><em>Section 4.1</em> <a class="iref" href="#rfc.xref.RFC5226.1">6.2.3</a>, <a class="iref" href="#rfc.xref.RFC5226.2">9.8.1</a></li> 3450 3514 </ul> 3451 3515 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r680 r684 48 48 <?rfc-ext allow-markup-in-artwork="yes" ?> 49 49 <?rfc-ext include-references-in-index="yes" ?> 50 <rfc obsoletes="2616" category="std" x:maturity-level="draft"50 <rfc obsoletes="2616" updates="2817" category="std" x:maturity-level="draft" 51 51 ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p1-messaging-&ID-VERSION;" 52 52 xmlns:x='http://purl.org/net/xml2rfc/ext'> … … 2931 2931 the family of Hypertext Transfer Protocols, as defined by the HTTP 2932 2932 version rules of <xref target="http.version"/> and future updates to this 2933 specification. Any token can be used as a protocol name; however, it 2934 will only be useful if both the client and server associate the name 2935 with the same protocol. 2936 </t> 2933 specification. Additional tokens can be registered with IANA using the 2934 registration procedure defined below. 2935 </t> 2936 2937 <section title="Upgrade Token Registry" anchor="upgrade.token.registry"> 2938 <t> 2939 The HTTP Upgrade Token Registry defines the name space for product 2940 tokens used to identify protocols in the Upgrade header field. 2941 Each registered token should be associated with one or a set of 2942 specifications, and with contact information. 2943 </t> 2944 <t> 2945 Registrations should be allowed on a First Come First Served basis as 2946 described in <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>. These 2947 specifications need not be IETF documents or be subject to IESG review, but 2948 should obey the following rules: 2949 <list style="numbers"> 2950 <t>A token, once registered, stays registered forever.</t> 2951 <t>The registration &MUST; name a responsible party for the 2952 registration.</t> 2953 <t>The registration &MUST; name a point of contact.</t> 2954 <t>The registration &MAY; name the documentation required for the 2955 token.</t> 2956 <t>The responsible party &MAY; change the registration at any time. 2957 The IANA will keep a record of all such changes, and make them 2958 available upon request.</t> 2959 <t>The responsible party for the first registration of a "product" 2960 token &MUST; approve later registrations of a "version" token 2961 together with that "product" token before they can be registered.</t> 2962 <t>If absolutely required, the IESG &MAY; reassign the responsibility 2963 for a token. This will normally only be used in the case when a 2964 responsible party cannot be contacted.</t> 2965 </list> 2966 </t> 2967 <t> 2968 It is not required that specifications for upgrade tokens be made 2969 publicly available, but the contact information for the registration 2970 should be. 2971 </t> 2972 </section> 2973 2974 2937 2975 </section> 2938 2976 … … 3312 3350 </section> 3313 3351 3352 <section title="Upgrade Token Registration" anchor="upgrade.token.registration"> 3353 <t> 3354 The registration procedure for HTTP Upgrade Tokens -- previously defined 3355 in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/> -- is now defined 3356 by <xref target="upgrade.token.registry"/> of this document. 3357 </t> 3358 <t> 3359 The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-upgrade-tokens/"/> 3360 should be updated with the registration below: 3361 </t> 3362 <texttable align="left" suppress-title="true"> 3363 <ttcol>Value</ttcol> 3364 <ttcol>Description</ttcol> 3365 <ttcol>Reference</ttcol> 3366 3367 <c>HTTP</c> 3368 <c>Hypertext Transfer Protocol</c> 3369 <c><xref target="http.version"/> of this specification</c> 3370 <!-- IANA should add this without our instructions; emailed on June 05, 2009 3371 <c>TLS/1.0</c> 3372 <c>Transport Layer Security</c> 3373 <c><xref target="RFC2817"/></c> --> 3374 3375 </texttable> 3376 </section> 3377 3314 3378 </section> 3315 3379 … … 4112 4176 </reference> 4113 4177 4178 <reference anchor='RFC2817'> 4179 <front> 4180 <title>Upgrading to TLS Within HTTP/1.1</title> 4181 <author initials='R.' surname='Khare' fullname='R. Khare'> 4182 <organization>4K Associates / UC Irvine</organization> 4183 <address><email>rohit@4K-associates.com</email></address> 4184 </author> 4185 <author initials='S.' surname='Lawrence' fullname='S. Lawrence'> 4186 <organization>Agranat Systems, Inc.</organization> 4187 <address><email>lawrence@agranat.com</email></address> 4188 </author> 4189 <date year='2000' month='May' /> 4190 </front> 4191 <seriesInfo name='RFC' value='2817' /> 4192 </reference> 4193 4114 4194 <reference anchor='RFC2818'> 4115 4195 <front> … … 5178 5258 </t> 5179 5259 <t> 5260 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/172"/>: 5261 "take over HTTP Upgrade Token Registry" 5262 </t> 5263 <t> 5180 5264 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/188"/>: 5181 5265 "pick IANA policy (RFC5226) for Transfer Coding / Content Coding"
Note: See TracChangeset
for help on using the changeset viewer.