idnits 2.17.1 draft-klyne-msghdr-registry-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 27, 2003) is 7487 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) == Unused Reference: '12' is defined on line 633, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 653, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 659, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 662, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 692, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 695, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 698, but no explicit reference was found in the text == Unused Reference: '33' is defined on line 704, but no explicit reference was found in the text == Unused Reference: '40' is defined on line 729, but no explicit reference was found in the text == Unused Reference: '44' is defined on line 749, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2822 (ref. '4') (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 1036 (ref. '5') (Obsoleted by RFC 5536, RFC 5537) -- Obsolete informational reference (is this intentional?): RFC 2141 (ref. '13') (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 2298 (ref. '19') (Obsoleted by RFC 3798) -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '23') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2421 (ref. '24') (Obsoleted by RFC 3801) -- Obsolete informational reference (is this intentional?): RFC 2518 (ref. '25') (Obsoleted by RFC 4918) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '27') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2617 (ref. '28') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. '32') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2910 (ref. '33') (Obsoleted by RFC 8010) -- Obsolete informational reference (is this intentional?): RFC 2965 (ref. '36') (Obsoleted by RFC 6265) == Outdated reference: A later version (-05) exists of draft-klyne-hdrreg-mail-01 == Outdated reference: A later version (-05) exists of draft-nottingham-hdrreg-http-00 Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Klyne 3 Internet-Draft Nine by Nine 4 Expires: April 26, 2004 M. Nottingham 5 BEA 6 J. Mogul 7 Compaq WRL 8 October 27, 2003 10 Registration procedures for message header fields 11 draft-klyne-msghdr-registry-07 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 26, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This specification defines registration procedures for the message 42 header fields used by Internet mail, HTTP, Netnews and other 43 applications. 45 Discussion of this document 47 Please send comments to . To subscribe, send a 48 message with body 'subscribe' to . 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Structure of this document . . . . . . . . . . . . . . . . . 4 54 1.2 Document terminology and conventions . . . . . . . . . . . . 4 55 2. Message header fields . . . . . . . . . . . . . . . . . . . 4 56 2.1 Permanent and provisional header fields . . . . . . . . . . 4 57 2.2 Definitions of message header fields . . . . . . . . . . . . 5 58 2.2.1 Application-specific message header fields . . . . . . . . . 5 59 2.2.2 MIME header fields . . . . . . . . . . . . . . . . . . . . . 6 60 3. Registration procedure . . . . . . . . . . . . . . . . . . . 7 61 3.1 Header field specification . . . . . . . . . . . . . . . . . 7 62 3.2 Registration templates . . . . . . . . . . . . . . . . . . . 7 63 3.2.1 Permanent message header field registration template . . . . 7 64 3.2.2 Provisional message header field submission template . . . . 9 65 3.3 Submission of registration . . . . . . . . . . . . . . . . . 10 66 3.4 Objections to registration . . . . . . . . . . . . . . . . . 10 67 3.5 Change control . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.6 Comments on header definitions . . . . . . . . . . . . . . . 12 69 3.7 Location of header field registry . . . . . . . . . . . . . 12 70 4. IANA considerations . . . . . . . . . . . . . . . . . . . . 12 71 5. Security considerations . . . . . . . . . . . . . . . . . . 13 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 Normative References . . . . . . . . . . . . . . . . . . . . 13 74 Informative References . . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17 76 A. Revision history . . . . . . . . . . . . . . . . . . . . . . 17 77 A.1 draft-klyne-msghdr-registry-07 . . . . . . . . . . . . . . . 17 78 A.2 draft-klyne-msghdr-registry-06 . . . . . . . . . . . . . . . 18 79 A.3 draft-klyne-msghdr-registry-05 . . . . . . . . . . . . . . . 19 80 A.4 draft-klyne-msghdr-registry-04 . . . . . . . . . . . . . . . 19 81 A.5 draft-klyne-msghdr-registry-03 . . . . . . . . . . . . . . . 20 82 A.6 draft-klyne-msghdr-registry-02 . . . . . . . . . . . . . . . 21 83 A.7 draft-klyne-msghdr-registry-01 . . . . . . . . . . . . . . . 22 84 A.8 draft-klyne-msghdr-registry-00 . . . . . . . . . . . . . . . 22 85 B. Todo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 Intellectual Property and Copyright Statements . . . . . . . 23 88 1. Introduction 90 This specification defines registration procedures for the message 91 header field names used by Internet mail, HTTP, newsgroup feeds and 92 other Internet applications. It is not intended to be a replacement 93 for protocol-specific registries, such as the SIP registry [37]. 95 Benefits of a central registry for message header field names 96 include: 98 o providing a single point of reference for standardized and 99 widely-used header field names; 101 o providing a central point of discovery for established header 102 fields, and easy location of their defining documents; 104 o discouraging multiple definitions of a header field name for 105 different purposes; 107 o helping those proposing new header fields discern established 108 trends and conventions, and avoid names that might be confused 109 with existing ones; 111 o encouraging convergence of header field name usage across multiple 112 applications and protocols. 114 The primary specification for Internet message header fields in email 115 is the Internet mail message format specification, RFC 2822 [4]. 116 HTTP/1.0 [10] and HTTP/1.1 [27] define message header fields 117 (respectively, the HTTP-header and message-header protocol elements) 118 for use with HTTP. RFC 1036 [5] defines message header elements for 119 use with Netnews feeds. These specifications also define a number of 120 header fields, and provide for extension through the use of new 121 field-names. 123 There are many other Internet standards track documents that define 124 additional header fields for use within the same namespaces, notably 125 MIME [11] and related specifications. Other Internet applications 126 that use MIME, such as SIP (RFC 3261 [37]) may also use many of the 127 same header fields (but note that IANA maintains a separate registry 128 of header fields used with SIP). 130 Although in principle each application defines its own set of valid 131 header fields, exchange of messages between applications (e.g. mail 132 to Netnews gateways), common use of MIME encapsulation, and the 133 possibility of common processing for various message types (e.g. a 134 common message archive and retrieval facility) makes it desirable to 135 have a common point of reference for standardized and proposed header 136 fields. Listing header fields together reduces the chance of an 137 accidental collision, and helps implementers find relevant 138 information. The message header field registries defined here serve 139 that purpose. 141 1.1 Structure of this document 143 Section 2 discusses the purpose of this specification, and indicates 144 some sources of information about defined message header fields. 146 Section 3 defines the message header field name repositories, and 147 sets out requirements and procedures for creating entries in them. 149 1.2 Document terminology and conventions 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [2]. 155 NOTE: indented comments like this provide additional nonessential 156 information about the rationale behind this document. 158 [[[Editorial comments and questions about outstanding issues are 159 provided in triple brackets like this. These working comments should 160 be resolved and removed prior to final publication.]]] 162 2. Message header fields 164 2.1 Permanent and provisional header fields 166 Many message header fields are defined in standards-track documents, 167 which means they have been subjected to a process of community review 168 and achieved consensus that they provide a useful and well-founded 169 capability, or represent a widespread use of which developers should 170 be aware. Some are defined for experimental use, typically 171 indicating consensus regarding their purpose but not necessarily 172 concerning their technical details. Many others have been defined and 173 adopted ad-hoc to address a locally occurring requirement; some of 174 these have found widespread use. 176 The catalogues defined here are intended to cater for all of these 177 header fields, while maintaining a clear distinction and status for 178 those which have community consensus. To this end, two repositories 179 are defined: 181 o A Permanent Message Header Field Registry, intended for headers 182 defined in IETF standards-track documents, those that have 183 achieved a comparable level of community review, or are generally 184 recognized to be in widespread use. The assignment policy for such 185 registration is "Specification Required", as defined by RFC 2434 186 [3], where the specification must be published in an RFC 187 (standards-track, experimental, informational or historic), or as 188 an "Open Standard" in the sense of RFC 2026, section 7 [1]. 190 o A Provisional Message Header Field Repository, intended for any 191 header field proposed by any developer, without making any claim 192 about its usefulness or the quality of its definition. The policy 193 for recording these is "Private Use", per RFC 2434 [3]. 195 Neither repository tracks the syntax, semantics or type of 196 field-values. Only the field-names, applicable protocols and status 197 are registered; all other details are specified in the defining 198 documents referenced by repository entries. Significant updates to 199 such references (e.g., the replacement of a Proposed Standard RFC by 200 a Draft Standard RFC, but not necessarily the revision of an 201 Internet-draft) SHOULD be accompanied by updates to the corresponding 202 repository entries. 204 2.2 Definitions of message header fields 206 RFC 2822 [4] defines a general syntax for message headers, and also 207 defines a number of fields for use with Internet mail. HTTP/1.0 [10] 208 and HTTP/1.1 [27] do likewise for HTTP. Additional field names are 209 defined in a variety of standards-track RFC documents, including: RFC 210 1036 [5], RFC 1496 [6], RFC 1505 [7], RFC 1864 [9], RFC 2156 [14], 211 RFC 2183 [15], RFC 2045 [11], RFC 2046 [11], RFC 2557 [26], RFC 2227 212 [16], RFC 2231 [17], RFC 2298 [19], RFC 2369 [22], RFC 2421 [24], RFC 213 2518 [25], RFC 2617 [28], RFC 2821 [32], RFC 2912 [34], RFC 2919 214 [35], RFC 2965 [36], and RFC 3282 [38]. 216 2.2.1 Application-specific message header fields 218 Internet applications that use similar message headers include 219 Internet mail [32] [4], NNTP newsgroup feeds [5], HTTP web access 220 [27] and any other that uses MIME [11] encapsulation of message 221 content. 223 In some cases (notably HTTP [27]), the header syntax and usage is 224 redefined for the specific application. This registration is 225 concerned only with the allocation and specification of field names, 226 and not with the details of header implementation in specific 227 protocols. 229 In some cases, the same field name may be specified differently (by 230 different documents) for use with different application protocols; 231 e.g. The Date: header field used with HTTP has a different syntax 232 than the Date: used with Internet mail. In other cases, a field name 233 may have a common specification across multiple protocols (ignoring 234 protocol-specific lexical and character set conventions); e.g. this 235 is generally the case for MIME header fields with names of the form 236 'Content-*'. 238 Thus, we need to accommodate application-specific fields, while 239 wishing to recognize and promote (where appropriate) commonality of 240 other fields across multiple applications. Common repositories are 241 used for all applications, and each registered header field specifies 242 the application protocol for which the corresponding definition 243 applies. A given field name may have multiple registry entries for 244 different protocols; in the Permanent Message Header Field registry, 245 a given header field name may be registered only once for any given 246 protocol. (In some cases, the registration may reference several 247 defining documents.) 249 2.2.2 MIME header fields 251 Some header fields with names of the form Content-* are associated 252 with the MIME data object encapsulation and labelling framework. 253 These header fields can meaningfully be applied to a data object 254 separately from the protocol used to carry it. 256 MIME is used with email messages and other protocols that specify a 257 MIME-based data object format. MIME header fields used with such 258 protocols are defined in the registry with the protocol "mime", and 259 as such are presumed to be usable in conjunction with any protocol 260 that conveys MIME objects. 262 Other protocols do not convey MIME objects, but define a number of 263 header fields with similar names and functions to MIME. Notably, HTTP 264 defines a number of entity header fields that serve a purpose in HTTP 265 similar to MIME header fields in email. Some of these header fields 266 have the same names and similar functions to their MIME counterparts 267 (though there are some variations). Such header fields must be 268 registered separately for any non-MIME-carrying protocol with which 269 they may be used. 271 It is poor practice to reuse a header field name from another 272 protocol simply because the fields have similar (even "very similar") 273 meanings. Protocols should share header field names only when their 274 meanings are identical in all foreseeable circumstances. In 275 particular, new header field names of the form Content-* should not 276 be defined for non-MIME-carrying protocols unless their specification 277 is exactly the same as in MIME. 279 3. Registration procedure 281 The procedure for registering a message header field is: 283 1. Construct a header field specification 285 2. Prepare a registration template 287 3. Submit the registration template 289 3.1 Header field specification 291 Registration of a new message header field starts with construction 292 of a proposal that describes the syntax, semantics and intended use 293 of the field. For entries in the Permanent Message Header Field 294 Registry, this proposal MUST be published as an RFC, or as an Open 295 Standard in the sense described by RFC 2026, section 7 [1]. 297 A registered field name SHOULD conform at least to the syntax defined 298 by RFC 2822 [4], section 3.6.8. 300 Further, the "." character is reserved to indicate a naming 301 sub-structure and MUST NOT be included in any registered field name. 302 Currently, no specific sub-structure is defined; if used, any such 303 structure MUST be defined by a standards track RFC document. 305 Header field names may sometimes be used in URIs, URNs and/or XML. To 306 comply with the syntactic constraints of these forms, it is 307 recommended that characters in a registered field name are restricted 308 to those that can be used without escaping in a URI [23] or URN [13], 309 and that are also legal in XML [39] element names. 311 Thus, for maximum flexibility, header field names SHOULD further be 312 restricted to just letters, digits, hyphen ('-') and underscore ('_') 313 characters, with the first character being a letter or underscore. 315 3.2 Registration templates 317 The registration template for a message header field may be contained 318 in the defining document, or prepared separately. 320 3.2.1 Permanent message header field registration template 322 An header registered in the Permanent Message Header Field Registry 323 MUST be published as an RFC or as an "Open Standard" in the sense 324 described by RFC 2026, section 7 [1], and MUST have a name which is 325 unique among all the registered permanent field names that may be 326 used with the same application protocol. 328 The registration template has the following form. 330 PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE: 332 Header field name: 333 The name requested for the new header field. This MUST conform to 334 the header field specification details noted in Section 3.1. 336 Applicable protocol: 337 Specify "mail" (RFC 2822), "mime" (RFC2045), "http" (RFC 2616), 338 "netnews" (RFC 1036), or cite any other standards-track RFC 339 defining the protocol with which the header is intended to be 340 used. 342 Status: 343 Specify "standard", "experimental", "informational", "historic", 344 "obsoleted", or some other appropriate value according to the type 345 and status of the primary document in which it is defined. For 346 non-IETF specifications, those formally approved by other 347 standards bodies should be labelled as "standard"; others may be 348 "informational" or "deprecated" depending on the reason for 349 registration. 351 Author/Change controller: 352 For Internet standards-track, state "IETF". For other open 353 standards, give the name of the publishing body (e.g. ANSI, ISO, 354 ITU, W3C, etc.). For other specifications, give the name, email 355 address, and organization name of the primary specification 356 author. A postal address, home page URI, telephone and fax numbers 357 may also be included. 359 Specification document(s): 360 Reference to document that specifies the header for use with the 361 indicated protocol, preferably including a URI that can be used to 362 retrieve a copy of the document. An indication of the relevant 363 sections MAY also be included, but is not required. 365 Related information: 366 Optionally, citations to additional documents containing further 367 relevant information. (This part of the registry may also be used 368 for IESG comments.) 369 Where a primary specification refers to another document for 370 substantial technical detail, the referenced document is usefully 371 mentioned here. 373 3.2.2 Provisional message header field submission template 375 Registration as a Provisional Message Header Field does not imply any 376 kind of endorsement by the IETF, IANA or any other body. 378 The main requirements for a header field to be included in the 379 provisional repository are that it MUST have a citable specification, 380 and there MUST NOT be a corresponding entry (with same field name and 381 protocol) in the permanent header field registry. 383 The specification SHOULD indicate an email address for sending 384 technical comments and discussion of the proposed message header. 386 The submission template has the following form. 388 PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE: 390 Header field name: 391 The name proposed for the new header field. This SHOULD conform to 392 the field name specification details noted in Section 3.1. 394 Applicable protocol: 395 Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616), 396 "netnews" (RFC 1036), or cite any other standards-track RFC 397 defining the protocol with which the header is intended to be 398 used. 400 Status: 401 Specify: "provisional". This will be updated if and when the 402 header registration is subsequently moved to the permanent 403 registry. 405 Author/Change controller: 406 The name, email address, and organization name of the submission 407 author, who may authorize changes to or retraction of the 408 repository entry. A postal address, home page URI, telephone and 409 fax numbers may also be included. 410 If the proposal comes from a standards body working group, give 411 the name and home page URI of the working group, and an email 412 address for discussion of or comments on the specification. 414 Specification document(s): 415 Reference to document that specifies the header for use with the 416 indicated protocol. The document MUST be an RFC, a current 417 Internet-draft or the URL of a publicly accessible document (so 418 IANA can verify availability of the specification). An indication 419 of the relevant sections MAY also be included, but is not 420 required. 422 NOTE: if the specification is available in printed form only, 423 then an Internet draft containing full reference to the paper 424 document should be published and cited in the registration 425 template. The paper specification MAY be cited under related 426 information. 428 Related information: 429 Optionally, citations to additional documents containing further 430 relevant information. 432 3.3 Submission of registration 434 The registration template is submitted for incorporation in one of 435 the IANA message header field repositories by one of the following 436 methods: 438 o An IANA considerations section in a defining RFC, calling for 439 registration of the message header and referencing information as 440 required by the registration template within the same document. 441 Registration of the header is then processed as part of the RFC 442 publication process. 444 o Send a copy of the template to the designated email discussion 445 list [43]. Allow a reasonable period - at least 2 weeks - for 446 discussion and comments, then send the template to IANA at the 447 designated email address [45]. IANA will publish the template 448 information if the requested name and the specification document 449 meet the criteria noted in Section 3.1 and Section 3.2.2, unless 450 the IESG or their designated expert have requested that it not be 451 published (see Section 3.4). IESG's designated expert should 452 confirm to IANA that the registration criteria have been 453 satisfied. 455 When a new entry is recorded in the permanent message header field 456 registry, IANA will remove any corresponding entries (with the same 457 field name and protocol) from the provisional registry. 459 3.4 Objections to registration 461 Listing of an entry in the provisional repository should not be 462 lightly refused. An entry MAY be refused if there is some credible 463 reason to believe that such registration will be harmful. In the 464 absence of such objection, IANA SHOULD allow any registration that 465 meets the criteria set out in Section 3.1 and Section 3.2.2. Some 466 reasonable grounds for refusal might be: 468 o There is IETF consensus that publication is considered likely to 469 harm the Internet technical infrastructure in some way. 471 o Disreputable or frivolous use of the registration facilities. 473 o The proposal is sufficiently lacking in purpose, or misleading 474 about its purpose, that it can be held to be a waste of time and 475 effort. 477 o Conflict with some current IETF activity. 479 Note that objections or disagreements about technical detail are not, 480 of themselves, considered grounds to refuse listing in the 481 provisional repository. After all, one of its purposes is to allow 482 developers to communicate with a view to combining their ideas, 483 expertise and energy to the maximum benefit of the Internet 484 community. 486 Publication in an IESG-approved RFC or other form of Open Standard 487 document (per RFC 2026 [1], section 7) is sufficient grounds for 488 publication in the permanent registry. 490 To assist IANA in determining whether or not there is a sustainable 491 objection to any registration, IESG nominates a designated expert to 492 liaise with IANA about new registrations. For the most part, the 493 designated expert's role is to confirm to IANA that the registration 494 criteria have been satisfied. 496 The IESG or their designated expert MAY require any change or 497 commentary to be attached to any registry entry. 499 The IESG is the final arbiter of any objection. 501 3.5 Change control 503 Change control of a header field registration is subject to the same 504 condition as the initial registration; i.e. publication (or 505 reclassification) of an Open Standards specification for a Permanent 506 Message Header Field, or on request of the indicated author/change 507 controller for a Provisional Message Header (like the original 508 submission, subject to review on the designated email discussion list 509 [43].) 511 A change to a permanent message header field registration MAY be 512 requested by the IESG. 514 A change to or retraction of any Provisional Message Header Field 515 Repository entry MAY be requested by the IESG or designated expert. 517 IANA MAY remove any Provisional Message Header Field Repository entry 518 whose corresponding specification document is no longer available 519 (e.g. expired Internet-draft, or URL not resolvable). Anyone may 520 notify IANA of any such cases by sending an email to the designated 521 email address [45]. removing an entry for this reason, IANA SHOULD 522 contact the registered Author/Change controller to determine whether 523 a replacement for the specification document (consistent with the 524 requirements of section Section 3.2.2) is available. 526 It is intended that entries in the Permanent Message Header Field 527 Registry may be used in the construction of URNs (per RFC 2141 [13]) 528 which have particular requirements for uniqueness and persistence 529 (per RFC 1737 [8]). Therefore, once an entry is made in the Permanent 530 Message Header Registry, the combination of the header name and 531 applicable protocol MUST NOT subsequently be registered for any other 532 purpose. (This is not to preclude revision of the applicable 533 specification(s) within the appropriate IETF Consensus rules, and 534 corresponding updates to the specification citation in the header 535 registration.) 537 3.6 Comments on header definitions 539 Comments on proposed registrations should be sent to the designated 540 email discussion list [43]. 542 3.7 Location of header field registry 544 The message header field registry is accessible from IANA's web site 545 http://[[[IANA registry URL here]]]. 547 4. IANA considerations 549 This specification calls for: 551 o A new IANA registry for permanent message header fields per 552 Section 3 of this document. The policy for inclusion in this 553 registry is described in Section 3.1 and Section 3.2.1. 555 o A new IANA repository listing provisional message header fields 556 per Section 3 of this document. The policy for inclusion in this 557 registry is described in Section 3.1 and Section 3.2.2. 559 o IESG appoints a designated expert to advise IANA whether 560 registration criteria for proposed registrations have been 561 satisfied. 563 o [[[During the publication process for this document, there are 564 IANA-controlled email addresses and URLs to be allocated. All 565 such references are indicated in this memo by '[[[(some 566 description)]]]'. All such text (including this) should be 567 replaced or removed in the publication process.]]] 569 Initial header registrations are provided by the following companion 570 documents: 572 o For mail message headers: Registration of mail header fields [41] 574 o For HTTP message headers: Registration of HTTP header fields [42] 576 No initial entries are provided for the provisional registry. 578 5. Security considerations 580 No security considerations are introduced by this specification 581 beyond those already inherent in the use of message headers. 583 6. Acknowledgements 585 The shape of the registries described here owes much to energetic 586 discussion of previous versions by many denizens of the IETF-822 587 mailing list. 589 The authors also gratefully acknowledge the contribution of those who 590 provided valuable feedback on earlier versions of this memo: Charles 591 Lindsey, Dave Crocker, Pete Resnick, Jacob Palme, Ned Freed, Michelle 592 Cotton. 594 Normative References 596 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 597 9, RFC 2026, October 1996. 599 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 600 Levels", BCP 14, RFC 2119, March 1997. 602 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 603 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 605 [4] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 607 Informative References 609 [5] Horton, M. and R. Adams, "Standard for interchange of USENET 610 messages", RFC 1036, December 1987. 612 [6] Alvestrand, H., Jordan, K. and J. Romaguera, "Rules for 613 downgrading messages from X.400/88 to X.400/84 when MIME 614 content-types are present in the messages", RFC 1496, August 615 1993. 617 [7] Costanzo, A., Robinson, D. and R. Ullmann, "Encoding Header 618 Field for Internet Messages", RFC 1505, August 1993. 620 [8] Sollins, K. and L. Masinter, "Functional Requirements for 621 Uniform Resource Names", RFC 1737, December 1994. 623 [9] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 624 1864, October 1995. 626 [10] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext 627 Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. 629 [11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 630 Extensions (MIME) Part One: Format of Internet Message Bodies", 631 RFC 2045, November 1996. 633 [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 634 Extensions (MIME) Part Two: Media Types", RFC 2046, November 635 1996. 637 [13] Moats, R., "URN Syntax", RFC 2141, May 1997. 639 [14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping 640 between X.400 and RFC 822/MIME", RFC 2156, January 1998. 642 [15] Troost, R., Dorner, S. and K. Moore, "Communicating 643 Presentation Information in Internet Messages: The 644 Content-Disposition Header Field", RFC 2183, August 1997. 646 [16] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting 647 for HTTP", RFC 2227, October 1997. 649 [17] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word 650 Extensions: Character Sets, Languages, and Continuations", RFC 651 2231, November 1997. 653 [18] Holtman, K. and A. Mutz, "Transparent Content Negotiation in 654 HTTP", RFC 2295, March 1998. 656 [19] Fajman, R., "An Extensible Message Format for Message 657 Disposition Notifications", RFC 2298, March 1998. 659 [20] Holtman, K., "The Safe Response Header Field", RFC 2310, April 660 1998. 662 [21] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/ 663 1.0)", RFC 2324, April 1998. 665 [22] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for 666 Core Mail List Commands and their Transport through Message 667 Header Fields", RFC 2369, July 1998. 669 [23] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 670 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 671 1998. 673 [24] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail 674 - version 2", RFC 2421, September 1998. 676 [25] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, 677 "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 678 2518, February 1999. 680 [26] Palme, F., Hopmann, A., Shelness, N. and E. Stefferud, "MIME 681 Encapsulation of Aggregate Documents, such as HTML (MHTML)", 682 RFC 2557, March 1999. 684 [27] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 685 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 686 HTTP/1.1", RFC 2616, June 1999. 688 [28] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 689 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 690 Basic and Digest Access Authentication", RFC 2617, June 1999. 692 [29] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 693 August 1999. 695 [30] Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer 696 Protocol", RFC 2660, August 1999. 698 [31] Nielsen, H., Leach, P. and S. Lawrence, "An HTTP Extension 699 Framework", RFC 2774, February 2000. 701 [32] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 702 2001. 704 [33] Herriot, R., Butler, S., Moore, P., Turner, R. and J. Wenn, 705 "Internet Printing Protocol/1.1: Encoding and Transport", RFC 706 2910, September 2000. 708 [34] Klyne, G., "Indicating Media Features for MIME Content", RFC 709 2912, September 2000. 711 [35] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and 712 Namespace for the Identification of Mailing Lists", RFC 2919, 713 March 2001. 715 [36] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", 716 RFC 2965, October 2000. 718 [37] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 719 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 720 Session Initiation Protocol", RFC 3261, June 2002. 722 [38] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002. 724 [39] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 725 "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C 726 Recommendation xml, October 2000, . 729 [40] Palme, J., "Common Internet Message Header Fields", 730 Work-in-progress: Internet draft 731 draft-palme-mailext-headers-08, September 2002, . 735 [41] Klyne, G., "Registration of mail header fields", 736 Work-in-progress: Internet draft draft-klyne-hdrreg-mail-01, 737 Jun 2002, . 740 [42] Nottingham, M. and J. Mogul, "Registration of HTTP header 741 fields", Work-in-progress: Internet draft 742 draft-nottingham-hdrreg-http-00, Jan 2002, . 745 [43] "Mail address for announcement of new header field 746 submissions", Mail address 747 mailto:[[[ietf-message-headers]]]@ietf.org. 749 [44] "Mail address for subscription to 750 [[[ietf-message-headers]]]@ietf.org. (DO NOT SEND SUBSCRIPTION 751 REQUESTS TO THE MAILING LIST ITSELF)", Mail address 752 mailto:[[[ietf-message-headers-request]]]@ietf.org. 754 [45] "Mail address for submission of new header field templates", 755 Mail address mailto:[[[iana-message-headers]]]@iana.org. 757 Authors' Addresses 759 Graham Klyne 760 Nine by Nine 762 EMail: GK-IETF@ninebynine.org 763 URI: http://www.ninebynine.net/ 765 Mark Nottingham 766 BEA Systems 767 235 Montgomery St. 768 Level 15 769 San Francisco, CA 94104 770 USA 772 EMail: mnot@pobox.com 774 Jeffrey C. Mogul 775 Western Research Laboratory, Compaq Computer Corporation 776 250 University Avenue 777 Palo Alto, CA 94305 778 US 780 Phone: 1 650 617 3304 (email preferred) 781 EMail: JeffMogul@acm.org 783 Appendix A. Revision history 785 [[[Please remove this section on final publication]]] 787 A.1 draft-klyne-msghdr-registry-07 789 07a 27-Oct-2003: 791 * Changes in response to feedback from IESG: 793 * Added notes clarifying that this header field registry does not 794 supplant the SIP header field registry. 796 * Updated references in cases where cited RFCs have been 797 obsoleted (these were all informational references, being part 798 of the survey of protocols and specifications that define 799 header fields). 801 06b 08-Jan-2003: 803 * Response to last-call comments: 805 * Updated author details. 807 * Added section on MIME header fields, noting that MIME is 808 treated as a separate protocol for registration purposes. 810 * Separated normative references from informational references. 811 (Some protocols mentioned as motivation for an aspect of this 812 specification are cited as informational, on the basis that 813 their specification is not needed for validation of a proposed 814 registry entry.) 816 * Added "mime" as an option under applicable protocols. 818 * Moved URL of IANA registry from references section to body of 819 document. 821 * Added requirement that IESG's designated expert should confirm 822 to IANA that registration criteria have been satisfied. 824 * Noted appointment of IESG-designated expert in IANA 825 considerations section. 827 * Added temporary note to IANA considerations section that there 828 are IANA-controlled email addresses and URLs yet to be 829 allocated. 831 * Widened options for status of a header field. 833 * Revised some references. 835 A.2 draft-klyne-msghdr-registry-06 837 06a 05-Aug-2002: 839 * Fixed typo. 841 06b 08-Jan-2003: 843 * Response to last-call comments: 845 * Updated author details. 847 * Added section on MIME header fields, noting that MIME is 848 treated as a separate protocol for registration purposes. 850 * Separated normative references from informational references. 851 (Many protocols mentioned as motivation for an aspect of this 852 specification are cited as informational, on the basis that 853 their specification is not needed for validation of a proposed 854 registry entry.) 856 * Added "mime" as an option under applicable protocols. 858 * Moved URL of IANA registry from references section to body of 859 document. 861 * Added requirement that IESG's designated expert should confirm 862 to IANA that registration criteria have been satisfied. 864 * Noted appointment of IESG-designated expert in IANA 865 considerations section. 867 * Added temporary note to IANA considerations section that there 868 are IANA-controlled email addresses and URLs yet to be 869 allocated. 871 * Widened options for status of a header field. 873 * Revised some references. 875 A.3 draft-klyne-msghdr-registry-05 877 05a 10-Jun-2002: 879 * Updated contact details. 881 * Updated reference to mail header field registration document. 883 A.4 draft-klyne-msghdr-registry-04 885 04a 25-Mar-2002: 887 * Added note about referencing paper-only specification 888 documents. 890 * Change 'news' -> 'netnews'. 892 * Experimental standards don't cite IETF as change controller. 894 * Added note that provisional registry entries SHOULD indicate a 895 discussion list. 897 * Clarify that a single registry may reference several 898 specification documents. 900 * Add "deprecated" to list of possible status values for 901 permanent registry. 903 * Conflict with IETF work noted as possible objection to listing 904 in the provisional registry. 906 * Several small editorial changes. 908 04b 25-Mar-2002: 910 * Simplify the text describing recommended character limitations 911 for header field names. 913 * Re-arrange the text dealing with status for permanent registry 914 entries. 916 * More small editorial changes. 918 A.5 draft-klyne-msghdr-registry-03 920 03a 11-Feb-2002: 922 * Re-organized repositories into Permanent and Provisional, names 923 chosen with a view to reducing any spurious impression of 924 legitimacy. 926 * All entries have a status indicator. For provisional entries, 927 this clearly indicates the non-settled nature of the entry. 929 * Make provision for prior email notification to interested 930 parties of submissions not published in an RFC. 932 * Make limited provision for refusal or removal of harmful 933 submissions. IESG may appoint a designated expert to assist 934 IANA with any assessments needed. 936 * Make provision for IANA to remove provisional entries whose 937 specification is no longer available. 939 * Proposed mailing list for announcement/discussion of new 940 registrations, and another for notifying IANA. 942 * Removed any reference to header names beginning with 'X-', on 943 the basis that this is a protocol-specific convention. 945 * Updated terminology to use "header field" more consistently, 946 rather than just "header". 948 * Revised permanent and provisional submission templates to have 949 the same form and structure. 951 03b 11-Feb-2002: 953 * Editorial fixes. 955 03c 19-Feb-2002: 957 * Extend range of specifications acceptable for permanent 958 registry entries to include "Open standards" (per RFC 2026). 960 * Trim references to other informational lists of header 961 information. 963 * Focused the requirement for permanent registration on 964 persistent publication by an open standards body. 966 * Noted in provisional submission template that a proposal may 967 come from a working group. 969 * Allowed for fuller contact information under change controller. 971 03d 19-Feb-2002: 973 * Improved wording of submission process. 975 * Indicate that there should be IETF consensus that publication 976 would harm the technical infrastructure, for publication of a 977 provisional entry to be blocked. 979 * Adjust registration criteria and procedures so that 980 corresponding entries cannot appear simultaneously in the 981 permanent and provisional listings. 983 A.6 draft-klyne-msghdr-registry-02 985 02a 22-Jan-2002: 987 * Merged with HTTP header registry proposal. 989 * Move initial registrations to separate documents. 991 02b 29-Jan-2002: 993 * Editorial revisions. 995 A.7 draft-klyne-msghdr-registry-01 997 01a 04-Jan-2002: 999 * In response to feedback from interested parties, expanded the 1000 registry to cover Normative and Provisional message header 1001 registrations. 1003 * Defined a formal role for the applicable protocol(s) in the 1004 registry: the combination of header name and any applicable 1005 protocol must be unique for a Normative Message Header. 1007 * Noted further constraints to the header name format for XML 1008 name compatibility. 1010 * Fixed registration policy for a Normative Message Header to be 1011 "IETF Consensus". 1013 A.8 draft-klyne-msghdr-registry-00 1015 00a 27-Sep-2001: 1017 * Document initially created. 1019 Appendix B. Todo 1021 [[[Please remove this section on final publication]]] 1023 o Finalize references to initial registrations. 1025 o Finalize email address for submission of registration templates. 1027 o Finalize web address for registry. 1029 Intellectual Property Statement 1031 The IETF takes no position regarding the validity or scope of any 1032 intellectual property or other rights that might be claimed to 1033 pertain to the implementation or use of the technology described in 1034 this document or the extent to which any license under such rights 1035 might or might not be available; neither does it represent that it 1036 has made any effort to identify any such rights. Information on the 1037 IETF's procedures with respect to rights in standards-track and 1038 standards-related documentation can be found in BCP-11. Copies of 1039 claims of rights made available for publication and any assurances of 1040 licenses to be made available, or the result of an attempt made to 1041 obtain a general license or permission for the use of such 1042 proprietary rights by implementors or users of this specification can 1043 be obtained from the IETF Secretariat. 1045 The IETF invites any interested party to bring to its attention any 1046 copyrights, patents or patent applications, or other proprietary 1047 rights which may cover technology that may be required to practice 1048 this standard. Please address the information to the IETF Executive 1049 Director. 1051 Full Copyright Statement 1053 Copyright (C) The Internet Society (2003). All Rights Reserved. 1055 This document and translations of it may be copied and furnished to 1056 others, and derivative works that comment on or otherwise explain it 1057 or assist in its implementation may be prepared, copied, published 1058 and distributed, in whole or in part, without restriction of any 1059 kind, provided that the above copyright notice and this paragraph are 1060 included on all such copies and derivative works. However, this 1061 document itself may not be modified in any way, such as by removing 1062 the copyright notice or references to the Internet Society or other 1063 Internet organizations, except as needed for the purpose of 1064 developing Internet standards in which case the procedures for 1065 copyrights defined in the Internet Standards process must be 1066 followed, or as required to translate it into languages other than 1067 English. 1069 The limited permissions granted above are perpetual and will not be 1070 revoked by the Internet Society or its successors or assignees. 1072 This document and the information contained herein is provided on an 1073 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1074 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1075 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1076 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1077 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1079 Acknowledgement 1081 Funding for the RFC Editor function is currently provided by the 1082 Internet Society.