Both X.400 and Usenet News have functions to correct messages
which you have sent by mistake.
In Usenet News, you can use the "cancel" command to remove
a message you have sent by mistake. You can then send a new
message with the replacement text.
In X.400, you can send a new message with an "obsoletes"
reference to a message to be replaced. "obsoletes" has
the same syntax as "In-Reply-To".
Hold on. While there is an Obsoletes field in X.400, its use in this way is
strictly implementation defined. Moreover, in practice I've yet to see an
implementation that works this way. I would also refuse unconditionally to use
such an agent assuming it exists, and I suspect a lot of other people would do
so as well.
Obsoletes is a P2 field, populated by P2 message ids (there is a separate ID
in X.400 that's part of the envelope). It is therefore not available to the
transport (i.e. MTA), making it impossible to use it to implement anything that
works like Usenet's cancel functionality.
The specific text in X.420-1992 (section 7.2.8) is cleverly worded to avoid any
security concerns. In the process it also avoids effective refutes any
conclusion that this field be used to actually replace or cancel anything:
The Obsoleted IPMs heading field identifies zero or more IPMs that the
authorizing users of the present IPM consider it to obsolete.
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 exist
in some X.400 user agents (but by no means all).
However, simply replacing a given message willy-nilly stretches things past the
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
messages.)
Note that this assumes that the recipient actually has access to both the
original and obsoleted message. This is by no means a given, and the
possibility that these sorts of references will never be satisfied must be
taken into account. (Remember that this cannot be done on a multiple recipient
basis since this information is not available to the transport layer.)
I note in passing that there actually are mail systems that provide the
capability you're after. Wordperfect Office is the one I'm most familiar with
that has it. A user can cancel or replace a message they've sent to another
user any time they want, literally yanking it right back out of the recipient's
mailbox. But this system is based on an entirely different model of message
control and ownership (a user owns the messages they send in Wordperfect Office
forever, whereas in Internet and X.400 mail ownership transfers to the
recipient on final delivery). This change of model has profound global
implications, and it is not something we can just go ahead and jump into.
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.
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. And worse,
adding a facility that implies a profound paradigm shift requires careful
evaluation of that shift. In this particular case I think the assessment that
"it'll never fly" is a massive understatement.
It might be possible to claim that Internet mail does
have this facility. The reason for this is that RFC 1327
defines an "Obsoletes" RFC 822 heading field, with similar
syntax as for "In-Reply-To". This is defined by RFC 1327 in
order to map the X.400 facility to Internet mail in Gateways
from X.400 to Internet mail.
Question 1: Does this definition i RFC 1327 mean that the
"Obsoletes:" mail heading field is only standardised in
Internet mail for use by gateways from X.400? Or does it
mean that this heading field can be used also in communication
between Internet mail clients where X.400 is not involved?
The result is that Internet mail has the exact same facility that X.400 has.
That is, the obsoletes service element is carried through to the final
recipient, and that recipient is free to do with it as they please. Like it or
not, this is how it works in X.400.
My personal hope is that the answer to this question is that
this feature is also for general Internet mail usage.
If this is the case, my second question is:
Question 2: Are designers of Internet mail message systems
aware that Internet mail has an "Obsoletes:" heading field
so that they can include it in their message systems.
I think you will find that message threading is more heavily supported in
Internet messaging agents than it is in X.400 agents. As to whether or not such
agents can be configured to track obsoletes fields in addition to in-reply-to
and references fields, I don't know enough about it to comment.
If not, what can be done to make them aware of this?
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.
A document explaining how to use this field and recommending that user agents
be made capable of generating it would therefore be a good start. However, it
cannot possibly guarantee the level of service you seem to be after. You are
going to have to settle for this being *at* *most* a rather straightforward
extension of existing threading technology.
Ned