Network Working Group Jacob Palme Internet Draft Stockholm University/KTH, Sweden draft-ietf-drums-MHRegistry-03.txt January 1998 Category-to-be: Informational Expires August 1998 Mail and Netnews Header field 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. Distribution of this memo is unlimited. Copyright (C) The Internet Society 1998. All Rights Reserved. Abstract Various IETF standards and http, e-mail and netnews software products use various http, e-mail and netnews header fields. This document specifies a procedure for the registration of http, e-mail and netnews header field names, to reduce the risk that two different products use the same header field name in different ways (homonyms) or that several different header field names are used with identical meaning (synonyms). Changes from version 02 of this draft Also http header fieldss are now included in the registry, not as before only e-mail and netnews header fields. Added text that also fields from Internet drafts can be registered on a temporary basis, such registration expires with the Internet draft: 3.1 Registration of headers from Internet drafts Headers in Internet drafts can be registered on a temporary basis, so that the header registry can be used to find also such headers. If the IETF draft expires, such headers must either be removed from the registry, or changed to reflect their new status (as an IETF standard or as a non-standard documented separately from IETF). Expiration month: (For a header field from an Internet draft, this must be the expiration date of the draft. After this time, the registration must either be removed or changed. The word "unlimited" can be used for fields without an expiration month.) Changed paragraph about "X-" headers: Because of this, an IANA registry for http, e-mail and Netnews header field names is needed. This registry can contain header fields starting with "X-", even though such header fields cannot be specified in IETF standards. The registry can also contain header fields not starting with "X-", even though such fields are not part of IETF standards. There is no promise that such non-standard field names, not starting with "X-", will not be used in future standards, but normally future standards can be expected not to use field names from the header registry in ways which are incompatible with existing usage of such fields as specified in the registry. Added text that the IESG can change any header registration. Minor changes to registered headers, which will not cause problems for those who have already implemented the header, can be done by the person or organisation who has change control for the header. This person or organisation can also add to the register advance notice about future changes under development. The IESG additionally has the right to modify an header field registration, even without permission from the change controller. This right for the IESG should of course be used with great caution. The name of the mailing list has been changed from "mail-headers" to "message-headers" to allow also http and netnews header fields. Table of contents 1. Introduction 2. Which Header fields are Registered 3. Who can Register a Header field Name 3.1 Registration of headers from Internet drafts 4. Registration Procedure 4.1 Registration Template 4.2 Present the Request for Registration to the Community 4.3 Submit the Header field name to the IANA for Registration 4.4 Changes to registered headers 5. Clarifications On Specific Issues 5.1 Requirements for a Limited Number of Header Fields 5.2 Header field 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: Examples of the publication format of the header registry 11.1 Header registry when published as plain formatted text 11.2 Header registry when published in HTML format 11.3 Header registry when published as a tab-separated table 1. Introduction Many different Internet standards, other RFCs and http, e-mail and netnews software products define header fields which may occur on http headings, Internet mail headings and/or Netnews headings. There is an obvious risk for Honomyns: The same header field name is used in different ways by different software products. Synonyms: Several different header fields for exactly the same use. The solution, to allow header field names beginning with "X-" for non-standard header field names has several drawbacks. One is that it does not preclude two different products using the same "X-" header field name with different semantic meaning. Another is that if an "X-" header field 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 field. Because of this, an IANA registry for http, e-mail and Netnews header field names is needed. This registry can contain header fields starting with "X-", even though such header fields cannot be specified in IETF standards. The registry can also contain header fields not starting with "X-", even though such fields are not part of IETF standards. There is no promise that such non-standard field names, not starting with "X-", will not be used in future standards, but normally future standards can be expected not to use field names from the header registry in ways which are incompatible with existing usage of such fields as specified in the registry. The following words are used in this memo with the meaning specified below: heading Formatted text at the top of a message, ended by CRLFCRLF header field One field in the heading, beginning with a header field name, colon, and followed by the field value(s). Other words sometimes used for this is "header" or "heading field". 2. Which Header fields are Registered The header field name registry can contain header fields from the following sources: - Internet standards - RFCs which are not Internet standards - Non-Internet standards - Other commonly used header fields - Headers implemented in new products - Sometimes used header fields whose use is discouraged. The use of a header field name may be discouraged because it is badly defined, ambigous or used in different ways by different software. The purpose of registering discouraged header fields is to avoid their use in their present or any other future semantic meaning. The registry can contain header fields used in e-mail message headings, MIME content headings, http headings and Netnews article headings. 3. Who can Register a Header field Name Header field names from Internet standards are registered (or the registration modified) by IETF together with the standard specifying the header field. Header fields in other RFCs are registered (or the registration modified) when the RFCs are published. Anyone can propose the registry of additional header fields, but such header fields should be approved by the IETF application area managers before accepted in the registry. This approval should be given if the header field seems reasonable and not in conflict with current usage or other header fields in ways which might cause problem. It is not necessary for approval that the area manager likes the header field 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 http, e-mail and netnews header fields. This is not a formal standards process, but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay. 3.1 Registration of headers from Internet drafts Headers in Internet drafts can be registered on a temporary basis, so that the header registry can be used to find also such headers. If the IETF draft expires, such headers must either be removed from the registry, or changed to reflect their new status (as an IETF standard or as a non-standard documented separately from IETF). 4. Registration Procedure 4.1 Registration Template To: message-headers@segate.sunet.se Subject: Registration of header field: XXX Header field name: Header field status (choices, see section 5.2 Header field Status below) Applicability: (One of COMMON, LIMITED USE or OBSOLETE) What is the header field used for: Who can set or modify the header field: Protocols which use this header field: (One or more of E-MAIL MESSAGE HEADING, E-MAIL CONTENT HEADING, HTTP HEADING, USENET NEWS HEADING) Application programs which use this header field: Encoding considerations: Security considerations: Interoperability considerations: Published specification: Person & email address to contact for further information: Author/Change controller: Expiration month: (For a header field from an Internet draft, this must be the expiration date of the draft. After this time, the registration must either be removed or changed. The word "unlimited" can be used for fields without an expiration month.) (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 field to the "message-headers@segate.sunet.se" mailing list. This mailing list has been established for the sole purpose of reviewing proposed e-mail, netnews and http header fields. You can subscribe to the list by sending a message to "listserv@segate.sunet.se" containing in the text a line with "subscribe message-headers " followed by your name (not your e-mail address), and unsubscribe with a message "unsubscribe message-headers". You can also subscribe through the WWW to http://segate.sunet.se/archives/message-headers.html Archives of this list are available by anonymous FTP from ftp://segate.sunet.se/lists/message-headers/ by HTTP from http://segate.sunet.se/archives/message-headers.html by E-MAIL send a message to LISTSERV@SEGATE.SUNET.SE with the text "INDEX message-headers" to get a list of the archive files, and then a new message "GET <file name>" 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 field 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 field name does not need to make sense for every possible application. If the header field name is intended for a limited or specific use, this should be noted in the submission. 4.3 Submit the Header field name to the IANA for Registration After at least two weeks, submit the proposed header field to the IANA for registration. The request and supporting documentation should be sent to "iana@isi.edu". IANA will ask the application area directors for approval. If approved, IANA will register the header field, assign an OID under the IANA branch, and make the header field registration available to the community. IANA should keep a data base of registered header fields. 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 plain formatted ASCII text as shown in section 11.1. (2) In HTML format as shown in section 11.2. (3) As ASCII text with HTAB between fields and CRLF between lines as shown in section 11.3. Format (1) and (2) are good for human reading, format (3) is good for input to a data base. The header field will be listed in the periodically issued "Assigned Numbers" RFC [2]. The header field description may be published as an Informational RFC by sending it to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [3]). 4.4 Changes to registered headers Minor changes to registered headers, which will not cause problems for those who have already implemented the header, can be done by the person or organisation who has change control for the header. This person or organisation can also add to the register advance notice about future changes under development. The IESG additionally has the right to modify an header field registration, even without permission from the change controller. This right for the IESG should of course be used with great caution. Changes made by an revised version of an IETF standard should be made at the same time as the publication of the revised standard. Other changes require the same approval procedure as for registration of new headers. 5. Clarifications On Specific Issues 5.1 Requirements for a Limited Number of Header Fields 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 header fields used to those "common" header fields expected to be widely implemented. This was asserted as a reason to limit the number of possible header fields and resulted in a registration process with a significant hurdle and delay for those registering header fields. 5.2 Header field Status Any header field 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. Internet draft Header from an Internet draft. If/when the Internet draft expires, the header registry must be changed to indicate its new defining document, for example an IETF standard. X.400. Used to mark header fields which are defined in RFC 1327 and other standards 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. Other standard Defined in standard developed by another standards making body than IETF. Non-standard This header field is not specified in any of the RFCs which define Internet protocols, including Internet Standards, Draft Standards, Proposed Standards and Experimental Standards. The header field appears here because it sometimes appears in http, e-mail or Netnews. Usage of these header fields is not in general recommended. Some header field proposed in ongoing IETF standards development work, but not yet accepted, are also marked in this way. discouraged This header field, which is non-standard or historical, is known to create problems and should not be generated. Handling of such header fields in incoming mail should be done with great caution. controversial The meaning and usage of this header field is controversial, i.e. different implementors have chosen to implement the header field in different ways. Because of this, such header fields should be handled with caution and understanding of the different possible interpretations. 5.3 Requirements for a Published Specification If header fields 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 information specified in section 4.1 Registration Template above should be provided. 5.4 Identification of Security Considerations The registration process requires the identification of any known security problems with the header field name. It is not required that the header field be secure or that it be free from risks, but that the known risks be identified. Publication of a header field name does not require an exhaustive security review. 5.5 Recommendations and Standards Status Issue: The registration of a header field 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 header fields. 7. Acknowledgments Harald Tveit Alvestrand, Ned Freed, Olle Järnefors, Larry Masinter, 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 it. 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 Netnews [4] M. Sirbu: "A Content-Type header field 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 field 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 field for Non-standard Internet Messages", RFC 1154, April 1990. [10] A. Costanzo, D. Robinson: "Encoding Header Experimental field 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 field", 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 field, RFC 1864, October 1995. [18] M. Horton, UUCP mail interchange format Not an official standard, RFC 976, Januari 1986. IETF standard, but in reality a de-facto standard for Netnews [19] R. Fielding, J. Gettys, J. Mogul, H. Proposed Frystyk. T. Berners-Lee: Hypertext standard Transfer Protocol -- HTTP/1.1, RFC 2068, January 1997. [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". Netnews [22] J. Palme: Common Internet Message Header Informational fields. 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: Examples of the publication format of the header registry 11.1 Header registry when published as plain formatted text Header name: Content-Location: Header status: IETF Proposed Standard Applicability: COMMON Use: Gives an URL corresponding to a content part. The content part may, but need not, be retrievable using this URL. Used when sending HTML combined with related objects as aggregate MIME objects. Who can set or modify: Creator of aggregate MIME object Protocols which use it: E-MAIL MESSAGE HEADING, E-MAIL CONTENT HEADING, HTTP HEADING, USENET NEWS HEADING Applications which use Several e-mail clients and web browsers it: Encoding MIME (RFC 2047) and URLBODY (RFC 2017) considerations: Security Various, none serious. Can be avoided by considerations: careful impelementation. See RFC 2110 for details. Interoperability Can interoperate with non-compliant software, considerations: body part will be provided without its URL. Published RFC 2110: MIME Encapsulation of Aggregate specification: Documents, such as HTML (MHTML), March 1997. Contact person: Jacob Palme <jpalme@dsv.su.se> and Alex Hopmann <alexhop@microsoft.com> Change controller: IETF (MHTML working group), chair Einar Stefferud <stef@nma.com> Other information: IETF is working on a revision of RFC 2110. See URL http://www.dsv.su.se/~jpalme/ietf/ mhtml.html for more information. 11.2 Header registry when published in HTML format The HTML document below can also be found at URL http://www.dsv.su.se/~jpalme/ietf/iana-header-field-registry.html <H2><A NAME="html-format"></A>Header registry in HTML format</H2> <H3>Table of contents</H3> <P><I>(Not yet complete)</I> <MENU> <LI>Content-Base <LI>Content-Conversion <LI>Content-Description <LI>Content-Disposition <LI>Contetn-ID <LI>Content-Identifier <LI>Content-Language <LI>Content-Length <LI><A HREF="#Content-Location">Content-Location</A> <LI>Content-MD5 <LI>Content-Return <LI>Content-SGML-Entity <LI>Content-Transfer-Encoding <LI>Content-Type </MENU> <H4>Content-Location</H4> <P><TABLE BORDER=1> <TR> <TD> <P><A NAME="Content-Location"></A>Header name: </TD><TD> <P>Content-Location: </TD></TR> <TR> <TD> <P>Header status: </TD><TD> <P>IETF Proposed Standard </TD></TR> <TR> <TD> <P>Applicability: </TD><TD> <P>COMMON </TD></TR> <TR> <TD> <P>Use: </TD><TD> <P>Gives an URL corresponding to a content part. The content part may, but need not, be retrievable using this URL. Used when sending HTML combined with related objects as aggregate MIME objects. </TD></TR> <TR> <TD> <P>Who can set or modify: </TD><TD> <P>Creator of aggregate MIME object </TD></TR> <TR> <TD> <P>Protocols which use it: </TD><TD> <P>E-MAIL MESSAGE HEADING, E-MAIL CONTENT HEADING, HTTP HEADING, USENET NEWS HEADING </TD></TR> <TR> <TD> <P>Applications which use it: </TD><TD> <P>Several e-mail clients and web browsers </TD></TR> <TR> <TD> <P>Encoding considerations: </TD><TD> <P>MIME (RFC 2047) and URLBODY (RFC 2017) </TD></TR> <TR> <TD> <P>Security considerations: </TD><TD> <P>Various, none serious. Can be avoided by careful impelementation. See RFC 2110 for details. </TD></TR> <TR> <TD> <P>Interoperability considerations: </TD><TD> <P>Can interoperate with non-compliant software, body part will be provided without its URL. </TD></TR> <TR> <TD> <P>Published specification: </TD><TD> <P>RFC 2110: MIME Encapsulation of Aggregate Documents, such as HTML (MHTML), March 1997. </TD></TR> <TR> <TD> <P>Contact person: </TD><TD> <P>Jacob Palme <jpalme@dsv.su.se> and Alex Hopmann <alexhop@microsoft.com> </TD></TR> <TR> <TD> <P>Change controller: </TD><TD> <P>IETF (MHTML working group), chair Einar Stefferud <stef@nma.com> </TD></TR> <TR> <TD> <P>Other information: </TD><TD> <P>IETF is working on a revision of RFC 2110. See URL <A HREF= "http://www.dsv.su.se/~jpalme/ietf/mhtml.html"> http://www.dsv.su.se/~jpalme/ietf/mhtml.html</A> for more information. </TD></TR> </TABLE> 11.3 Header registry when published as a tab-separated table To agree with the allowed formats for RFCs, the section below is encoded with the quoted-printable encoding method. This means that the Horizontal Tab (HT) character is replaced by the string "=09" and that all occurences of "=" followed by End-Of-Line should be deleted from the text below to get the actual format. The IANA published document should *not* be encoded with quoted-printable. Header name:=09Header status:=09Applicability:=09Use:=09Who = can set or modify:=09Protocols which use it:=09Applications = which use it:=09Encoding considerations:=09Security = considerations:=09Interoperability considerations:= =09Published specification:=09Contact person:=09Change = controller:=09Other information: Content-Location:=09IETF Proposed Standard=09COMMON=09Gives an= URL corresponding to a content part. The content part may,= but need not, be retrievable using this URL. Used when= sending HTML combined with related objects as aggregate= MIME objects.=09Creator of aggregate MIME object=09E-MAIL= MESSAGE HEADING, E-MAIL CONTENT HEADING, HTTP HEADING, USENET= NEWS HEADING=09Several e-mail clients and web browsers=09MIME= (RFC 2047) and URLBODY (RFC 2017)=09Various, none serious. Can= be avoided by careful impelementation. See RFC 2110 for= details.=09Can interoperate with non-compliant software, body= part will be provided without its URL.=09RFC 2110: MIME= Encapsulation of Aggregate Documents, such as HTML (MHTML),= March 1997.=09Jacob Palme <jpalme@dsv.su.se> and Alex Hopmann= <alexhop@microsoft.com>=09IETF (MHTML working group), chair= Einar Stefferud <stef@nma.com>=09IETF is working on a revision= of RFC 2110. = See URL http://www.dsv.su.se/~jpalme/ietf/mhtml.html for more= information.
Datatracker
Report a datatracker bug
draft-ietf-drums-MHRegistry-03
None
| Document | Document type |
Expired Internet-Draft
(drums WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author |
Jacob Palme
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |