Changeset 684 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

Aug 16, 2009, 3:41:56 AM (10 years ago)

Author:

julian.reschke@…

Message:

take over HTTP Upgrade Token Registry (see #172)

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (5 diffs)

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

@@ -48 +48 @@
 <?rfc-ext allow-markup-in-artwork="yes" ?>
 <?rfc-ext include-references-in-index="yes" ?>
-<rfc obsoletes="2616" category="std" x:maturity-level="draft"
+<rfc obsoletes="2616" updates="2817" category="std" x:maturity-level="draft"
      ipr="pre5378Trust200902" docName="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"
      xmlns:x='http://purl.org/net/xml2rfc/ext'>
@@ -2931 +2931 @@
    the family of Hypertext Transfer Protocols, as defined by the HTTP
    version rules of <xref target="http.version"/> and future updates to this
-   specification. Any token can be used as a protocol name; however, it
-   will only be useful if both the client and server associate the name
-   with the same protocol.
-</t>
+   specification. Additional tokens can be registered with IANA using the
+   registration procedure defined below.  
+</t>
+
+<section title="Upgrade Token Registry" anchor="upgrade.token.registry">
+<t>
+   The HTTP Upgrade Token Registry defines the name space for product
+   tokens used to identify protocols in the Upgrade header field.
+   Each registered token should be associated with one or a set of
+   specifications, and with contact information.
+</t>
+<t>
+   Registrations should be allowed on a First Come First Served basis as
+   described in <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>. These
+   specifications need not be IETF documents or be subject to IESG review, but
+   should obey the following rules:
+  <list style="numbers">
+    <t>A token, once registered, stays registered forever.</t>
+    <t>The registration &MUST; name a responsible party for the
+       registration.</t>
+    <t>The registration &MUST; name a point of contact.</t>
+    <t>The registration &MAY; name the documentation required for the
+       token.</t>
+    <t>The responsible party &MAY; change the registration at any time.
+       The IANA will keep a record of all such changes, and make them
+       available upon request.</t>
+    <t>The responsible party for the first registration of a "product"
+       token &MUST; approve later registrations of a "version" token
+       together with that "product" token before they can be registered.</t>
+    <t>If absolutely required, the IESG &MAY; reassign the responsibility
+       for a token. This will normally only be used in the case when a
+       responsible party cannot be contacted.</t>
+  </list>
+</t>
+<t>
+   It is not required that specifications for upgrade tokens be made
+   publicly available, but the contact information for the registration
+   should be.
+</t>
+</section>
+
+
 </section>
 
@@ -3312 +3350 @@
 </section>
 
+<section title="Upgrade Token Registration" anchor="upgrade.token.registration">
+<t>
+   The registration procedure for HTTP Upgrade Tokens -- previously defined
+   in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/> -- is now defined
+   by <xref target="upgrade.token.registry"/> of this document.
+</t>
+<t>
+   The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-upgrade-tokens/"/>
+   should be updated with the registration below:
+</t>
+<texttable align="left" suppress-title="true">
+   <ttcol>Value</ttcol>
+   <ttcol>Description</ttcol>
+   <ttcol>Reference</ttcol>
+
+   <c>HTTP</c>
+   <c>Hypertext Transfer Protocol</c> 
+   <c><xref target="http.version"/> of this specification</c>
+<!-- IANA should add this without our instructions; emailed on June 05, 2009
+   <c>TLS/1.0</c>
+   <c>Transport Layer Security</c> 
+   <c><xref target="RFC2817"/></c> -->
+
+</texttable>
+</section>
+
 </section>
 
@@ -4112 +4176 @@
 </reference>
 
+<reference anchor='RFC2817'>
+  <front>
+    <title>Upgrading to TLS Within HTTP/1.1</title>
+    <author initials='R.' surname='Khare' fullname='R. Khare'>
+      <organization>4K Associates / UC Irvine</organization>
+      <address><email>rohit@4K-associates.com</email></address>
+    </author>
+    <author initials='S.' surname='Lawrence' fullname='S. Lawrence'>
+      <organization>Agranat Systems, Inc.</organization>
+      <address><email>lawrence@agranat.com</email></address>
+    </author>
+    <date year='2000' month='May' />
+  </front>
+  <seriesInfo name='RFC' value='2817' />
+</reference>
+
 <reference anchor='RFC2818'>
   <front>
@@ -5178 +5258 @@
     </t>
     <t>
+      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/172"/>:
+      "take over HTTP Upgrade Token Registry"
+    </t>
+    <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/188"/>:
       "pick IANA policy (RFC5226) for Transfer Coding / Content Coding"