You can avoid the need for additional round trips by batching all the
capabilities queries with the first RCPT TO. But this results in a rather
sharp
rise in implementation complexity.
surely is it less complex than what is required by the current protocol - i.e.
doing a RSET followed by additional MAIL and RCPT commands.
That's quite a bit of overhead, for something that frequently will have no
effect on the content being transferred.
actually I don't see why putting the conneg response in a separate command
is "quite a bit of overhead" - the extra bandwidth required for
"RCAP <recipient>" is neglibible, there's no difference in the response
at all, and the client logic to deal with separate commands is simpler since
the client doesn't have to distinguish ordinary RCPT failures from CONNEG
failures. and the client doesn't have to do RSET followed by a separate set
of MAIL/RCPT commands for each recipient if for some reason it wants or needs
to deliver different versions of the message to different recipients.
Indeed. The average number of recipients for legitimate mail does tend to be
quite small, which implies we're optimizing the uncommon case here.
to understand the tradeoff it may be useful to compare each proposal under
the same set of scenarios. e.g.
a. single recipient
b. multiple recipients, all with similar capabilities
c. multiple recipients, different capabilities
d. multiple recipients, mutually exclusive capabilities
with each case evaluated for
a. ease/simplicity of implementation,
b. necessary round-trip delays,
c. future extensibility
Keith