Network Working Group Jacob Palme Internet Draft Stockholm University/KTH draft-palme-newfields-info-02.doc IETF status: To become an informational RFC Expires: May 1998 November 1998 Advice 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), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society 1998. All Rights Reserved. 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 advice on the implementation of these features. Table of Contents 1. User interface 2. Hard and soft Supersedes 3. Data base 4. Copyright 5. References 6. 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. A good 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. It is also possible to have special features to see a whole thread (set of related messages) graphically, or as an indented list, and to allow users to traverse, print, save or do other actions on a thread. Example of showing a thread as an indented list: This is entry no. 1, the start entry of the thread This is entry no. 2, a reply to entry no. 1 This is entry no. 3, a reply to entry no. 2 This is entry no. 4, a reply to entry no. 1 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 way to show this information to users is to show the "In-Reply-To", "Supersedes" and "References" fields, possibly as buttons, and allow the user to click on them to get to the referred-to messages. Additionally, it is useful to add buttons to follow threads forward, with texts like "Next in thread" or "Replies" or "This document is referenced by" or "Superseding documents". 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 buttons should not be sent in e-mail, they are just for local handling in user mailbox databases. Note that their values may change after a message has been submitted, when more new messages arrive which reference it. Example of showing a message with thread information: To: IETF-Announce: ; From: The IESG <iesg-secretary@ns.ietf.org> Subject: Last Call: The Auto-Submitted, Supersedes and Expires Headers in E-mail and Netnews to Proposed Standard In-Reply-To: <v04003a00b12335fb8686@ns.ietf.org> Replied-By: <v04003a00b12335fb8687@ns.ietf.org> Date: Thu, 05 Mar 1998 07:02:47 -0500 Sender: scoya@cnri.reston.va.us 2. Hard and soft Supersedes By a hard supersedes is meant a Supersedes which causes deletion of the superseded 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, somewhat similar to In-Reply-To and References. Supersedes is best implemented as soft supersedes. Users of the supersedes field should however be aware that some implementations, especially in Usenet News, do implement it as hard supersedes. Hard supersedes has the same security problem as the Cancel command of Usenet News. They can be used to maliciously delete other people's messages. Use of strong authentication of the author can reduce this risk. 3. Data base In order to implement threads, 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 copied to 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. When a new message arrives, the mailer can find the messages, to which this message has references. Note that there is a risk that replies arrive before the replied-to message, so a good implementation should work even in this case. A 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 purging to avoid unlimited growth of the data base. (b) Implement a smaller data base, where all objects are deleted after a certain time. A couple of months is enough if the techniques described in the next paragraph are used. 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 can be used instead, just removing records after a certain expiration time. 4. More implementation hints More implementation hints can be found at URL http://www.dsv.su.se/~jpalme/ietf/thread-support-proposal.html See also URL http://www.dsv.su.se/~jpalme/ietf/jp-ietf-home.html#newfields 5. Acknowledgements Peter Kaminski has given me valuable ideas for this document. 6. 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 implementation 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. 7. 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-12.txt, March 1998. [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. 8. 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