INTERNET-DRAFT Jacob Palme Network Working Group Stockholm University/KTH draft-palme-supersedes-00.txt Sweden Expires August 1999 February 1999 The Supersedes or Replaces Header in E-mail Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society 1998. All Rights Reserved. Abstract This memo introduces one new e-mail header, Supersedes. This document may, if accepted by the IESG, become a proposed standard, at some time in the future. Differences from draft-ietf-mailext-new-fields-14.txt Most of these changes are to agree with a similar specification by Charles Lindsey on the Supersedes and Replaces headers in Usenet News, which is being developed as part of the IETF USEFOR working group, and by other suggestions made in the USEFOR mailing list. Parameters "noshow", "show" and "repost" have been added to the "Supersedes" header, in accordance with discussions in the usefor mailing list. A parameter "version=<decimal-version-number>" might also be considered, but has not been added. The discussion in chapter 1.2.1 Who may supersede a message/article? has been extended to more fully explain the reasons for the recommended practices for implementing hard supersedes. A discussion note has been added to chapter 1.2.4 When to use soft and hard supersedes to explain why the author of a message may want hard superseding of a message in certain cases. Table of contents 1. Supersedes 1.1 Syntax 1.2 Semantics 1.2.1 Who may supersede a message/article? 1.2.2 Semantic variant 1: Soft supersedes 1.2.3 Semantic variant 2: Hard supersedes 1.2.4 When to use soft and hard supersedes 1.2.5 Multiple field values 2. Security considerations 3. Copyright 4. Acknowledgments 5. References 6. Author's address 1. Supersedes 1.1 Syntax Supersedes-field = "Supersedes:" CFWS identifier *(identifier) optional-parameter-list [CFWS] CRLF optional-parameter-list = *( ";" LWSP parameter ) parameter = parameter-name [ "=" parameter-value ] parameter-name = "noshow" / "show" / "repost" private-parameter / future-parameter Note: There is no comma between multiple values, and that each Message-ID value is to be surrounded by angle brackets. Warning: Some software may not work correctly with comments in header fields, especially comments in other places than at the beginning and end of the field value. Warning: This header MUST be spelled "Supersedes" and not "Supercedes". 1.2 Semantics The Supersedes header identifies previous correspondence, which this message supersedes. Different messaging agents such as user agents, mailing list expanders and mailing list archives. A user agent is expected to handle this field in much the same way as the In-Reply-To and References header. Note: The Message-ID of a superseding message MUST be different from the Message-ID of the superseded message. The Message-ID of the superseded message is used as value in the "Supersedes:" header, not in the Message-ID of the superseding message. Parameters: noshow In the opinion of the sender, this message makes such a minor change to the superseded version, that a recipient, who has already seen the previous verson, will probably not want to see the new version, unless the user explicitly asks for it. show In the opinion of the sender, this message makes such a large change to the superseded version, that a recipient, who has already seen the previous version, will probably want to see the new version, too. repost This document is a document which is repeatedly, at regular or irregular intervals, reposted, such as FAQs or mailing list monthly information. None of these parameters have values. The "noshow" and the "show" parameters are mutually exclusive, but both of them can occur together with the "repost" parameter. 1.2.1 Who may supersede a message/article? Agents receiving superseding messages MAY ignore, or issue a warning, for the Supersedes header, if the author of the message is not approved. Approved authors of superseding messages MAY be: (1) The author of the message being superseded. (2) For moderated mailing lists, the moderator. Note that a moderator may only supersede messages/articles in groups, for which the moderator is responsible, and such a moderator SHOULD not send superseding messages/articles to other groups. Discussion: There are two kinds of moderated lists, pre-moderated and post-moderated. In pre-moderated lists, the moderator approves all contributions before they are sent out to list members. In post-moderated lists, contributions are sent out immediately, but the moderator can supersede inappropriate contributions afterwards. The advantage with pre-moderated lists is that no inappropriate contributions will ever be sent out. The advantage with post-moderated list is faster turnaround time in discussion threads. (3) Other users given the authority to supersede messages. Such authority is often local to one particular server only. Discussion: A server administrator may be legally required to supersede illegal messages, if these are available for download by people who have not yet received them. An agent MAY ignore or issue a warning for Supersedes headers if the Superseding message does not have a verifyable digital signature of its author or another agent who the agent owner thinks should be allowed to supersede this message. Digital signatures are separately standardized (like SMIME [9] and PGP [10] or other standards for digital signatures) and their format and semantics are not specified in this standard. 1.2.2 Semantic variant 1: Soft supersedes (a) With soft supersedes this header does not imply any mandatory deletion of the previous correspondence in mailboxes and user agent databases. The user is still able to view old versions of superseded messages. (b) Agents which provide user commands for getting from a reply to the replied-to message (or for getting from a replied-to message to its replies), MAY provide similar commands for getting from a superseding message to the superseded message (or for getting from a superseded message to its superseding version). (c) Agents MAY normally show the recipient both the previous and the superseding message. If, however, both the previous and the superseding message have arrived, both having the same author, but the user has not yet seen either of them, a user agent MAY show only the superseding message, but also show a mark to inform the recipient that this message supersedes a previous message. 1.2.3 Semantic variant 2: Hard supersedes With hard supersedes, the arrival of a superseding message or article will cause the deletion of the superseded message. The new message will however still have a new Message-ID and will not take over the Message-ID of the superseded message/article. 1.2.4 When to use soft and hard supersedes Hard and soft supersedes are differentiated by the receiving client, not the sender. There is no format difference in the header between hard and soft supersedes. Mail stores under the control of an individual user (for example, POP or IMAP mail boxes) SHOULD implement soft supersedes but MAY implement hard supersedes, possibly only as an (off by default) option. (Please read the security considerations if you plan to implement this). Multi-user message archives and servers MAY implement HARD supersedes. Discussion: A person, who has by mistake written an illegal message, may be legally required to hard supersede the illegal message, in places where it is available for download by people who have not yet received it. Note: In Usenet News, servers commonly implement hard supersedes. If the handler of a message/article storage has a mechanism for automatic purging of old messages, the fact that there is a superseding message may be a component in the decision of when to purge the previous version. 1.2.5 Multiple field values When this is written (1999) some Usenet News softwares cannot handle Supersedes with more than one previous articles listed as parameters. This can be expected to change, but until then, a gateway from e-mail to news MAY because of this delete all but the first parameter of this attribute when conveying messages from e-mail to news. 2. Security considerations If a server or receiving user agent suppresses showing of superseded messages, the "Supersedes:" feature might be used maliciously to suppress messages written by other people. To reduce the risk for this, it is RECOMMENDED that user agents give a warning to the recipient when a superseding message has a different "From:" name than the superseded message. A moderately clever forger can of course circumvent this by sending messages with falsified "From:" field and even falsified SMTP senders. User agents supporting S/MIME [9] or PGP [10] or other standards for digital signature can require and check digital signatures to reduce also this risk (see section 1.2.1 above). Even more reduction of security problems can be achieved if user agents handle "Supersedes:" exactly in the same way as "In-Reply-To:" and "References:", i.e. show both versions of the message, and only use the "Supersedes:" header as information to readers of messages of the relation between different messages. Another possible risk with "Supersedes:" is that it allows people to "change their minds", possibly changing the meaning of replies to them. Example: A message with the text "Do you like your mother" gets the reply "Yes, very much", and then the original message might be changed to "Do you like Hitler", changing the meaning of the reply. Note, however, that the "In-Reply-To" or "References" headers in the reply refers to the Message-ID of the original message, not of the superseding message. Thus, a user agent can avoid this problem by designing the user interface so that replies are not shown as referring to the superseding message, when they use the Message-ID of the superseded message. Also, since "Supersedes:" in e-mail is meant to not actually cause deletion of the superseded message, recipients can look up the superseded message to see if the author has changed his mind. In general, it is not illegal or unethical to change your mind, rather, it shows your openness to new ideas and willingness to listen to the arguments of other people. The fact that some implementations of Supersedes cause deletion of the Superseded message (hard supersedes, section 1.2.3 above), but others do not (soft supersedes, section 1.2.2 above), may cause security problems. To reduce this problem, a server should clarify its policy on this to its users and follow the recommendations in section 1.2.4 above. 3. Copyright and disclaimer The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat." The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 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 implmentation 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. 4. Acknowledgments Many people have helped with the production of this document. Of special value have been R. Allbery, H. T. Alvestrand, A. Bowesman, B. Franz, P. Hoffman, S. Kille, S. Lyall, K. Moore, P. Overell, U. Paz, E. Sommarskog, H. Spencer, J. Stanley, B. Templeton, K. Weide and R. Zellich 5. References [1] D. Crocker: "Standard for the format of ARPA Internet text messages." STD 11, RFC 822, August 1982. [2] S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021 and RFC 822", RFC 1327 May 1992. [3] ISO/ITU: "Message Handling Systems", ISO international standard 10021, ITU recommendation X.400. [4] ISO/ITU: "Message Handling Systems, Part 7: Interpersonal Messaging System, ISO international standard 10021-7, ITU recommendation X.420. [5] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996 [6] K. Moore, G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. [7] K. Moore, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996. [8] M.R. Horton, R. Adams: "Standard for interchange of USENET messages", RFC 1036, December 1987. [9] B. Ramsdell: S/MIME Version 3 Message Specification. Work in progress. [10] J. Callas, L. Donnerhacke, H. Finney, R. Thayer: OpenPGP Message Format. Work in progress. [11] J. Palme: "Advise on the implementation of In-Reply-To, References and Supersedes e-mail and netnews headers", draft-palme-newfields-info-02.doc, March 1998. [12] D. Crocker: Augmented BNF for Syntax Specifications: ABNF, RFC 2234, November 1997. 6. Author's address Jacob Palme Phone: +46-8-16 16 67 Stockholm University/KTH Fax: +46-8-783 08 29 Skeppargatan 73 E-mail: jpalme@dsv.su.se S-115 30 Stockholm, Sweden