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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]