Date: 5 Mar 1996 21:15:32 GMT
Message-ID: <19960305211532.8177.qmail@koobera.math.uic.edu>
From: djb@koobera.math.uic.edu (D. J. Bernstein)
To: drums@cs.utk.edu
Subject: Re: proposed agenda for 8 March WG meeting

> In your original message, you stated that "multiple RCPTs are a _slowness_ 
> feature."  The only time you have the option of sending multiple RCPTs is 
> when you are sending to multiple recipients at THE SAME HOST.

Correct.

On a message to 100 users over five typical hops, for example, multiple
RCPTs mean that the last user receives his message about an hour later
than he could have.

That's a _slowdown_.

It is, even worse, a slowdown _required_ for unconditional compliance to
RFC 1123 and to your current draft.

It is _not_ an ``efficiency feature.'' If you continue to call it an
``efficiency feature,'' you're being dishonest. It's a minor
bandwidth-saving hack that gets in the way of parallelism and generally
increases latency.

> you have changed your point mid-argument.

My point remains correct, exactly as I stated it.

> Please read the PIPELINING document again.  Parallelizing connections to 
> distinct hosts, along with PIPELINING of RCPTs destined for the same host 
> (don't forget to also PIPELINE the MAIL and DATA commands) is THE BEST YOU 
> CAN DO.

You're living in a fantasy world where everyone supports pipelining.
What, pray tell, do you do with hosts that _don't_ support pipelining?

(Btw, I assume that by ``best'' you're referring to bandwidth---it's not
true for latency, though the reason for this is a bit subtle.)

---Dan