Repository entry MAY be requested by the IESG or designated expert.
IANA MAY remove any Provisional Message Header Field Repository entry
whose corresponding specification document is no longer available
(e.g., expired Internet-draft, or URL not resolvable). Anyone may
notify IANA of any such cases by sending an email to the designated
email address [35]. Before removing an entry for this reason, IANA
SHOULD contact the registered Author/Change controller to determine
whether a replacement for the specification document (consistent with
the requirements of section Section 4.2.2) is available.
It is intended that entries in the Permanent Message Header Field
Registry may be used in the construction of URNs (per RFC 2141 [13])
which have particular requirements for uniqueness and persistence
(per RFC 1737 [8]). Therefore, once an entry is made in the
Permanent Message Header Registry, the combination of the header name
and applicable protocol MUST NOT subsequently be registered for any
other purpose. (This is not to preclude revision of the applicable
specification(s) within the appropriate IETF Consensus rules, and
corresponding updates to the specification citation in the header
registration.)
4.6. Comments on Header Definitions
Comments on proposed registrations should be sent to the designated
email discussion list [33].
4.7. Location of Header Field Registry
The message header field registry is accessible from IANA’s web site
http://www.iana.org/assignments/message-headers/
message-header-index.html
5. IANA Considerations
This specification calls for:
o A new IANA registry for permanent message header fields per
Section 4 of this document. The policy for inclusion in this
registry is described in Section 4.1 and Section 4.2.1.
o A new IANA repository listing provisional message header fields
per Section 4 of this document. The policy for inclusion in this
registry is described in Section 4.1 and Section 4.2.2.
o IESG appoints a designated expert to advise IANA whether
registration criteria for proposed registrations have been
satisfied.
No initial registry entries are provided.
6. Security Considerations
No security considerations are introduced by this specification
beyond those already inherent in the use of message headers.
7. Acknowledgements
The shape of the registries described here owes much to energetic
discussion of previous versions by many denizens of the IETF-822
mailing list.
The authors also gratefully acknowledge the contribution of those who
provided valuable feedback on earlier versions of this memo: Charles
Lindsey, Dave Crocker, Pete Resnick, Jacob Palme, Ned Freed, Michelle
Cotton.
8. References
8.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Resnick, P., Ed., "Internet Message Format", RFC 2822, April
2001.
8.2. Informative References
[5] Horton, M. and R. Adams, "Standard for interchange of USENET
messages", RFC 1036, December 1987.
[6] Alvestrand, H., Jordan, K., and J. Romaguera, "Rules for
downgrading messages from X.400/88 to X.400/84 when MIME
content-types are present in the messages", RFC 1496, August
1993.
[7] Costanzo, A., Robinson, D., and R. Ullmann, "Encoding Header
Field for Internet Messages", RFC 1505, August 1993.
[8] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[9] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864,
October 1995.
[10] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[11] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[13] Moats, R., "URN Syntax", RFC 2141, May 1997.
[14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[15] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997.
[16] Mogul, J. and P. Leach, "Simple Hit-Metering and Usage-Limiting
for HTTP", RFC 2227, October 1997.
[17] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations", RFC
2231, November 1997.
[18] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition
Notification", RFC 3798, May 2004.
[19] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for
Core Mail List Commands and their Transport through Message
Header Fields", RFC 2369, July 1998.
[20] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[21] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail -
version 2 (VPIMv2)", RFC 3801, June 2004.
[22] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen,
"HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518,
February 1999.
[23] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME
Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC
2557, March 1999.
[24] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[25] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[26] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[27] Klyne, G., "Indicating Media Features for MIME Content", RFC
2912, September 2000.
[28] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and
Namespace for the Identification of Mailing Lists", RFC 2919,
March 2001.
[29] Kristol, D. and L. Montulli, "HTTP State Management Mechanism",
RFC 2965, October 2000.
[30] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[31] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[32] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
Recommendation xml, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[33] "Mail address for announcement of new header field submissions",
Mail address: ietf-message-headers@lists.ietf.org
[34] "Mail address for subscription to ietf-message-
headers@lists.ietf.org. (DO NOT SEND SUBSCRIPTION REQUESTS TO
THE MAILING LIST ITSELF)", Mail address: ietf-message-headers-
request@lists.ietf.org
[35] "Mail address for submission of new header field templates",
Mail address: iana@iana.org
9. Authors’ Addresses
Graham Klyne
Nine by Nine
EMail: GK-IETF@ninebynine.org
URI: http://www.ninebynine.net/
Mark Nottingham
BEA Systems
235 Montgomery St.
Level 15
San Francisco, CA 94104
USA
EMail: mnot@pobox.com
Jeffrey C. Mogul
HP Labs
1501 Page Mill Road
Palo Alto, CA 94304
US
EMail: JeffMogul@acm.org
10. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.