Path: utzoo!attcan!sobeco!unibase!thud!regina!herald.usask.ca!alberta!ubc-cs!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!ifi.uio.no!enag
From: enag@ifi.uio.no (Erik Naggum, the Internet Purist)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Certified SMTP mail
Message-ID: <9102110842.AA02908@holmenkollen.ifi.uio.no>
Date: 11 Feb 91 08:42:04 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 68

In article <1991Feb10.205047.2217@oilean.uucp>, Joe McGuckin writes:
> I think it's a great idea.  But why stop there?  Why not have an
> additional confirmation that informs you when the message was
> actually read...

I think (yet another) reality check on this topic is needed.  It can
be exemplified by the question:

	How often do you send registered mail?

If that is every time you send a letter, I sympathize with your need
to do the same with e-mail.  If not, I claim that you're going to do
it every time if it were possible, for a large number of "you".

The second, corollary problem is that even for a limited number of
users who request receipts on any of the events "message received",
"message read", "message understood", "mission completed", etc, on all
messages sent, the volume of mail will likely escalate exponentially.
Also, see below for a related volume problem.

The third problem is the Three Armies problem, where two allies A and
B are separated by an Enemy controlled area.  A can communicate with B
only _through_ the Enemy controlled area.

Say A plans to do a two-flank attack on E, and this requires the
cooperation of B, since a one-flank attack is close to suicide.  A
sends B a message: "Will attack from W at 0430.  Pls ACK."  The
following occurs:

	(1) B doesn't get the message (ordonance caught, shot, drown...)
	(2) B gets the message, and ACKs, but needs an ACK.

	    (1) A doesn't get the ACK.
	    (2) A gets the ACK, ACKs, but needs an ACK.

		(1) B doesn't get the ACKed ACK.
		(2) B gets the ACKed ACK, ACKS, needs ACK.

		    ...

As should be obvious, a lack of ACK is not a NAK.  An ACK is not
guaranteed to be delivered, and thus must be ACKed, ad infinitum.
Also, in the absence of an ACK, should A retransmit until an ACK is
received?  Should each party retransmit ACKs until properly ACKed?
What is the terminating condition of this recursion?

Consider what options exist in the absence of a "secure" ACK.  Either
party may not get the message or the ACK, but believe that the other
party has got it, for any iteration of the above process.  This may be
suicide, and may not be a viable option.

What would you do?  Or rephrased: If you don't get an ACK "message
received, read, understood, mission completed", which of the four
possible NAK conditions is true, or did the ACK fail to get delivered?

The corollary to this third problem is that the network will become
saturated with ACKed ACKs, or retransmitted messages.  The latter will
also occur if the recipient is not equipped to reply, or chooses not
to for any number of reasons.

So, the summary of this rather elaborate exposition of this one
problem of basic network technology, is:

	You don't want that.

--
[Erik Naggum]					     <enag@ifi.uio.no>
Naggum Software, Oslo, Norway			   <erik@naggum.uu.no>