Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!PURDUE.EDU!narten
From: narten@PURDUE.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Tcp/Ip vs a store & forward network
Message-ID: <8703311435.AA11791@gwen.cs.purdue.edu>
Date: Tue, 31-Mar-87 09:35:16 EST
Article-I.D.: gwen.8703311435.AA11791
Posted: Tue Mar 31 09:35:16 1987
Date-Received: Thu, 2-Apr-87 06:56:17 EST
References: <8703301830.AA00030@apolling.imagen.uucp>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 40
Approved: tcp-ip@sri-nic.arpa

Geof,

>Similarly, who says that Arpanet mail has end-to-end ACKs?  It just depends
>on where you put the "end."  I put it at the user, and I want to see explicit
>acks from users, too

True, there will never be real end-to-end ACKs if you take things far
enough. An ack for a mail message to some would mean "mail has been
received and READ (and understood :-))". A reasonable compromise would be a
confirmation that the message has been placed in the recipients
mailbox.  Presumably, as domain names get extended, we will be able to
do that.  Any mail you send to a user can go directly to the machine
where the his/her mailbox resides. No forwarding at the site would be
needed.

>On USENET it is normal to keep a copy of a sent message until you receive
>an ACK for it, manually sent by the recipient.  It is reasonable etiquette
>to ACK a message when you receive it

I don't find that acceptable as a *general* way of doing business. This
puts the burden on reliable delivery on the sender and the recipient.
That works for some cases, but requires voluntary compliance of all
users (some who know nothing about mail and networks). Each user has
to think about things such as "Is it time to send the mail again? I
don't have an ACK yet."  It is unworkable when mailing to lists (for
which mail needs to be just as reliable), when the receiver is out of
town, etc. etc.  It is especially a burden for those that send and
receive large quantities of mail.

>My opinion is that mail reading software should encourage this
>behavior by suggesting such a reply and having an automatic way of
>generating it.

This just confirms that most people want reliable mail delivery.
Hence, the burden should be shifted from the user to the software used
for the delivery of mail. It is much easier to do this with a
transport level protocol that connects directly with the destination
machine than over an S&F message switching system.

Thomas