Network Working Group                                     Jacob Palme
Internet Draft                               Stockholm University/KTH
<draft-ietf-mailext-new-fields-07.txt>                         Sweden
Category-to-be: Proposed standard                            May 1997
Expires October 1997


             The Supersedes and Expires e-mail headers


Status of this Memo

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).

This memo provides information for the Internet community. This
memo does not specify an Internet standard of any kind, since
this document is mainly a compilation of information taken from
other RFC-s.. Distribution of this memo is unlimited.


Abstract

This memo introduces two new e-mail (RFC 822) headers,
Supersedes, and Expires. The postscript version of this IETF draft
shows the differences from its previous version.


Differences from previous version

Differences between version 04 and version 05

The syntax of the Supersedes header has been changed from 1#msg-id to
1*msg-id, i.e. LWSP instead of comma between multiple values.

Difference between version 05 and version 06

The main change here is that the standard now specifies the same
recommended practice in both e-mail and netnews. The current
difference in practice in netnews is described and allowed but not
recommended.

The text about the Supersedes header has thus been modified so that
recommended practice is now to allow more than one parameter to this
header in both e-mail and netnews. This means that many netnews
servers as clients may for some time not handle Supersedes with more
than one parameter correctly, but after discussion with some leading
Usenet News software developers, this has been found to be better
than to specify different behavior in the standard for news and e-
mail. Usenet News software developers can be expected to modify their
software.

The other major difference between netnews and e-mail, that
supersedes causes a hard delete in netnews but a soft delete in
netnews, is handled by recommending soft supersedes but allowing hard
supersede.

Difference between version 06 and version 07

Added the sentence "There is no requirement that a user agent must
suppress expired messages or make them inaccessible to their owners."

Added the following clause: "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."

Also some trivial editorial changes.


. Introduction

This memo introduces two new headers for Internet e-mail (RFC 822)
headers which will enhance the e-mail service in various ways. The
names of the new headers are: Supersedes and Expires.


. Supersedes

Syntax: supersedes-field = "Supersedes" ":" 1*msg-id

The message identifiers (msg-id) use the msg-id format, as defined in
RFC 822 [1].

The Supersedes header identifies previous correspondence, which this
message supersedes. A user agent is expected to handle this field in
much the same way as the In-Reply-To and References header.

(a) Thus, this header does not imply any mandatory deletion of the
previous correspondence.

(b) User 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) User 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 the supersedes-
field to inform the recipient that this message supersedes a
previous message.

(d) User agents might issue a warning if a superseding message
arrives with a different author than the author of the superseded
message. This can be done by checking the "From:" header, or, if
PEM [6], PGP [7] or MOSS [8] signatures are available, by
checking the digital signature.

The above procedure is called a "soft supersedes".

Some user agents or servers may delete the old version of a message
when a new version arrives, which is called a "hard supersedes". Hard
supersedes is NOT RECOMMENDED practice, but common, especially in
netnews where servers want to save disk space.

When this is written (1997) some netnews agents (servers and clients)
cannot handle Supersedes with more than one previous articles listed
as parameters. They usually ignore the Supersedes header in this
case, and treats the new article as a separate article, not related
to the superseded article. Implementors of netnews agents SHOULD
modify their software to be able to handle Supersedes with more than
one previous article as parameter, but for some time, many agents may
not be able to handle Supersedes with more than one parameter. 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, BUT such a practice should be temporary only for one or two
years until news agents have been modified.

Warning: This header MUST be spelled "Supersedes" and not
"Supercedes". Mailers MUST never generate "Supercedes" but MAY accept
"Supercedes" in input.

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.


. Expires:

Syntax: Expires-field = "Expires" ":" date-time

The Expires header indicates a date-time, at which this message
expires. The field can be used both to limit and to extend the life
of a message. User agents and servers which employ automatic purging
of old messages MAY let this field influence the purging process.
There is no requirement that a user agent must suppress expired
messages or make them inaccessible to their owners.

Note: This header is also defined, with similar meaning, in netnews
[5] and in X.420 [4].


. Relation to X.400 gateways versus Netnews

Similar headers to those defined in this document are also defined in
recommendations for gatewaying [2] between X.400 [4] and Internet
mail. However, those recommendations are only valid for gateways. By
defining the fields here, the fields are made available for general
Internet e-mail usage. This document also gives fuller descriptions
of the fields than is given by the X.400 gatewaying recommendations
[2].

Unfortunately, the two new headers specified here have different
names in  Internet-X.400 gatewaying standards [2] and in netnews.

RFC 1327 [2] gives the name "Obsoletes:" for what in netnews is
usually called "Supersedes:" (not specified in RFC 1036 [5] but in
common usage).

RFC 1327 gives the name "Expiry-Date:" for what in netnews is called
"Expires:" (as specified in RFC 1036).

Because compatibility with netnews is more important than with X.400,
the netnews names of the fields are proposed here.

Future versions of RFC 1327 (the MIXER document) may choose to
specify the use of "Supersedes" and "Expires" also in gatewayed
messages from X.400.


. Security considerations

5.1 "Supersedes" security considerations

If a mail or news 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 PEM [6] or PGP [7] can require and
check digital signatures to reduce also this risk.

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 does 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 Supersedes in e-mail does not enforce deletion of the
supersedes message, but that Supersedes in many existing netnews
implementations does enforce such deletion, may in some circumstances
cause security problems.

5.2 "Expires" security considerations

One intention of "Expires" is to help recipients avoid seeing
messages with information which is not any longer valid. There may of
course be cases where a user might want to see an expired message
(e.g. a user might sometimes want to be informed of a meeting, even
after the time of the meeting). This could possibly be solved by
having different kinds of "Expires" for different expiration causes,
however, this complexity is not felt needed at present. A user agent
can of course be designed to inform the recipient also of expired
messages, and allow the recipient the choice of reading them or not.
This standard does, therefore, not require user agents to make
expired messages inaccessible.


. Acknowledgements

Many people have helped with the production of this document. Of
special value have been H. T. Alvestrand, S. Kille, K.Moore, P.
Overell and K. Weide.

. References

  []  D. Crocker: "Standard for the format of ARPA Internet text
       messages." STD 11, RFC 822, August 1982.

  []  S. Hardcastle-Kille: "Mapping between X.400(1988) / ISO 10021
       and RFC 822",  RFC 1327 May 1992.

  []  ISO/ITU: "Message Handling Systems", ISO international standard
       10021, ITU  recommendation X.400.

  []  ISO/ITU: "Message Handling Systems, Part 7: Interpersonal
       Messaging System, ISO international standard 10021-7, ITU
       recommendation X.420.

  []  M.R. Horton, R. Adams: "Standard for interchange of USENET
       messages", RFC 1036, December 1987.

  []  S. Kent, J. Linn, D. Balenson, B. Kaliski: 1421 Privacy
       Enhancement for Internet Electronic Mail: Part I-IV,
       RFC 1421-1424, February 1993.

  []  Gary B. Edstrom: Frequently Asked Questions; alt.security.pgp.
       Available from faq servers, such as URL: gopher:
       //nutmeg.ukc.ac.uk.:70/11/.archive/uunet/usenet/news.answers/
       pgp-faq.

  []  S. Crocker, N. Freed, J. Galvin, S. Murphy, "MIME Object Security
       Services", RFC 1848, March 1995.


. Author's address

  Jacob Palme                          Phone: +46-8-16 16 67
  Stockholm University/KTH             Fax: +46-8-703 90 25 (not fast)
  Electrum 230                         E-mail: jpalme@dsv.su.se
  S-164 40 Kista, Sweden




4