[Top] [All Lists]

Re: "Obsoletes" is a much needed Internet mail feature

1994-08-18 23:44:05
On Thu, 18 Aug 1994, Ned Freed wrote:

A realistic implementation strategy is to indicate tell the user that a given
message has been marked by somebody as obsoleted and optionally let them
read/use the new version if they prefer. This ends up being a rather
straightforward use of message threading technology, technology that does 
in some X.400 user agents (but by no means all).

However, simply replacing a given message willy-nilly stretches things past 
breaking point, since even if you could check the message for authenticity
there's no infrastructure to determine what can be obsoleted by whom. (There
are plenty of situations where users should not be able to replace their own

What is wrong with my proposal of showing the user the new version (which
is what most users want to see) but clearly indicating to them that this
is an obsoletion, and providing them with a command to see the previous
version also if they so wish? This is the way we have implemented it,
and our experience is that it works fine!

You must have misread my proposal if you understood int to mean that
messages should actually be remotely deleted from mailboxes without
control of the mailbox owner.

Presumably, you might cancel a message in x.400 by obsoleting
it with an empty message.

Obsoleting with an empty message is fine, but the result is not defined
to be a cancel operation as you seem to think.

This is a detail, we can disucss whether obsoleting with an empty
message should have a special meaning or not, it is not an argument
against the idea of the obsoletes feature in general.

It is not clear to me whether Internet mail has a standard
for this facility or not.

Well, it is quite clear that X.400 doesn't have this facility either. 
Basing an Internet facility on a nonexistant X.400 facility isn't a good idea.

My intention was to define the facility in Internet mail as roughly
similar to that in X.400, i.e. not to cause any actual remote
deletions of messages from recipients mailboxes.

The bigger problem is finding applications that are capable of generating
this field. I don't know of any. Until there is some base of application
software capable of generating this field there is no reason to argue for
support of it on the receiving side of things.

The "obsoletes" feature should of course be implemented both on the
sending and the receiving side. You will never get user agents
implemeting it on the receiving side if you do not also recommend
its implementation on the sending side.

Jacob Palme                  E-mail: jpalme(_at_)dsv(_dot_)su(_dot_)se
                             Phone: +46-8-664 77 48 or +46-8-16 16 67
Department of Computer and   Fax: +46-8-664 77 48 between 9 am & 2 pm WET
Systems Sciences (DSV)       Postal address: Skeppargatan 73,
Stockholm University         S-11530 Stockholm, Sweden

<Prev in Thread] Current Thread [Next in Thread>