But there's a serious side effect: Advance capability retrieval tends to
stall
the pipeline. And while it is natural to view SMTP as a series of commands
and
responses, the way modern SMTP clients and servers need to work to be
efficient
is by sending batches of commands and getting back batches of responses.
The naive implementation of capabilities exchange in a separate command then
becomes the worst case scenario: If you send a VRFY (or RCAP) prior to
sending
each RCPT TO you end up with at least one round trip per recipient.
I don't understand which argument you're making - is it that the naive
implementation is slow, or that it's too hard to do an efficient
pipelining implementation?
Both: The naive implementation has latency problems while the efficient
pipelining implementation is more complex than it needs to be.
as long as RCAP doesn't force any new decision points for the client,
I don't see why the efficient pipelining implementation is any more
difficult for the RCAP case than the RCPT/RSET case.
Then I suggest you haven't actually looked closely at how you'd actually code
this. Two responses for each recipient lead to a bunch of corner cases that
have to be dealt with.
if RCPT is overloaded then the client sends multiple RCPTs, waits for
all of the responses, then decides whether to just send one copy or
do RSET/MAIL/etc and send multiple copies.
if there's a separate command then the client sends multiple RCAPs,
and one RCPT, waits for all of the responses, and then decides
whether the version that's right for the first recipient is also
appropriate for other recipients.
seems like the implementation complexity is about the same in either case.
Sigh. This is pretty much a strawman argument, but rather than get into that
let me simply repeat my earlier conclusion: I believe that if support for
sending more than one variant of the same message is likely then a separate
command makes sense. If, on the other hand, this is the very uncommon case,
then RCPT TO piggybacking is much simpler and a separate command doesn't make
sense.
Do you really wish to claim otherwise?
but it's hard to see how the client can avoid implementing some
kind of logic to convert differently for different recipients, since
there's clearly the potential for the recipients' conneg strings to
have no format in common. perhaps if the client can only do one
or two different kinds of conversion (otherwise it has to bounce)
then the decision becomes a bit easier, but this again looks more
like a fax-specific facility than a general one.
On the contrary, I suspect that this issue can and will be avoided. John
phrased it well: Select the least common demoninator that's above a certain
threshhold. That sounds like the right implementation strategy to me.
Ned