Hi all,
Nothing like a good bun fight to grab my attention ;)
Having followed this discussion with interest and having tried to follow the
technical side of the argument, I find myself agreeing with Keith Moore's
notion of using an RCAP (or whatever) command to determine recipient mailbox
capabilities.
I don't know if the following contributes anything or nothing to the debate,
hopefully it is food for thought. Apologies for any repitition or lack of
clarity in what follows, it's late afternoon here and I'm writing quickly.
Using RCAP leads, I feel, to a simpler client and clearer error reports. The
loss of performance due to issuing two commands per recipient is not really
releveant here, IMO.
If I were to design a client that transmits a message in various formats to a
number of recipients, I would first collect the CONNEG capabilities using an
RCAP command for each recipient. I do not care whether the recipient mailbox
is valid, all I want is the CONNEG string. I feel that it is necessary that
RCAP should be issued before MAIL FROM:.
The error code for RCAP is simple and clear, either CONNEG was available or it
wasn't and, in particular, it is not affected by the server's ability to relay
or deliver to that mailbox (I can see no reason that prevents RCAP from
supplying valid CONNEG strings for non-existent mailboxes, perhaps this is
even desirable sometimes). Furthermore there is no need for a
REQUIRED/OPTIONAL or similar parameter to RCAP.
Having obtained all recipient capabilities, the client can make a decision
either to remove the failing RCAP recipients from the list and report an error
for them - the temporary RCAP failures can obviously be retried later - or to
send them the LCD version of the document.
The decision on how to proceed has been determined entirely by the client
based on information supplied by the server. The server has not tried in any
way to second guess the client's intentions or apply any particular
intelligence to the situation.
Based on CONNEG capabilities, or lack of them, the client can now either
generate (or select the best versions from a previously delivered
multipart/alternative document, say) for each recipient. At worst a different
document is sent to each recipient, at best the same document is sent to all
of them. The client can now simply progress to issuing a separate transaction
(i.e. MAIL FROM ... RCPT TO ... DATA) for each version of the document and the
associated recipients. Error handling for MAIL FROM etc. is identical to the
normal case when RCAP is not used. PIPELINING won't affect things much here,
all the RCAPs can be pipelined and the client pauses after issuing the last
RCAP until it has all the responses, then proceeds with MAIL for the first
version of the document. RSET is never required in this scenario (barring
errors that make it necessary).
I also like RCAP because it does not overload two potential failure modes
(CONNEG not available vs recipient not available) on one error code (extended
or not).
By contrast with the sceanrio outlined above, overloading RCPT means that the
client cannot determine what document to send until the entire recipient list
is sent (using RCPT) at which point there is no going back, either RSET is
issued and we start again with one or more transactions determined by the
number of document versions needed or the LCD document is sent with all the
problems raised elsewhere in this thread.
Even with an overloaded RCPT command, I'd probably design a client to issue
MAIL, RCPT ... CONNEG=whatever, ... pause just before DATA and if more than
one document version is needed RSET and proceed with a number of transactions
as outlined above. Given the extra work MAIL, RCPT and RSET must do and when
all I want is the CONNEG string, I'd personally rather have the simpler, more
lightweight RCAP command available. More importantly, because the server
potentially has to choose which error to report from recipient failure vs
conneg failure (not an easy choice, I'm sure) I feel that overloading RCPT
leads to loss of useful information at the client. On balance, I would rather
code for the "edge cases" over two commands than present potentially ambiguous
and misleading reports to the message sender.
Just my 0.02 Euros worth. Of course, I may be way off the mark - I am
prepared to be convinced that the extended RCPT command is the better choice
but so far RCAP seems preferable to me.
Brian Stafford