Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard

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