Network Working Group Jacob Palme Internet Draft Stockholm University/KTH, Sweden draft-ietf-drums-MHRegistry-02.txt November 1997 Category: Informational; Replaces RFC 2076 Expires May 1998 Mail and Netnews Header Registration Procedure Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind, since this document is mainly a compilation of information taken from other RFCs.. Distribution of this memo is unlimited. Abstract Various IETF standards and e-mail and netnews software products use various e-mail and netnews header fields. This document specifies a procedure for the registration of e-mail and netnews header field names, to reduce the risk that two different products use the same header name in different ways (homonyms) or that several different header names are used with identical meaning (synonyms). Table of contents 1. Introduction 2. Which Headers are Registered 3. Who can Register a Header Name 4. Registration Procedure 4.1 Registration Template 4.2 Present the Request for Registration to the Community 4.3 Submit the Header name to the IANA for Registration 5. Clarifications On Specific Issues 5.1 E-mail Requirements for a Limited Number of Headers 5.2 Header Status 5.3 Requirements for a Published Specification 5.4 Identification of Security Considerations 5.5 Recommendations and Standards Status 6. Security Considerations 7. Acknowledgments 8. Copyright 9. References 10. Author's address 11. Appendix: Example of the first few entries in the registry 1. Introduction Many different Internet standards, other RFCs and e-mail software products define headers which may occur on Internet mail messages and/or Usenet News articles. There is an obvious risk for Honomyns: The same header name is used in different ways by different software products. Synonyms: Several different headers for exactly the same use. The solution, to allow header names beginning with "X-" for non-standard header names has several drawbacks. One is that it does not preclude two different products using the same "X-" header name with different semantic meaning. Another is that if an "X-" header gets popular and much used, and is to become a standard, there is a problem with removing the "X-" in front of an already much used header. Because of this, an IANA registry for e-mail and Usenet News header field names is needed. The following words are used in this memo with the meaning specified below: heading Formatted text at the top of a message, ended by a blank line header = heading One field in the heading, beginning with a field header name, colon, and followed by the field value(s) 2. Which Headers are Registered The header name registry can contain headers from the following sources: - Internet standards - RFCs which are not Internet standards - Non-Internet standards - Other commonly used headers - Sometimes used headers whose use is discouraged. The use of a header name may be discouraged because it is badly defined, ambigous or used in different ways by different software. The purpose of registering discouraged headers is to avoid their use in their present or any other future semantic meaning. The registry is intended to contain headers used in messaging (e-mail, Usenet News, etc.) but not HTTP-only headers. 3. Who can Register a Header Name Header names from Internet standards are registered by IETF together with the standard specifying the header. Headers in other RFCs are registered when the RFCs are published. Anyone can propose the registry of additional headers, but such headers should be approved by the IETF application area managers before accepted in the registry. This approval should be given if the header seems reasonable and not in conflict with current usage or other headers in ways which might cause problem. It is not necessary for approval that the AREA manager likes the header or wants it to be progressed into an IETF standard. The procedure described in this memo is followed by the IANA for review and approval of new e-mail and netnews headers. This is not a formal standards process, but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay. 4. Registration Procedure 4.1 Registration Template To: ietf-types@iana.org Subject: Registration of e-mail header: XXX E-mail header name: Short description (max 100 words): Encoding considerations: Security considerations: Interoperability considerations: Published specification: Applications which use this header: Person & email address to contact for further information: Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Author/Change controller: (Any other information that the author deems interesting may be added below this line.) 4.2 Present the Request for Registration to the Community Send a proposed header to the "mail-headers@segate.sunet.se" mailing list. This mailing list has been established for the sole purpose of reviewing proposed e-mail and netnews headers. You can subscribe to the list by sending a message to "listserv@segate.sunet.se" containing in the text a line with "subscribe mail-headers " followed by our name (not your e-mail address), and unsubscribe with a message "unsubscribe mail-headers". Archives of this list are available by anonymous FTP from ftp://segate.sunet.se/lists/mail-headers/ by HTTP from http://segate.sunet.se/archives/mail-headers.html by E-MAIL send a message to LISTSERV@SEGATE.SUNET.SE with the text "INDEX mail-headers" to get a list of the archive files, and then a new message "GET " to retrieve the archive files. The FTP and E-MAIL archives are best if you want to retrieve all messages during a month or more, while the HTTP archives are better if you want to browse and find particular messages to download. The intent of the public posting is to solicit comments and feedback on the choice of header name, the unambiguity of the references with respect to versions and external profiling information, the choice of which OIDs to use, and a review of the security considerations section. It should be noted that the proposed header name does not need to make sense for every possible application. If the header name is intended for a limited or specific use, this should be noted in the submission. 4.3 Submit the Header name to the IANA for Registration After at least two weeks, submit the proposed header to the IANA for registration. The request and supporting documentation should be sent to "iana@isi.edu". IANA will ask the area directors for approval. If approved, IANA will register the header, assign an OID under the IANA branch, and make the header registration available to the community. IANA should keep a data base of registered headers. IANA should regularly publish the contents of this data base in the following formats, which can be generated automatically from the data base: (1) In HTML format as shown in an appendix to this document. (2) As plain formatted ASCII text. (3) As ASCII text with HT between fields and CRLF between lines. Format (1) and (2) are good for human reading, format (3) is good for input to a data base. The header will be listed in the periodically issued "Assigned Numbers" RFC [2]. The header description may be published as an Informational RFC by sending it to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [3]). 5. Clarifications On Specific Issues 5.1 E-mail Requirements for a Limited Number of Headers Issue: In the asynchronous mail environment, where information on the capabilities of the remote mail agent is not available to the sender, maximum interoperability is attained by restricting the number of headers used to those "common" headers expected to be widely implemented. This was asserted as a reason to limit the number of possible headers and resulted in a registration process with a significant hurdle and delay for those registering headers. 5.2 Header Status Any header in the registry should be marked with a status, which has one of the values specified below: IETF standard. Specified in an IETF standard. IETF draft standard. Specified in an IETF draft standard. IETF proposed Specified in an IETF proposed standard. standard. IETF experimental Specified in an IETF experimental standard. standard. X.400. Used to mark headers which are defined in RFC 1327 for use in messages from or to Internet mail/X.400 gateways, and which have not been standardized for general usage in the exchange of messages between Internet mail-based systems. Usenet News only, De facto standard in Usenet News, may not in e-mail. occur in messages gatewayed from Usenet News to e-mail, no defined meaning in e-mail. Non-standard, only Used in Usenet News, may occur in in Usenet News, not messages gatewayed from Usenet News to in e-mail. e-mail, no defined meaning in e-mail. Usenet news only, De facto standard in Usenet News, may discouraged in occur in messages gatewayed from Usenet e-mail. News to e-mail, but such practice is discouraged. Not standardized for Used to mark headers defined only for use in e-mail. use in Usenet News. These headers have no standard meaning when appearing in e-mail, some of them may even be used in different ways by different software. When appearing in e-mail, they should be handled with caution. Other standard. Defined in standard developed by another standards making body than IETF. Non-standard. This header is not specified in any of the RFCs which define Internet protocols, including Internet Standards, Draft Standards, Proposed Standards and Experimental Standards. The header appears here because it sometimes appears in e-mail or Usenet News. Usage of these headers is not in general recommended. Some header proposed in ongoing IETF standards development work, but not yet accepted, are also marked in this way. discouraged This header, which is non-standard or historical, is known to create problems and should not be generated. Handling of such headers in incoming mail should be done with great caution. controversial The meaning and usage of this header is controversial, i.e. different implementors have chosen to implement the header in different ways. Because of this, such headers should be handled with caution and understanding of the different possible interpretations. 5.3 Requirements for a Published Specification If headers registered are specified in a separate document, this document should be published as an RFC. Other specifications can in some cases also be accepted if they are publicly available on the Internet. The following information should be provided when applying for registry of a new e-mail or Usenet News header: - Header name. - Status, one of the statuses specified in section 5.2 above. - If the header is specified in an RFC, the number of this RFC. - If the header is specified in another standard than an RFC, a reference to this standard. - If the header is not specified in an RFC, a short textual description should be enclosed, which describes the header, its intended use and discusses security considerations. - Security considerations. 5.4 Identification of Security Considerations The registration process requires the identification of any known security problems with the header name. It is not required that the header be secure or that it be free from risks, but that the known risks be identified. Publication of a header name does not require an exhaustive security review, and the security considerations. Additional security considerations should be periodically published in an RFC by IANA. 5.5 Recommendations and Standards Status Issue: The registration of a header does not imply endorsement, approval, or recommendation by IANA or IETF or even certification that the specification is adequate. 6. Security Considerations This memo does not address specific security issues but outlines a security review process for headers 7. Acknowledgments Harald Tveit Alvestrand, Ned Freed, Olle Järnefors, Keith Moore, Nick Smith and several other people have helped in developing this document. I alone take responsibility for any errors which may still be in the list. 8. Copyright "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." 9. References Ref. Author, title IETF status (July 1996) ---- ------------------------------------------ ------------- - [1] J. Postel: "Simple Mail Transfer Standard, Protocol", STD 10, RFC 821, August 1982. Recommended [2] D. Crocker: "Standard for the format of Standard, ARPA Internet text messages." STD 11, RFC Recommended 822, August 1982. [3] M.R. Horton, R. Adams: "Standard for Not an interchange of USENET messages", RFC 1036, offi-cial IETF December 1987. standard, but in reality a de-facto standard for Usenet News [4] M. Sirbu: "A Content-Type header for Standard, internet messages", RFC 1049, March 1988. Recommended, but can in the future be expected to be replaced by MIME [5] R. Braden (editor): "Requirements for Standard, Internet Hosts -- Application and Required Support", STD-3, RFC 1123, October 1989. [6] D. Robinson, R. Ullman: "Encoding Header Non-standard for Internet Messages", RFC 1154, April 1990. [7] S. Hardcastle-Kille: "Mapping between Proposed X.400(1988) / ISO 10021 and RFC 822", RFC standard, 1327 May 1992. elective [8] H. Alvestrand & J. Romaguera: "Rules for Proposed Downgrading Messages from X.400/88 to standard, X.400/84 When MIME Content-Types are elective Present in the Messages", RFC 1496, August 1993. [9] A. Costanzo: "Encoding Header for Internet Non-standard Messages", RFC 1154, April 1990. [10] A. Costanzo, D. Robinson: "Encoding Header Experimental for Internet Messages", RFC 1505, August 1993. [11] N. Borenstein & N. Freed: "MIME Draft Standard, (Multipurpose Internet Mail Extensions) elective Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Sept 1993. [12] H. Alvestrand: "Tags for the Proposed Identification of Languages", RFC 1766, standard, February 1995. elective [13] J. Palme: "Electronic Mail", Artech House Non-standard publishers, London-Boston January 1995. [14] R. Troost, S. Dorner: "Communicating Experimental Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995. [15] B. Kantor, P. Lapsley, "Network News Proposed Transfer Protocol: "A Proposed Standard standard for the Stream-Based Transmission of News", RFC 977, January 1986. [16] 1848 PS S. Crocker, N. Freed, J. Proposed Galvin, S. Murphy, "MIME Object Security standard Services", RFC 1848, March 1995. [17] J. Myers, M. Rose: The Content-MD5 Header, Draft standard RFC 1864, October 1995. [18] M. Horton, UUCP mail interchange format Not an standard, RFC 976, Januari 1986. offi-cial IETF standard, but in reality a de-facto standard for Usenet News [19] T. Berners-Lee, R. Headering, H. Frystyk: IETF draft Hypertext Transfer Protocol -- HTTP/1.0, draft-ietf-http-v10-spec-04.txt. [20] G. Vaudreuil: Voice Profile for Internet Experimental Mail, RFC 1911, February 1996. [21] H. Spencer: News Article Format and Not even an Transmission, June 1994, RFC, but still FTP://zoo.toronto.edu/pub/news.ps.Z widely used and FTP://zoo.toronto.edu/pub/news.txt.Z partly almost a de-facto This document is often referenced under standard for the name "son-of-RFC1036". Usenet News [22] J. Palme: Common Internet Message Headers. Informational draft-ietf-mailext-mail-attributes-07.txt. January 1997. [23] PICS Label Distribution Label Syntax and Other standard Communication Protocols, World Wide Web Consortium, October 1996. [24] Eudora Pro Macintosh User Manual, Qualcomm Non-standard Inc., 1988-1995. 10. Author's address Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-783 08 29 Electrum 230 E-mail: jpalme@dsv.su.se S-164 40 Kista, Sweden 11. Appendix: Example of the first few entries in the registry Note 1: This example is formatted in a simple subset of HTML which almost all HTML browsers can handle. Note 2: When the registry is started, use the latest version of draft-ietf-mailext-mail-attributes-??.txt as starting contents of the registry. The example below can be accessed via URL: http://www.dsv.su.se/~jpalme/ietf/ehead-registry-example.html IANA Registry of e-mail headers

ISI Logo IANA Registry of e-mail headers HTML 3.2 Checked!

Last update: 15 August 1997.

Description Name Reference, status
Special Usenet News actions and a normal article at the same time. Also-Control: son-of-RFC1036 [21], non-standard, only in Usenet News, not in e-mail
Controls whether this message may be forwarded to alternate recipients such as a postmaster if delivery is not possible to the intended recipient. Default: Allowed. Alternate-Recipient: RFC 1327, not for general usage.
Inserted by Sendmail when there is no "To:" recipient in the original message, listing recipients derived from the envelope into the message heading. This behavior is not quite proper, MTAs should not modify headings (except inserting Received lines), and it can in some cases cause Bcc recipients to be wrongly divulged to non-Bcc recipients. Apparently-To: Non-standard, discouraged, mentioned in RFC 1211.
Name of the moderator of the newsgroup to which this article is sent; necessary on an article sent to a moderated newsgroup to allow its distribution to the newsgroup members. Also used on certain control messages, which are only performed if they are marked as Approved. Approved: RFC 1036: 2.2.11, not standardized for use in e-mail.