Re: Supersedes in e-mail (was) Apology: Test your knowledge of Internet application layer

[Jacob Palme <jpalme at DSV.SU.SE>]

At 05.57 +0200 98-08-05, Robert Elz wrote:
>   | I hope the draft above will soon be accepted by the IESG as
>   | a proposed standard.
>
> I certainly hope it does not.  E-mail (like regular mail) is the property of
> the recipient (intellectual property rights aside).  Once you have sent it,
> you have absolutely no right to attempt to destroy it -- that you have to do
> before you decide to send the message.   What you are
>asking for is equivalent
> to the right to forcibly retrieve a paper letter you have sent me, which
> no-one would agree to.   Usenet is more like a public bulletin board, where
> it is perfectly normal for people to take down their messages when they
> cease to be relevant.

You have not read the latest version of the draft you are
criticising. There is nothing in the draft saying that the
sender can destroy messages after they have been delivered
to the recipient mailbox. Quite the opposite, the draft
clearly specifies that this should not be recommended!

I copy the relevant text from the draft below. You can see
from this text, that the draft clearly specifies the
opposite of what you believe. The main problem with this
IETF draft has been that it tries to specify use of these
headers which will be acceptable in both the mail and news
communities. I believe this is valuable, because I believe
that more and more gatewaying will occur between news and
mail, because more and more clients combine both services
in the same client, and because it is confusing to users if
things work differently in news and mail. I believe the
text below solves these problems in a reasonable way.

-- copied text from the draft --

The Supersedes header identifies previous correspondence, which this
message supersedes. Different messaging agents such as user agents,
mailing list expanders, mailing list archives and Usenet News servers
may handle the Supersedes header. 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.

4.2.1 Who may supersede a message/article?

Agents receiving superseding messages may ignore, or issue a warning,
if the author of the message is not approved. Approved authors of
superseding messages are:

(1) The author of the message being superseded.

(2) For moderated newsgroups and 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.

(3) Other users given the authority to supersede messages. Such
    authority is often local to one particular server only.

An agent may ignore or issue a warning for Supersedes headers if the
Superseding message does not have a digital signature of its author.
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.

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

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

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

4.2.4 When to use soft and hard supersedes

Personal mailboxes and personal message stores SHOULD implement soft
supersedes. Usenet News servers and multi-user message archives MAY
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.
------------------------------------------------------------------------
Jacob Palme <jpalme at dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme