16/08/09 10:41:56 (13 years ago)

take over HTTP Upgrade Token Registry (see #172)

1 edited


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

    r680 r684  
    4848<?rfc-ext allow-markup-in-artwork="yes" ?>
    4949<?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"
    5151     ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"
    5252     xmlns:x='http://purl.org/net/xml2rfc/ext'>
    29312931   the family of Hypertext Transfer Protocols, as defined by the HTTP
    29322932   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. 
     2937<section title="Upgrade Token Registry" anchor="upgrade.token.registry">
     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.
     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>
     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.
     3352<section title="Upgrade Token Registration" anchor="upgrade.token.registration">
     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.
     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:
     3362<texttable align="left" suppress-title="true">
     3363   <ttcol>Value</ttcol>
     3364   <ttcol>Description</ttcol>
     3365   <ttcol>Reference</ttcol>
     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> -->
     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' />
    41144194<reference anchor='RFC2818'>
    41154195  <front>
    51785258    </t>
    51795259    <t>
     5260      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/172"/>:
     5261      "take over HTTP Upgrade Token Registry"
     5262    </t>
     5263    <t>
    51805264      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/188"/>:
    51815265      "pick IANA policy (RFC5226) for Transfer Coding / Content Coding"
Note: See TracChangeset for help on using the changeset viewer.