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

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

  Network Working Group                                     Jacob Palme
  Internet Draft                               Stockholm University/KTH
  <draft-ietf-mailext-new-fields-02.txt>                         Sweden
  Category: Experimental                                  November 1995
  Expires May 1996


                 Additional RFC 822 header fields


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) header fields,
Supersedes, and Expires.


Differences from previous version

Differences from previous version <draft-ietf-mailext-new-fields-
00.txt>: The Obsoletes header field has been renamed to Supersedes. A
section with security considerations has been added. One specified
new header field "Auto-Submitted:" has been moved to a separate ietf-
draft. For conformance with RFC 822, the word "attribute" has been
changed to "field" or "header field" and the word "heading" to
"header".







Palme                                                          [Page 1]
draft-ietf-mailext-new-fields-02.txt                          July 1995

1. Introduction

This memo introduces certain header fields for Internet e-mail (RFC
822) headers which will enhance the e-mail service in various ways.

The header fields introduced are: Supersedes and Expires.


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

(a) Thus, this header field 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 field,
or, if PEM [6] or PGP [7] signatures are available, by checking
the digital signature.

Note: A similar header field is defined in X.420 [4], and has been in
common usage in Usenet News.


3. Expires:

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

The Expires header field 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.

Palme                                                          [Page 2]
draft-ietf-mailext-new-fields-02.txt                          July 1995

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


4. Relation to X.400 gateways and to Usenet News

Similar header fields to those defined in this document are also
defined in recommendations for gatewaying [2] between X.400 [3] 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 header fields specified here have
different names in  Internet-X.400 gatewaying standards [2] and in
Usenet News.

RFC 1327 gives the name "Obsoletes:" for what in Usenet News is
usually called "Supersedes:" (not specified in RFC 1036).

RFC 1327 gives the name "Expiry-Date:" for what in Usenet News is
called "Expires:" (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. This
memo should be considered as an update to RFC 1327, specifying that
future X.400-Internet gateways should preferably generate the new
field names "Supersedes:" and "Expires:". However, for best
functionality, it is recommended that such gateways should, on
incoming messages, recognize also the previous names of these fields,
"Obsoletes:" and "Expiry-Date:". Also other mail software might
prefer to recognize both field names in incoming messages, but only
generate the names specified in this memo on outgoing messages.


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.





Palme                                                          [Page 3]
draft-ietf-mailext-new-fields-02.txt                          July 1995

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" header fields
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:" 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.

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.


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



Palme                                                          [Page 4]
draft-ietf-mailext-new-fields-02.txt                          July 1995

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


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]