* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #172: 172.diff

File 172.diff, 5.4 KB (added by julian.reschke@gmx.de, 7 years ago)

Proposed patch for part 1.

  • p1-messaging.xml

    4747<?rfc inline="yes"?> 
    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'> 
    29302930   This specification only defines the protocol name "HTTP" for use by 
    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. 
     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. 
    29392977<section title="Via" anchor="header.via"> 
    29402978  <iref primary="true" item="Via header" x:for-anchor=""/> 
    29412979  <iref primary="true" item="Headers" subitem="Via" x:for-anchor=""/> 
     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 registrations 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> --> 
    33163380<section title="Security Considerations" anchor="security.considerations"> 
    33183382   This section is meant to inform application developers, information 
    41114175  <seriesInfo name="RFC" value="2616"/> 
     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> 
    41164196    <title>HTTP Over TLS</title> 
    51775257      "IP addresses in URLs" 
    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" 
    51825266    </t>