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

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