<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "../Tools/rfcbootstrap/rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc ipr="trust200902" docName="draft-nottingham-httpbis-header-registry-00" category="std" updates="3864, 7231">

  <front>
    <title abbrev="HTTP Header Registry">A Registry for HTTP Header Fields</title>

    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization></organization>
      <address>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>

    <date year="2018"/>

    <area>General</area>
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document defines a separate IANA registry for HTTP header fields, and establishes the procedures for its operation.</t>



    </abstract>


    <note title="Note to Readers">


<t>The issues list for this draft can be found at <eref target="https://github.com/mnot/I-D/labels/httpbis-header-registry">https://github.com/mnot/I-D/labels/httpbis-header-registry</eref>.</t>

<t>The most recent (often, unpublished) draft is at <eref target="https://mnot.github.io/I-D/httpbis-header-registry/">https://mnot.github.io/I-D/httpbis-header-registry/</eref>.</t>

<t>Recent changes are listed at <eref target="https://github.com/mnot/I-D/commits/gh-pages/httpbis-header-registry">https://github.com/mnot/I-D/commits/gh-pages/httpbis-header-registry</eref>.</t>


    </note>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t><xref target="RFC3864"/> established common IANA registries for header fields from a variety of protocols.
Experience has shown that having a combined registry has few benefits, and creates a number of
issues, including:</t>

<t><list style="symbols">
  <t>Difficulty in evolving the registration process (without coordination with other protocols),</t>
  <t>Registry user confusion, due to the large number of header fields registered,</t>
  <t>Using one expert to review all header field registrations is onerous to that individual,</t>
  <t>Lack of HTTP community involvement / oversight in reviews.</t>
</list></t>

<t>While these issues could be mitigated by a RFC3864bis, it is more straightforward to separate the
HTTP registrations out into a separate registry; since there is only slight syntactic similarity
between header fields between protocols (and often, the mismatches create confusion), and little
semantic overlap, this seems like the best path forward.</t>

<t>Therefore, this document establishes a new HTTP Header Field Registry, defines its procedures, and
guides the transition of existing values to it. Doing so effectively removes HTTP header fields
from the scope of <xref target="RFC3864"/> and the registries it defines, and updates <xref target="RFC7231"/> Section 8.3
with a new process for managing them.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in
<xref target="RFC2119"/>.</t>

</section>
</section>
<section anchor="registry" title="The HTTP Header Field Registry">

<t>The “Hypertext Transfer Protocol (HTTP) Header Field Registry” defines the namespace for HTTP
header fields (as per <xref target="RFC7230"/>, Section 3.2).</t>

<section anchor="requesting-registration" title="Requesting Registration">

<t>Any party can request registration of a HTTP header field. See <xref target="RFC7231"/> Section 8.3.1 for
considerations to take into account when creating a new HTTP header field.</t>

<t>The “HTTP Header Field Name” registry is located at “https://www.iana.org/assignments/http-headers/”.
Registration requests can be made by following the instructions located there or by sending an
email to the “ietf-http-wg@ietf.org” mailing list.</t>

<t>Header field names are registered on the advice of a Designated Expert (appointed by the IESG or
their delegate). Header fields with the status ‘permanent’ are Specification Required (using
terminology from <xref target="RFC8126"/>).</t>

<t>Registration requests consist of at least the following information:</t>

<t><list style="symbols">
  <t><spanx style="strong">Header field name</spanx>: The requested field name. It MUST conform to the field-name syntax defined
in <xref target="RFC7230"/>, Section 3.2, and SHOULD be restricted to just letters, digits, hyphen (‘-‘) and
underscore (‘_’) characters, with the first character being a letter.</t>
  <t><spanx style="strong">Status</spanx>: “permanent” or “provisional”</t>
  <t><spanx style="strong">Author/Change controller</spanx>: For a standards-track RFC, state “IETF”. For other open standards,
give the name of the publishing body (e.g., “W3C”). For other specifications, give the name
and/or organisation name and e-mail address of the primary specification author.</t>
  <t><spanx style="strong">Specification document(s)</spanx>: Reference to the document that specifies the header field,
preferably including a URI that can be used to retrieve a copy of the document. An indication of
the relevant section(s) can also be included, but is not required.</t>
</list></t>

<t>The Expert(s) can define additional fields to be collected in the registry, in consultation with
the community.</t>

<t>Standards-defined names have a status of “permanent”. Other names can also be registered as permanent, if the Expert(s) find that they are in use, in consultation with the community. Other names should be registered as “provisional”.</t>

<t>Provisional entries can be removed by the Expert(s) if – in consultation with the community – the Expert(s) find that they are not in use. The Experts can change a provisional entry’s status to permanent at any time.</t>

<t>Note that names can be registered by third parties (including the Expert(s)), if the Expert(s)
determines that an unregistered name is widely deployed and not likely to be registered in a timely
manner otherwise.</t>

</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<section anchor="registry-creation" title="Registry Creation">

<t>IANA will create a new registry as outlined in <xref target="registry"/>.</t>

<t>After creating the registry, all entries in the Permanent and Provisional Message Header Registries
with the protocol ‘http’ are to be moved to it, with the following changes applied:</t>

<t><list style="numbers">
  <t>The ‘Applicable Protocol’ field is to be omitted.</t>
  <t>Entries with a status of ‘standard’, ‘experimental’, or ‘informational’ are to have a status of
‘permanent’.</t>
  <t>Entries with a status of ‘deprecated’ are to have a status of ‘obsoleted’.</t>
  <t>Provisional entries without a status are to have a status of ‘provisional’.</t>
  <t>Permanent entries without a status (after confirmation that the registration document did not define one) will have a status of ‘provisional’. The Expert(s) can choose to update their status if there is evidence that another is more appropriate.</t>
</list></t>

<t>The Permanent and Provisional Message Header registries will be annotated to indicate that HTTP
header field registrations have moved, with an appropriate link.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>No security considerations are introduced by this specification beyond those already inherent in
the use of HTTP header fields.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC8126" target='https://www.rfc-editor.org/info/rfc8126'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='M.' surname='Cotton' fullname='M. Cotton'><organization /></author>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<author initials='T.' surname='Narten' fullname='T. Narten'><organization /></author>
<date year='2017' month='June' />
<abstract><t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t><t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t><t>This is the third edition of this document; it obsoletes RFC 5226.</t></abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>



<reference  anchor="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC3864" target='https://www.rfc-editor.org/info/rfc3864'>
<front>
<title>Registration Procedures for Message Header Fields</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'><organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></author>
<date year='2004' month='September' />
<abstract><t>This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='90'/>
<seriesInfo name='RFC' value='3864'/>
<seriesInfo name='DOI' value='10.17487/RFC3864'/>
</reference>



<reference  anchor="RFC7231" target='https://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIAIQY4FsAA41Y23LbyBF9n6+Y0A+kXCSoy2bjZVLJqiR5pSpLciS5tlKp
lGsIDMmJwBkGA5BmtvTvOd0zuOmyjh9kEMD09fTpbkwmE1GaMtczeSrv9NL4
stjLhSvk5cPDZ3mpVaYL+dHoPPNCzeeF3s56j+ozInOpVWvIyQq1KCfWlaWx
y5VaT1ZluZkbP1nxiUkRT0wOD0WmSpw4Pjz6IFJcLl2xn0lfZqLa0CM/kycf
fvxhLP90fHIkhNkUM1kWlS+PDw9/OjwWqtBqJn/RVhcqFztXPC4LV21m4lHv
8SubyStb6sLqcnJOVgnhS2Wzryp3Fnr32ouNmcl/li4dS/wxNtO2HEvvirLQ
C4+r/TpelIVJ8Sh1642KF2u8jEfG5sbqfwmhqnLlipmQEyHxz1jYf53ImyYU
fDtE6VoVj8+fuGKprPmvKo2zM76j18rkM7lGNH+mPwlc4QdVAbspsH42ne52
u6R+OhXCumINGVtNMu4+nh0fHf00Q/Tson0gxGQykWoOt+CNEA8r4yVSWJFP
MtMLeOSlkl5vVIFMyKvTm1NZvABIyKlcMEDGEsGVGjGe58avIKBcabkpXKqz
qsBPOmZKL90GCSMvk2AHbNdfb+hP6b7esUhPNmlpvK9wEOJKPl2ynZRLmSor
5xp3KyhVpfxLHY6lKVfVPEGCphSV6dXkfJqruc799A0o/jUJ2tYOagqdUgxG
blFqO5aV3VTBnewgaoYJXX0c+qjUOFb3hp4pKboL8tOVskuKcaHZPf19Jwhy
CN90uZpsFM7+njsc17XJslwL8Y7qoHBZlVLQhfjtt78BF1RaT0+dfGUMamd7
yTYxb71My0Xh1oDHVuF5uZduQWlGBbncJ+LiG/JrtE21XCkv/crtLDIH91Zq
C7zjIBTNAbGshRS9udA7pNQCfWUEU4oKLxmJtlrPod8tRMAE1V2aVxnkAc7v
5blZLExa5bDGWKm3LmdVhMCogxEX4Oi9HO0QYVchEQ5MYWx4Sjelw6Gidehg
TPIbcqw8HqbOLiqPE2OZVRrcwYpyVSx1a+mzmAUzdKEzFvjFk30gIqkpXiUJ
Ab0axEDlee9szwNP+MMxMJ0PihFYMJfZmqxSOcv+pNJHMoBrlJJaWcOBobBo
rvGpdFuUmVmu6HTUjOSJX1cm1+SOb8ovdRWMQLEBfmapCKvzPXISQQQIIhtc
F2sHOJOlJBew2akiIyMbHoFcwVb1XaJEGIsXO5RTQ+PPEpFK+Wihg/P5Xvqc
Tfd7W4LBTIqX1gYJgJ9irsud1vZZ/Ou7TWLliCAW65zytzYeBJkScwXgtXk+
CHjMTYlmKTyI2ZJSimGuNuNATF7rNZHVIxsLhaCTjQKiYiQCzaChIErxSMO5
XdoE2oGCFx24weC4YWhi05Zg2UaxrEwWuRfxtd4wsoEG/Q2nCXRblVNaEW5T
JvLc0T3vpF4sdEr9AeEt9Bq++VdYXnDtk3SfgshJcI9PKEydqjNsZW1wiGLs
7vEcNXecu9fMTvJDciK4DEMU6nolDkLQ1TJW9ZpI7t076qGMIZXLM2e3CCUB
KvA5xgBJc4CXg+sv9w+Dcfhf3tzy9d3F379c3V2c0/X95emnT81F/cb95e2X
T+ftVbgvcPLs9vr64uY8HL4+/ccgeDa4/fxwdXtz+mlARdXPMDE9Qo4yMjSV
bArNpI83tE8LM8cPY8HNf4g9++mJXZTkydtYkL+9qwvlKXg9uNwTn+hvpXyg
/C9w5nPEvByRpIPXRQ0aWFH+aE7xmHV00+1Fv55GMB2KkMWQxMOnp3GTxZPk
+CBm6E7/B2hj4N11il6IU7tHeRQgJurlRXitz9YAl3qJwQRq9JvoSY7IYoHS
9SiEmmGIKdWjjiyTgtKQkt0KfMClHtpSU3Y9bXVYX+TgBiEatC0Myc5dqmIr
H3THMwPkJpjvpsqDci1Pjty+Y+/200EiutGpw+HrOWeN14h1Fy7P3a5ubZgx
MRCnwcVaeSBKJA2ve20z9s0KHibrVjVA317waD7ZLX+mH2TeQNI79D6NJHD8
stuFGBEM47aVgYxZnsq2JtUhX+eafGRTLkJrG6nNxhHquXHQ+1cX97/ARIFr
UwB3uaa+cpDIyx7GmAiYa1Dl6HdDiAMLIHxDNuR+o1ODvh9iRkgzZNSoouYq
YOHaWJe75T5MLKG4Phwd//j0dMCz2KsRJ+QAieRMKXOtcE02tKFvZmka1NFv
379/Eaj372dcuVEqjGqfJfKqlMxE1F8gqc4KvzKhV0Jj+xYrMhO0TkTzXym1
QD6Ro+akNOwrmpvvv7ExwY0S4QABZ2bJ49VqvyH0j4aT4QH3DWwVlqCYUg8f
Db/iNoZU2g/4XJOKhSl82T6CvlA8QUMS4nHP+aIgDJqUDQiTAxD61nhm7EF4
95T3pukZT8QUEsyqea4LOv0RR5TktQ0N1E9oX3mkwWPMkACQry4ePg4SfjEM
bmhKtj0xhl9L9LSG0yitvJeEsZ5sn7tsL0c6WSYg819PzgYHXXm+izEEoicN
0qFoSi/z9uYDllgRb0MTrjqVZQV1sVp3YdYKjNETLcP+WAew96huIiN/QFG5
0yB1HrAjcJomw9NgFBuJvMtlFA00HpzGsLFvR2jE+MvdVTgdCQdzbhZmUmri
cJmm9s2+dqHWmMhTy+NnWjM2VIT+n+stpiRQEOMUprNolfvYBEk3hmE5r3h2
xJrD1UIVHDk30Ed9MtQCxdLEjh9ZInTVlEDDmDe2O4HsaVXgosZ20I75RD3t
bAyF9w3IYtFFwsPSogMGiYHgfgfRibxljIQ3u+51KDL0yXACtoT4ta5BVxYi
j/t7pjXYi/C/brfs290zAKtWnNT76ntFB1c/tz8ljOIhLaY9DH4NT7dmwm6s
lN+3iN76roOU6+BkIttEByPCZoyIb55ZuR/6OgvIeBNSImmFUaI0YFYh6DtC
0NYmpR8Qds1gMaHhg1wftXXQs/zgZbZEpkNX4eJizaDNjnCufEOdK6M5OtOb
3O0pC4gBeU3bAe6Xz0GCaCh2Id8L+GV1pJ+d8eQVL/G0lp/1xpo4YMUB5Iwn
GRqt+NWdwR4ZF5kw2zSjiuKVK2eUc2NpZkgaOk8XxOvNXNSvJVpOa8zEQvvc
pgJedsF1DdJTSGb/ayGOigY49TomhzSNDDtjcgAibynd9tN04eYTymaTG52h
Ex8FNA1P6U4KitPN5DuM/dfUdOGwzJbENMeJvIj+xL2jLfVh3UeGYznkPd0Q
6akcv8H5w84ggHu17c8Zgz7ZdSaXRJz8nkpAptA8yb0pUA7d3LucFghI+yGR
rxV0/YGjOfemsE6hQdwfk05C3xQ2UgEkGGBMjEBT4/0Zvv2saEIJRB53Vh8E
jH7HIvmyFaQr5zx7E3ZJGebIKCEUbfhYoLeolvD5gKs19PT6UwWgUzh0Y4iI
Lef/xnJnv2Un5tTwLW2jEbShJ0bFL/anZx9AOAQM+Ah1aiWtcaAN+xhpAHNf
RZ85XlDBDX1nic+ebT+hqYRvgA0D+mfzx1zvHTM1hVblKP+MRgSKpCW65o4J
ym6+LPX2wfgtd475TPwPul4a+lcYAAA=

-->

</rfc>

