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 <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 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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
   <TITLE>IANA Registry of e-mail headers</TITLE>
   <META name="description"
   content="This is a table of e-mail and Usenet News headers
   registered by IANA.">
   <META name="keywords"
   content="e-mail email netnews Usenet News header heading
   standard format">
</HEAD>
<BODY>

<H1> <IMG SRC="http://www.isi.edu/~touch/images/iu8.gif"
align="middle"
     alt="ISI Logo">
     <A HREF="http://www.inana.org/iana/">
     IANA</A> Registry of e-mail headers
     <A HREF="http://ugweb.cs.ualberta.ca/~gerald/validate/"><IMG

SRC="http://ugweb.cs.ualberta.ca/~gerald/validate/valid_html3.2.gi
f"
     ALT="HTML 3.2 Checked!" align="middle"></A></H1>
<P>
<I>Last update: 15 August 1997.</I>

<P><TABLE BORDER=1>
   <TR>
      <TH align="left" valign="top">
         Description
      </TH><TH align="left" valign="top">
         Name
      </TH><TH align="left" valign="top">
         Reference, status
      </TH></TR>
   <TR>
      <TD align="left" valign="top">
         Special Usenet News actions and a normal article at the
         same time.
      </TD><TD align="left" valign="top">
         Also-Control:
      </TD><TD align="left" valign="top">
         son-of-RFC1036 [21], non-standard, only in Usenet News,
         not in e-mail
      </TD></TR>
   <TR>
      <TD align="left" valign="top">
         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.
      </TD><TD align="left" valign="top">
         Alternate-Recipient:
      </TD><TD align="left" valign="top">
         RFC 1327, not for general usage.
      </TD></TR>
   <TR>
      <TD align="left" valign="top">
         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.

      </TD><TD align="left" valign="top">
         Apparently-To:
      </TD><TD align="left" valign="top">
         Non-standard, discouraged, mentioned in RFC 1211.
      </TD></TR>
   <TR>
      <TD align="left" valign="top">
         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.
      </TD><TD align="left" valign="top">
         Approved:
      </TD><TD align="left" valign="top">
         RFC 1036: 2.2.11, not standardized for use in e-mail.
      </TD></TR>
</TABLE>
</BODY>
</HTML>