idnits 2.17.1 draft-nottingham-httpbis-header-registry-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC3864, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7231, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3864, updated by this document, for RFC5378 checks: 2001-09-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 5, 2018) is 1999 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 239 -- Looks like a reference, but probably isn't: '2' on line 241 -- Looks like a reference, but probably isn't: '3' on line 243 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft November 5, 2018 4 Updates: 3864, 7231 (if approved) 5 Intended status: Standards Track 6 Expires: May 9, 2019 8 A Registry for HTTP Header Fields 9 draft-nottingham-httpbis-header-registry-00 11 Abstract 13 This document defines a separate IANA registry for HTTP header 14 fields, and establishes the procedures for its operation. 16 Note to Readers 18 The issues list for this draft can be found at 19 https://github.com/mnot/I-D/labels/httpbis-header-registry [1]. 21 The most recent (often, unpublished) draft is at 22 https://mnot.github.io/I-D/httpbis-header-registry/ [2]. 24 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 25 pages/httpbis-header-registry [3]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 9, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 63 2. The HTTP Header Field Registry . . . . . . . . . . . . . . . 3 64 2.1. Requesting Registration . . . . . . . . . . . . . . . . . 3 65 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Registry Creation . . . . . . . . . . . . . . . . . . . . 4 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 70 5.2. Informative References . . . . . . . . . . . . . . . . . 5 71 5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 [RFC3864] established common IANA registries for header fields from a 77 variety of protocols. Experience has shown that having a combined 78 registry has few benefits, and creates a number of issues, including: 80 o Difficulty in evolving the registration process (without 81 coordination with other protocols), 83 o Registry user confusion, due to the large number of header fields 84 registered, 86 o Using one expert to review all header field registrations is 87 onerous to that individual, 89 o Lack of HTTP community involvement / oversight in reviews. 91 While these issues could be mitigated by a RFC3864bis, it is more 92 straightforward to separate the HTTP registrations out into a 93 separate registry; since there is only slight syntactic similarity 94 between header fields between protocols (and often, the mismatches 95 create confusion), and little semantic overlap, this seems like the 96 best path forward. 98 Therefore, this document establishes a new HTTP Header Field 99 Registry, defines its procedures, and guides the transition of 100 existing values to it. Doing so effectively removes HTTP header 101 fields from the scope of [RFC3864] and the registries it defines, and 102 updates [RFC7231] Section 8.3 with a new process for managing them. 104 1.1. Notational Conventions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. The HTTP Header Field Registry 112 The "Hypertext Transfer Protocol (HTTP) Header Field Registry" 113 defines the namespace for HTTP header fields (as per [RFC7230], 114 Section 3.2). 116 2.1. Requesting Registration 118 Any party can request registration of a HTTP header field. See 119 [RFC7231] Section 8.3.1 for considerations to take into account when 120 creating a new HTTP header field. 122 The "HTTP Header Field Name" registry is located at 123 "https://www.iana.org/assignments/http-headers/". Registration 124 requests can be made by following the instructions located there or 125 by sending an email to the "ietf-http-wg@ietf.org" mailing list. 127 Header field names are registered on the advice of a Designated 128 Expert (appointed by the IESG or their delegate). Header fields with 129 the status 'permanent' are Specification Required (using terminology 130 from [RFC8126]). 132 Registration requests consist of at least the following information: 134 o *Header field name*: The requested field name. It MUST conform to 135 the field-name syntax defined in [RFC7230], Section 3.2, and 136 SHOULD be restricted to just letters, digits, hyphen ('-') and 137 underscore ('_') characters, with the first character being a 138 letter. 140 o *Status*: "permanent" or "provisional" 142 o *Author/Change controller*: For a standards-track RFC, state 143 "IETF". For other open standards, give the name of the publishing 144 body (e.g., "W3C"). For other specifications, give the name and/ 145 or organisation name and e-mail address of the primary 146 specification author. 148 o *Specification document(s)*: Reference to the document that 149 specifies the header field, preferably including a URI that can be 150 used to retrieve a copy of the document. An indication of the 151 relevant section(s) can also be included, but is not required. 153 The Expert(s) can define additional fields to be collected in the 154 registry, in consultation with the community. 156 Standards-defined names have a status of "permanent". Other names 157 can also be registered as permanent, if the Expert(s) find that they 158 are in use, in consultation with the community. Other names should 159 be registered as "provisional". 161 Provisional entries can be removed by the Expert(s) if - in 162 consultation with the community - the Expert(s) find that they are 163 not in use. The Experts can change a provisional entry's status to 164 permanent at any time. 166 Note that names can be registered by third parties (including the 167 Expert(s)), if the Expert(s) determines that an unregistered name is 168 widely deployed and not likely to be registered in a timely manner 169 otherwise. 171 3. IANA Considerations 173 3.1. Registry Creation 175 IANA will create a new registry as outlined in Section 2. 177 After creating the registry, all entries in the Permanent and 178 Provisional Message Header Registries with the protocol 'http' are to 179 be moved to it, with the following changes applied: 181 1. The 'Applicable Protocol' field is to be omitted. 183 2. Entries with a status of 'standard', 'experimental', or 184 'informational' are to have a status of 'permanent'. 186 3. Entries with a status of 'deprecated' are to have a status of 187 'obsoleted'. 189 4. Provisional entries without a status are to have a status of 190 'provisional'. 192 5. Permanent entries without a status (after confirmation that the 193 registration document did not define one) will have a status of 194 'provisional'. The Expert(s) can choose to update their status 195 if there is evidence that another is more appropriate. 197 The Permanent and Provisional Message Header registries will be 198 annotated to indicate that HTTP header field registrations have 199 moved, with an appropriate link. 201 4. Security Considerations 203 No security considerations are introduced by this specification 204 beyond those already inherent in the use of HTTP header fields. 206 5. References 208 5.1. Normative References 210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 211 Requirement Levels", BCP 14, RFC 2119, 212 DOI 10.17487/RFC2119, March 1997, 213 . 215 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 216 Protocol (HTTP/1.1): Message Syntax and Routing", 217 RFC 7230, DOI 10.17487/RFC7230, June 2014, 218 . 220 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 221 Writing an IANA Considerations Section in RFCs", BCP 26, 222 RFC 8126, DOI 10.17487/RFC8126, June 2017, 223 . 225 5.2. Informative References 227 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 228 Procedures for Message Header Fields", BCP 90, RFC 3864, 229 DOI 10.17487/RFC3864, September 2004, 230 . 232 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 233 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 234 DOI 10.17487/RFC7231, June 2014, 235 . 237 5.3. URIs 239 [1] https://github.com/mnot/I-D/labels/httpbis-header-registry 241 [2] https://mnot.github.io/I-D/httpbis-header-registry/ 243 [3] https://github.com/mnot/I-D/commits/gh-pages/httpbis-header- 244 registry 246 Author's Address 248 Mark Nottingham 250 Email: mnot@mnot.net 251 URI: https://www.mnot.net/