HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 10:42:31 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 07 Jul 1997 11:40:00 GMT ETag: "361d6e-1bc8-33c0d590" Accept-Ranges: bytes Content-Length: 7112 Connection: close Content-Type: text/plain 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@dsv.su.se S-164 40 Kista, Sweden