Ignore:
Timestamp:
Mar 11, 2012, 10:00:28 PM (8 years ago)
Author:
fielding@…
Message:

Move the IANA registry definitions to IANA considerations and
make them a bit more readable. Add responsible party and
expected versions to the HTTP token registration.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1583 r1584  
    19441944</artwork></figure>
    19451945<t>
    1946    All transfer-coding values are case-insensitive. HTTP/1.1 uses
    1947    transfer-coding values in the TE header field (<xref target="header.te"/>) and in
    1948    the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
     1946   All transfer-coding values are case-insensitive.
     1947   The HTTP Transfer Coding registry is defined in
     1948   <xref target="transfer.coding.registry"/>.
     1949   HTTP/1.1 uses transfer-coding values in the TE header field
     1950   (<xref target="header.te"/>) and in the Transfer-Encoding header field
     1951   (<xref target="header.transfer-encoding"/>).
    19491952</t>
    19501953
     
    21122115</section>
    21132116
    2114 </section>
    2115 
    2116 <section title="Transfer Coding Registry" anchor="transfer.coding.registry">
    2117 <t>
    2118    The HTTP Transfer Coding Registry defines the name space for the transfer
    2119    coding names.
    2120 </t>
    2121 <t>
    2122    Registrations &MUST; include the following fields:
    2123    <list style="symbols">
    2124      <t>Name</t>
    2125      <t>Description</t>
    2126      <t>Pointer to specification text</t>
    2127    </list>
    2128 </t>
    2129 <t>
    2130    Names of transfer codings &MUST-NOT; overlap with names of content codings
    2131    (&content-codings;), unless the encoding transformation is identical (as it
    2132    is the case for the compression codings defined in
    2133    <xref target="compression.codings"/>).
    2134 </t>
    2135 <t>
    2136    Values to be added to this name space require IETF Review (see
    2137    <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;
    2138    conform to the purpose of transfer coding defined in this section.
    2139 </t>
    2140 <t>
    2141    The registry itself is maintained at
    2142    <eref target="http://www.iana.org/assignments/http-parameters"/>.
    2143 </t>
    21442117</section>
    21452118
     
    33953368   version rules of <xref target="http.version"/> and future updates to this
    33963369   specification. Additional tokens can be registered with IANA using the
    3397    registration procedure defined below. 
    3398 </t>
    3399 
    3400 <section title="Upgrade Token Registry" anchor="upgrade.token.registry">
    3401 <t>
    3402    The HTTP Upgrade Token Registry defines the name space for protocol-name
    3403    tokens used to identify protocols in the Upgrade header field.
    3404    Each registered protocol-name is associated with contact information and
    3405    an optional set of specifications that details how the connection
    3406    will be processed after it has been upgraded.
    3407 </t>
    3408 <t>
    3409    Registrations require IETF Review (see
    3410    <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>) and are subject to the
    3411    following rules:
    3412   <list style="numbers">
    3413     <t>A protocol-name token, once registered, stays registered forever.</t>
    3414     <t>The registration &MUST; name a responsible party for the
    3415        registration.</t>
    3416     <t>The registration &MUST; name a point of contact.</t>
    3417     <t>The registration &MAY; name a set of specifications associated with
    3418        that token. Such specifications need not be publicly available.</t>
    3419     <t>The registration &SHOULD; name a set of expected "protocol-version"
    3420        tokens associated with that token at the time of registration.</t>
    3421     <t>The responsible party &MAY; change the registration at any time.
    3422        The IANA will keep a record of all such changes, and make them
    3423        available upon request.</t>
    3424     <t>The IESG &MAY; reassign responsibility for a protocol token.
    3425        This will normally only be used in the case when a
    3426        responsible party cannot be contacted.</t>
    3427   </list>
    3428 </t>
    3429 </section>
     3370   registration procedure defined in <xref target="upgrade.token.registry"/>.
     3371</t>
    34303372</section>
    34313373
     
    34363378<section title="Header Field Registration" anchor="header.field.registration">
    34373379<t>
    3438    The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated
    3439    with the permanent registrations below (see <xref target="RFC3864"/>):
     3380   HTTP header fields are registered within the Message Header Field Registry
     3381   <xref target="RFC3864"/> maintained by IANA at
     3382   <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>.
     3383</t>
     3384<t>
     3385   This document defines the following HTTP header fields, so their
     3386   associated registry entries shall be updated according to the permanent
     3387   registrations below:
    34403388</t>
    34413389<?BEGININC p1-messaging.iana-headers ?>
     
    34993447<?ENDINC p1-messaging.iana-headers ?>
    35003448<t>
    3501    Furthermore, the header field name "Close" shall be registered as "reserved", as its use as
    3502    HTTP header field would be in conflict with the use of the "close" connection
    3503    option for the "Connection" header field (<xref target="header.connection"/>).
     3449   Furthermore, the header field-name "Close" shall be registered as
     3450   "reserved", since using that name as an HTTP header field might
     3451   conflict with the "close" connection option of the "Connection"
     3452   header field (<xref target="header.connection"/>).
    35043453</t>
    35053454<texttable align="left" suppress-title="true">
     
    35233472<section title="URI Scheme Registration" anchor="uri.scheme.registration">
    35243473<t>
    3525    The entries for the "http" and "https" URI Schemes in the registry located at
    3526    <eref target="http://www.iana.org/assignments/uri-schemes.html"/>
    3527    shall be updated to point to Sections <xref target="http.uri" format="counter"/>
    3528    and <xref target="https.uri" format="counter"/> of this document
    3529    (see <xref target="RFC4395"/>).
    3530 </t>
     3474   IANA maintains the registry of URI Schemes <xref target="RFC4395"/> at
     3475   <eref target="http://www.iana.org/assignments/uri-schemes.html"/>.
     3476</t>
     3477<t>
     3478   This document defines the following URI schemes, so their
     3479   associated registry entries shall be updated according to the permanent
     3480   registrations below:
     3481</t>
     3482<texttable align="left" suppress-title="true">
     3483   <ttcol>URI Scheme</ttcol>
     3484   <ttcol>Description</ttcol>
     3485   <ttcol>Reference</ttcol>
     3486
     3487   <c>http</c>
     3488   <c>Hypertext Transfer Protocol</c>
     3489   <c><xref target="http.uri"/></c>
     3490
     3491   <c>https</c>
     3492   <c>Hypertext Transfer Protocol Secure</c>
     3493   <c><xref target="https.uri"/></c>
     3494</texttable>
    35313495</section>
    35323496
     
    36813645</section>
    36823646
    3683 <section title="Transfer Coding Registry" anchor="transfer.coding.registration">
    3684 <t>
    3685    The registration procedure for HTTP Transfer Codings is now defined by
    3686    <xref target="transfer.coding.registry"/> of this document.
    3687 </t>
    3688 <t>
    3689    The HTTP Transfer Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/>
    3690    shall be updated with the registrations below:
     3647<section title="Transfer Coding Registry" anchor="transfer.coding.registry">
     3648<t>
     3649   The HTTP Transfer Coding Registry defines the name space for transfer
     3650   coding names.
     3651</t>
     3652<t>
     3653   Registrations &MUST; include the following fields:
     3654   <list style="symbols">
     3655     <t>Name</t>
     3656     <t>Description</t>
     3657     <t>Pointer to specification text</t>
     3658   </list>
     3659</t>
     3660<t>
     3661   Names of transfer codings &MUST-NOT; overlap with names of content codings
     3662   (&content-codings;) unless the encoding transformation is identical, as it
     3663   is the case for the compression codings defined in
     3664   <xref target="compression.codings"/>.
     3665</t>
     3666<t>
     3667   Values to be added to this name space require IETF Review (see
     3668   <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;
     3669   conform to the purpose of transfer coding defined in this section.
     3670</t>
     3671<t>
     3672   The registry itself is maintained at
     3673   <eref target="http://www.iana.org/assignments/http-parameters"/>.
     3674</t>
     3675</section>
     3676
     3677<section title="Transfer Coding Registrations" anchor="transfer.coding.registration">
     3678<t>
     3679   The HTTP Transfer Coding Registry shall be updated with the registrations
     3680   below:
    36913681</t>
    36923682<texttable align="left" suppress-title="true" anchor="iana.transfer.coding.registration.table">
     
    37193709</section>
    37203710
     3711<section title="Upgrade Token Registry" anchor="upgrade.token.registry">
     3712<t>
     3713   The HTTP Upgrade Token Registry defines the name space for protocol-name
     3714   tokens used to identify protocols in the Upgrade header field.
     3715   Each registered protocol-name is associated with contact information and
     3716   an optional set of specifications that details how the connection
     3717   will be processed after it has been upgraded.
     3718</t>
     3719<t>
     3720   Registrations require IETF Review (see
     3721   <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>) and are subject to the
     3722   following rules:
     3723  <list style="numbers">
     3724    <t>A protocol-name token, once registered, stays registered forever.</t>
     3725    <t>The registration &MUST; name a responsible party for the
     3726       registration.</t>
     3727    <t>The registration &MUST; name a point of contact.</t>
     3728    <t>The registration &MAY; name a set of specifications associated with
     3729       that token. Such specifications need not be publicly available.</t>
     3730    <t>The registration &SHOULD; name a set of expected "protocol-version"
     3731       tokens associated with that token at the time of registration.</t>
     3732    <t>The responsible party &MAY; change the registration at any time.
     3733       The IANA will keep a record of all such changes, and make them
     3734       available upon request.</t>
     3735    <t>The IESG &MAY; reassign responsibility for a protocol token.
     3736       This will normally only be used in the case when a
     3737       responsible party cannot be contacted.</t>
     3738  </list>
     3739</t>
     3740<t>
     3741   This registration procedure for HTTP Upgrade Tokens replaces that
     3742   previously defined in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/>.
     3743</t>
     3744</section>
     3745
    37213746<section title="Upgrade Token Registration" anchor="upgrade.token.registration">
    37223747<t>
    3723    The registration procedure for HTTP Upgrade Tokens &mdash; previously defined
    3724    in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/> &mdash; is now defined
    3725    by <xref target="upgrade.token.registry"/> of this document.
    3726 </t>
    3727 <t>
    3728    The HTTP Upgrade Token Registry located at <eref target="http://www.iana.org/assignments/http-upgrade-tokens/"/>
    3729    shall be updated with the registration below:
     3748   The HTTP Upgrade Token Registry shall be updated with the registration
     3749   below:
    37303750</t>
    37313751<texttable align="left" suppress-title="true">
    37323752   <ttcol>Value</ttcol>
    37333753   <ttcol>Description</ttcol>
     3754   <ttcol>Expected Version Tokens</ttcol>
    37343755   <ttcol>Reference</ttcol>
    37353756
    37363757   <c>HTTP</c>
    3737    <c>Hypertext Transfer Protocol</c> 
    3738    <c><xref target="http.version"/> of this specification</c>
    3739 
     3758   <c>Hypertext Transfer Protocol</c>
     3759   <c>any DIGIT.DIGIT (e.g, "2.0")</c>
     3760   <c><xref target="http.version"/></c>
    37403761</texttable>
     3762<t>
     3763   The responsible party is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
     3764</t>
    37413765</section>
    37423766
Note: See TracChangeset for help on using the changeset viewer.