[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04                                                
Network Working Group                                 Jacob Palme
Internet Draft                   Stockholm University/KTH, Sweden
draft-ietf-drums-MHRegistry-00.txt                   January 1997
Category: Informational                       Expires August 1997

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


Various IETF standards and e-mail software products use various
e-mail header fields. This memo specifies a procedure for the
registration of e-mail header field names, to reduce the risk that
two different mail products use the same header name in different
ways. A proposed initial content of the header name registry at
start-up is specifed in an appendix to this ietf-draft.

Table of contents

1. Introduction
2. Which Headers are Registered
3. Who can Register a Header Name
4. Registration Procedure
     4.1 Present the Request for Registration to the
     4.2 Submit the Header name to the IANA for
5. Clarifications On Specific Issues
     5.1 E-mail Requirements for a Limited Number of
     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. References
9. Author's address
10. Appendix: Proposed initial content of the IETF header
name registry

Temporary comment (not to be included in the published RFC)

The first version is based mainly on two previous documents:
RFC 1590: Media registration

This version will need more discussion on at least the following
- Should every header get its own OID? Would this make conversion
  of Internet e-mail headers to X.400 eaier?
- How much explanation should the header registry contain for each
- Which are the allowed values of the status field in the

Differences between draft-palme-MHRegistry-00.txt and this revised
version draft-ietf-drums-MHRegistry-00.txt:

Two non-standard headers have been added in the appendix,
"For-Comment" and "For-Handling". They are variants of "To:" which
indicate what action this recipient is asked to perform when
receiving this message.

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 that the
same header name is used in different ways by different software

The solution proposed in RFC 822, 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

2.    Which Headers are Registered

The header name registry can contain headers from the following

- 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
  name may be discouraged because it is badly defined, ambigous or
  in different ways by different software. The purpose of
  discouraged headers is to avoid their use in their present or
  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. The procedure described in this
memo is followed by the IANA for review and approval of new e-mail
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   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 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

Archives of this list are available
by anonymous FTP from

by HTTP from

   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 retrieval
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.2   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". Provided a reasonable review period has
elapsed, the IANA will register the header, assign an OID under
the IANA branch, and make the header registration available to the

The header registrations will be posted in the anonymous FTP
directory "ftp.isi.edu:in-notes/mail-headers" and 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.

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

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

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

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

Issue: Header registration requires an RFC specifying the header,
except for header names marked as discouraged in the header

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 textual description
  should be enclosed, which describes the header, its intended use
  and discusses security considerations.

5.4   Identification of Security Considerations

Issue: The registration process requires the identification of any
known security problems with the header name.

Comment: 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 section is
subject to continuing evaluation. 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 me with compiling
the list in the appendix. I alone take responsibility for any
errors which may still be in the list.

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

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

[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

[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

[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
                                                  standard for
                                                  Usenet News

19]  T. Berners-Lee, R. Headering, H. Frystyk:   IETF draft
     Hypertext Transfer Protocol -- HTTP/1.0,

[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
     This document is often referenced under     standard for
     the name "son-of-RFC1036".                  Usenet News

22]  J. Palme: Common Internet Message Headers.  Informational
     January 1997.

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

10.   Appendix: Proposed initial content of the IETF header name

Note: The descriptions in the leftmost columns are intentionally
very brief and may therefore not give a complete and fully
accurate description of the header.

Hint on usage   Header name  Source              Status
--------------  -----------  ------------------  ----------------

Special Usenet  Also-Contro  son-of-RFC1036      Non-standard,
News actions.   l:           [21].               only in Usenet
                                                 News, not in

Controls X.400  Alternate-R  RFC 1327.           X.400.
forwarding.     ecipient:

Inserted by     Apparently-  RFC 1211 and [22].  Non-standard,
Sendmail.       To:                              discouraged.

Mark of         Approved:    RFC 1036: 2.2.11.   Only in Usenet
approval by                                      News, not in
moderator.                                       e-mail.

Specially       Article-Nam  son-of-RFC1036      Non-standard.
important       es:          [21].

Revised         Article-Upd  son-of-RFC1036      Non-standard.
version         ates:        [21].

Has been        Auto-Forwar  RFC 1327.           X.400.
automatically   ded:

Recipients not  bcc:         RFC 822: 4.5.3,     IETF standard.
to be                        RFC 1123:
disclosed.                   5.2.15-16, 5.3.7.

Secondary       cc:          RFC 822: 4.5.2,     IETF standard.
recipients.                  RFC 1123.
                             5.2.15-16, 5.3.7.

Comments on a   Comments:    RFC 822: 4.7.2.     IETF standard.

Base for        Content-Bas  In forthcoming      Soon IETF
resolving       e:           MHTML standard.     proposed
relative URLs.                                   standard.

Conversion      Content-Con  See [22].           Non-standard.
control.        version:

Description of  Content-Des  RFC 1521: 6.2.      IETF draft
body part.      cription:                        standard.

Inline or       Content-Dis  RFC 1806.           IETF
attachment.     position:                        experimental

Unique ID of    Content-ID:  RFC 1521: 6.1.      IETF draft
one body part.                                   standard.

Text string     Content-Ide  RFC 1327.           X.400.
identifier.     ntifier:

Language(s) of  Content-Lan  RFC 1766.           IETF proposed
body part.      guage:                           standard.

Size in bytes.  Content-Len  See [22].           Non-standard,
                gth:                             discouraged.

URI for body    Content-Loc  In forthcoming      Soon IETF
part.           ation:       MHTML proposed      proposed
                             standard.           standard.

Checksum of     Content-MD5  RFC 1864.           IETF proposed
content.        :                                standard.

Return content  Content-Ret  RFC 1327.           X.400.
in X.400        urn:

From the SGML   Content-SGM                      Other standard.
entity          L-Entity:

Coding method.  Content-Tra  RFC 1521: 5.        IETF draft
                nsfer-Encod                      standard.

Format of       Content-Typ  RFC 1049,           IETF draft
content.        e:           RFC 1123: 5.2.13,   standard.
                             RFC 1521: 4.
                             RFC 1766: 4.1

Special Usenet  Control:     RFC 1036: 2.1.6.    Only in Usenet
News actions                                     News, not in
only.                                            e-mail.

Body may not    Conversion-  RFC 1327.           X.400.
be converted    With-Loss:
with loss.

Body may not    Conversion:  RFC 1327.           X.400.
be converted.

When message    Date:        RFC 822: 5.1,       IETF standard.
was created.                 RFC 1123: 5.2.14
                             RFC 1036: 2.1.2.

When message    Delivery-Da  RFC 1327.           X.400.
was delivered.  te:

X.400           Discarded-X  RFC 1327.           X.400.
extensions not  400-IPMS-Ex
mapped.         tensions:

X.400           Discarded-X  RFC 1327.           X.400.
extensions not  400-MTS-Ext
mapped.         ensions:

Tell recipient  Disclose-Re  RFC 1327.           X.400.
about other     cipients:

Limitation of   Distributio  RFC 1036: 2.2.7.    Usenet news
distribution    n:                               only, not in
area.                                            e-mail.

Trace of lists  DL-Expansio  RFC 1327.           X.400.
passed.         n-History-I

Several         Encoding:    RFC 1154,           IETF
different                    RFC 1505,           experimental
incompatible                                     standard.

Where to send   Errors-To:   See [22].           Non-standard,
notifications.                                   discouraged.

Expiration      Expires:     RFC 1036: 2.2.4.    Usenet news
date.                                            only, not in

Expiration      Expiry-Date  RFC 1327.           X.400.
date.           :

Fax number of   Fax:                             Non-standard.

File where      Fcc:         See [22].           Non-standard.
message is

Where to        Followup-To  RFC 1036: 2.2.3.    Usenet news
discuss item    :                                only, not in
further.                                         e-mail.

Variant of      For-Comment  See [22].           Non-standard.
"To:"           :

Variant of      For-Handlin  See [22].           Non-standard.
"To:            g:

(1) Message     From         See [22].           Discouraged in
separator in                                     transport of
files.                                           e-mail.

(2) Usenet      From         RFC 976: 2.4        Usenet news
news delivery   or                               only, not in
path.           >From                            e-mail.

Author          From:        RFC 822: 4.4.1,     IETF standard.
                             RFC 1123:
                             5.2.15-16, 5.3.7,
                             RFC 1036 2.1.1

Delivery        Generate-De  RFC 1327.           X.400.
report          livery-Repo
generation      rt:

Values: High,   Importance:  RFC 1327 and        IETF
normal or low.               RFC 1911.           experimental

Message being   In-Reply-To  RFC 822: 4.6.2.
replied to.     :

Body parts are  Incomplete-  RFC 1327.           X.400.
missing.        Copy:

Search keys     Keywords:    RFC 822: 4.7.1
for retrieval.               RFC 1036: 2.2.9.

Language of     Language:    RFC 1327,           X.400.

Size of the     Lines:       RFC 1036: 2.2.12.   Usenet news
message.                                         only, not in

Generating      Mail-System                      Non-standard,
client          -Version:                        discouraged.

Generating      Mailer:                          Non-standard,
client                                           discouraged.

Unique ID of    Message-ID:  RFC 822: 4.6.1      IETF standard.
this message.                RFC 1036: 2.1.5.

Report or       Message-Typ  RFC 1327.           X.400.
message.        e:

Version of      MIME-Versio  RFC 1521: 3.        IETF draft
MIME.           n:                               standard.

Newsgroups      Newsgroups:  RFC 1036: 2.1.3,    Usenet news
getting this                 see also[22].       only,
article.                                         discouraged in

Previous        Obsoletes:   RFC 1327.           X.400.
message being

Sender          Organisatio                      Discouraged.
organzation.    n:

Sender          Organizatio  RFC 1036: 2.2.8.    Usenet news
organization.   n:                               only,
                                                 discouraged in

Body part       Original-En  RFC 1327.           X.400.
types in        coded-Infor
message.        mation-Type

Generating      Originating                      Non-standard,
client          -Client:                         discouraged.

List of MTAs    Path:        RFC 1036: 2.2.6.    Usenet news
passed.                                          only, not in

Phone number    Phone:       .                   Non-standard
of the

Priority,       Precedence:  See [22].           Non-standard,
might                                            controversial,
influence                                        discouraged.

Non-delivery    Prevent-Non  RFC 1327.           X.400.
report          Delivery-Re
control.        port:

Priority,       Priority:    RFC 1327.           X.400.

Trace of MTAs   Received:    RFC 822: 4.3.2,     IETF standard.
passed.                      RFC 1123: 5.2.8.

Reference to    References:  RFC 822: 4.6.3      IETF standard.
other                        RFC 1036: 2.1.5.

Latest reply    Reply-By:    RFC 1327.           X.400.

Where to send   Reply-To:    RFC 822: 4.4.3,     IETF standard
replies.                     RFC 1036: 2.2.1     but
                              see also [22].     controversial.

Information     Resent-Repl  RFC 822: C.3.3.     IETF standard.
about manual    y-To:,
forwarding.     Resent-From:,

Envelope info   Return-Path  RFC 821,            IETF standard.
at final        :            RFC 1123: 5.2.13.

Where to send   Return-Rece  See [22].           Non-standard,
notifications.  ipt-To:                          discouraged.

Related         See-Also:    Son-of-RFC1036      Non-standard.
articles.                    [21].

Sender if not   Sender:      RFC 822: 4.4.2,     IETF standard.
same as in                   RFC 1123:
from header.                 5.2.15-16, 5.3.7.

Disclosure      Sensitivity  RFC 1327 and        IETF
secrecy.        :            RFC 1911.           experimental

Whether         Status:      See [22].           Non-standard,
message has                                      should never
been                                             appear in mail
delivered.                                       in transit.

Title,          Subject:     RFC 822: 4.7.1      IETF standard.
heading,                     RFC 1036: 2.1.4.

Short version   Summary:     RFC 1036: 2.2.10.   Usenet news
of long                                          only,
message.                                         discouraged.

Replaces        Supersedes:  Son-of-RFC1036      Non-standard.
previous                     [21].

Fax number of   Telefax:                         Non-standard.

Primary         To:          RFC 822: 4.5.1,     IETF standard.
recipients.                  RFC 1123:
                             5.2.15-16, 5.3.7.

Generating      X-Mailer:                        Non-standard.

Generating      X-Newsreade                      Non-standard.
client          r

Control of      X400-Conten                      Non-standard.
content-return  t-Return:

Other           Xref:        RFC 1036: 2.2.13.   Usenet news
newsgroups                                       only, not in
getting the                                      e-mail.
same article.