Organization of the header name space

[Olle Jarnefors <[e-mail]>]

Here are some ideas for a better organization of the name space
for RFC 822 mail headers, netnews headers [RFC 1036], and HTTP
headers [draft-ietf-http-v10-spec-04.txt]. Hopefully these (or
better ideas), if applied, could lead to a better utilization
of the name space when these protocols are extended, and the
avoidance of unproductive skirmishes like the recent about
Content-Location versus Location.

When Jacob Palme's draft on Common Internet Message Attributes
[draft-ietf-mailext-mail-attributes-03.txt] becomes an
informational RFC, I hope the opportunity will be taken to
create an IANA registry of header names. Reasons for doing that:

a) The prospect of such a registry has been held out since 1982,
   for 13 (!) years: "Names of Extension-fields are registered
   with the Network Information Center, SRI International, Menlo
   Park, California." [RFC 822, 4.7.5]

b) Palme's work seems to be a good foundation, bringing together
   information from all messaging standards used on the
   Internet, and also the most important non-standardized
   headers. Information about HTTP headers can easily be
   gathered from the HTTP 1.0 draft.

c) The recent controversies about the use of the Newsgroups
   header in mail and about Location versus Content-Location in
   HTTP and HTML via mail shows that the coordination of the use
   of a common name space by different protocol development
   communities, despite good intensions, is not always
   effective.

d) If a registration mechanism, similar to that for media types,
   were instituted for headers, the troubling ambiguity of
   non-registered headers can be removed, so that:
   >  If a header is used whose name doesn't begin with "X-", it
      must have the same syntax and semantics as a header with
      that name registered with IANA.
   >  If a header with some other syntax or semantics is used,
      it must have a name starting with "X-".

   (Non-registered headers, called user defined fields, can have
   any non-registered name, according to RFC 822. The HTTP 1.0
   specification also allows such headers: "Unknown header
   fields are treated as Entity-Header fields." [section 4.3]
   This means that they are treated as describing the content of
   the HTTP message.)

I also believe that it would be useful to bring a more visible
order to the name space for headers by enforcing different
prefixes for different categories of headers, when new header
names are standardized or registered. (There's not much to do
about the chaos among the already standardized headers, which
all have a considerable installed base.)

A division of the registered headers into these groups would
be useful, I think:

1) Content-*  content-related headers
2) Message-*  general communication-related headers
3) Mail-*     mail-related headers
4) News-*     network news-related headers
5) HTTP-*     HTTP-related headers
6) Local-*    message store-related headers

I have categorized most currently used headers in these groups
at the end of this message.

Local-* headers maybe can't be standardized within IETF, but the
prefix "Local-" should be reserved, and it should be possible to
register such headers and public specifications of them.

An additional group is:

7) X-*        headers without a publicly available specification

In another message on the [e-mail] mailing list, I
have suggested that headers that have become detrimental to the
continued distribution of a message, e.g. when redistributed by
a mailing list exploder, should not be removed.  Instead they
should be kept in the message in a harmless form, be putting
"Old-" at the beginning of the header name. So another special
group could be:

8) Old-*      original headers that have been shut off

A new mechanism for allowing interoperable use of headers that
aren't registered, and whose names may clash, is possible by
means of URLs (and in the future URNs).

The syntax and meaning of such a header would be defined in a
document whose URI (URL/URN) is given in a special header. Say
that you want to use the Content-Foo header defined by company
Bar at ftp://bar.com/specs/headers.txt. Then you could choose
some prefix not already used, say Z-, and include in the
message:

   Message-Header-Ext-Definition: Z; ftp://bar.com/specs/headers.txt
   Z-Content-Foo: ...

And if you also needs the Content-Foo header, but as defined by
user group Baz at ftp://baz.org/formats/foo.txt, you choose
another prefix, such as:

   Message-Header-Ext-Definition: Y; ftp://baz.org/formats/foo.txt
   Y-Content-Foo: ...


Currently used headers
----------------------

1) Content-related headers -- Content-*
       Keywords+:  Summary:  Expires:*  Supersedes 
       Last-Modified*  MIME-Version+*  Content-ID+ 
       Content-Description+  Content-Type+*  Content-Langauge+ 
       Content-Disposition+  Content-Encoding*  Location* 
       Lines:  Content-Length*  Organization:/Organisation 
       Fax/Telefax  Phone  Postal 

2) General communication-related headers -- Message-*
       From+:  Sender+:  Date+:*  Reply-To+:  Message-ID+: 
       References+:  Subject+:  Comments+ 
       Content-Transfer-Encoding+ 
       User-Agent*/Mail-System-Version/Mailer/Originating-Client
       Resent-From+  Resent-Sender+  Resent-Date+  Resent-Reply-To+
       Resent-Message-ID+

3) Mail-related headers -- Mail-*
       Received+  Return-Path+  To+  Cc+  Bcc+  In-Reply-To+ 
       Resent-To+  Resent-Cc+  Resent-Bcc+

4) Network news-related headers -- News-*
       Newsgroups:  Distribution:  Followup-To:  Approved: 
       Path:  Xref:  Control: 

5) HTTP-related headers -- HTTP-*
       Pragma*  Authorization*  If-Modified-Since*  Referer* 
       Server*  WWW-Authenticate*  Allow* 

6) Message store-related headers -- Local-*
       Status  Fcc 

+ Header defined in RFC 822, MIME or other mail standard
: Header defined in RFC 1036 (network news)
* Header defined in HTTP 1.0

In this overview I have neglected headers from the obsolete
RFC 1154, and from RFC 1327 and 1496 (X.400<->Internet Mail).

/Olle

--
Olle Jarnefors, Royal Institute of Technology, Stockholm <[e-mail]>