> > 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