One document matched: draft-ietf-mailext-new-fields-05.txt

Differences from draft-ietf-mailext-new-fields-04.txt

             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 from previous version
<draft-ietf-mailext-new-fields-04.txt>:

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.


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

Palme                                                       [Page 1]
draft-ietf-mailext-new-fields-05.txt                      July 1996


2. Supersedes

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

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

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

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

Usenet News: A similar header has been in common usage in Usenet 
News. However, in Usenet News, Supersedes causes a hard delete of the 
supersedes message in the data base of servers. Despite this 
difference between supersedes in Usenet News and e-mail, gateways 
between e-mail and Usenet News SHOULD not remove the Supersedes 
header.

Another difference between the Supersedes header in e-mail and in 
Usenet News is that Usenet News usually only accepts an article to 
supersede one previous article. Thus, if an e-mail Supersedes 
references more than one Message-ID, this may not work in Usenet 
News, or all but the first Message-ID-s might be deleted by gateways 
from e-mail to Usenet News.



Palme                                                       [Page 2]
draft-ietf-mailext-new-fields-05.txt                      July 1996


Because of this, use of Supersedes with more than one Message-ID is 
discouraged for messages which are expected to be gatewayed to Usenet 
News and gateways from e-mail to Usenet News SHOULD remove all but 
the first Message-ID from the Supersedes header.


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

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


4. Relation to X.400 gateways versus Usenet News

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 Usenet News.

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

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

Because compatibility with Usenet News is more important than with 
X.400, the Usenet News 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.









Palme                                                       [Page 3]
draft-ietf-mailext-new-fields-05.txt                      July 1996


5. Security considerations

5.1 "Supersedes" security considerations

If a 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 
falsified messages. User agents supporting PEM [6] or PGP [7] can 
require and check digital signatures to stop 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 Usenet News usually 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.




Palme                                                       [Page 4]
draft-ietf-mailext-new-fields-05.txt                      July 1996


6. 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, K. Weide, 

7. 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]  M.R. Horton, R. Adams: "Standard for interchange of USENET
       messages", RFC 1036, December 1987.

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

  [7]  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.

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


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











Palme                                                       [Page 5]