I have written a draft document with advice on how to implement the
Supersedes, In-Reply-To and References headers in mail and news
user agents.
The document has been submitted to IETF drafts is available at URL:
ftp://ftp.dsv.su.se/users/jpalme/draft-palme-newfields-info-00.txt,
and its text is copied below in this message:
--- --- cut here --- ---
Network Working Group Jacob Palme
Internet Draft Stockholm University/KTH
draft-palme-newfields-info-00.doc
IETF status: To become an informational RFC
Expires: January 1998 July 1997
Advise on the implementation of In-Reply-To, References and Supersedes
e-mail and netnews headers
Status of this Document
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).
Abstract
Separate Internets standards documents define the e-mail headers,
In-Reply-To, References, Supersedes and Expires. This document,
which is an informational RFC, gives some advise on the
implementation of these features.
Table of Contents
1. User interface
2. Hard and soft Supersedes
3. Data base
4. References
5. Author's Address
1. User interface
The fields "In-Reply-To", "References" and "Supersedes" are all used to
convey information about references between different e-mail messages
or netnews articles.
The best way to implement these fields is to tell the recipient that
two messages reference each other, and to make it easy for readers to
traverse threads (series of linked messages) up and down.
In the particular case of "Supersedes", a user who has not yet read
either the old or the new version, may be shown only the new version as
a new message, but with methods to easily find the old version.
A good way to show this information to users is to show the "In-Reply-
To", "Supersedes" and "References" fields and allow the user to click
on the parameters of these fields to get to the referred-to messages.
Additionally, it is useful to add reverse fields to message headers,
i.e. "Replied-By", "Referenced-By" and "Superseded-By". This allows a
user, when reading a message, to see if someone else has already
replied, and it allows users to traverse threads downwards and not only
upwards. Such reverse fields should not be sent in e-mail, they are
just for local handling in user mailbox databases.
2. Hard and soft Supersedes
By a hard supersedes is meant a Supersedes which causes deletion of the
supersedes message. By a soft supersedes is meant a Supersedes which
still keeps both messages, and allows a user to see and use the
reference between them, similarly to In-Reply-To and References.
Supersedes should be implemented as soft supersedes. Some
implementations, especially in Usenet News, do however implement it as
hard supersedes.
Hard supersedes has the same security problem as the Cancel command of
Usenet News. They can be used to malicuosly deleting other people's
messages. Use of strong authentication of the author can reduce this
risk.
3. Data base
In order to implement this, a data base is needed which, given a
Message-ID, can find the message which this Message-ID refers to. This
data base has a very simple structure, just a single value mapped to
one or more messages. Note, however, that the same message can be
stored in more than one mailbox, so the data base should not be
restricted to only one location for each Message-ID.
Every time a message is added, moved, copied, deleted or purged, this
data base need to be updated.
The main problem with these kinds of Message-ID data bases is that they
tend to become very large with time, and they easily collect garbage
(Message-ID-s of messages not any more available in the mailbox data
base).
The two most common methods to implement such data bases are:
(a) Implement a large data base, but with some method of garbage
collection to avoid unlimited growth of the data base.
(b) Implement a smaller data base, where all objects are deleted
after a certain time, for example a few months.
With implementation method (b), information about the references in the
form of "In-Reply-To", "References", "Supersedes", "Replied-By",
"Referenced-By" and "Superseded-By" should also be stored in the
message headers themselves. The reason method (b) works is that it is
very uncommon that a message has a reference to other than very recent
messages. Thus, the lack of "Replied-By", "Referenced-By" and
"Superseded-By" headers in these very uncommon cases is acceptable.
The advantage with method (b) is that a complex garbage collection
method, as for method (a), is not needed. A much simpler garbage
collection method, just removing records after a certain expiration
time, can be used instead.
4. References
Ref. Author, title
--------- --------------------------------------------------------
[AUTOLOOP] J. Palme: "Loop control for the Auto-Submitted e-mail
header", draft-palme-autosub-03.txt, July 1997.
[MIME1] N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, December 1996.
.
[MIME2] N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
December 1996.
[MIME3] K. Moore, "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII
Text", RFC 2047, December 1996.
[MIME4] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration
Procedures", RFC 2048, January 1997.
[MIME5] "Multipurpose Internet Mail Extensions (MIME) Part Five:
Conformance Criteria and Examples", RFC 2049, December
1996.
[NEWFIELDS] J. Palme: "The Auto-Submitted, Supersedes and Expires
E-mail Headers", draft-ietf-mailext-new-fields-08.txt,
July 1997.
[NEWS] M.R. Horton, R. Adams: "Standard for interchange of
USENET messages", RFC 1036, December 1987.
[RFC822] D. Crocker: "Standard for the format of ARPA Internet
text messages." STD 11, RFC 822, August 1982.
[SMTP] J. Postel: "Simple Mail Transfer Protocol", STD 10, RFC
821, August 1982.
5. Author's Address
Jacob Palme Phone: +46-8-16 16 67
Stockholm University and KTH Fax: +46-8-783 08 29
Electrum 230 E-mail: jpalme(_at_)dsv(_dot_)su(_dot_)se
S-164 40 Kista, Sweden
------------------------------------------------------------------------
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme