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?
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.
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.
either way the sender wants to divide up the recipients into separate
classes and batch up the messages to each. assuming it's trying to
optimize, that is. of course the naive/inefficient implementation is
quite easy (and equally slow) for both proposals - just use no more
than one recipient per SMTP session.
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.
Keith