Re: Keywords for "SMTP Service Extension for Content Negotiation"

> >- new command RCAP??
> 
> The current ESMTP/CONNEG specification uses the RCPT command for finding 
> each recipient's capabilities.
> 
> Moore-san prefers to have the capabilities query be in a separate 
> command.  For convenience, he has given this command a name, RCAP.  So, the 
> name refers to an idea that Moore-san has.  There is no written 
> specification for that command.  In my opinion, the current specification 
> is satisfactory.

this is a little misleading.

if a message is being sent to more than one recipient then there is a 
possibility that different recipients will need different versions of the 
content, or that some recipients will be unable to accept the content at all.

if the message being transmitted is a fax and all recipients are capable of fax, 
then perhaps it is acceptable to downgrade the message to a lower quality fax 
format which is acceptable to all.   however this is not always possible for
recipients in general - a SMTP server is allowed to support CONNEG if some, 
none, or all of its recipients support fax reception.

the use of the RCPT response to tell the client of the recipient's capabilities
is odd because it asserts that the client intends to deliver a message to
each of several recipients before the client actually knows whether it can 
deliver the same version of the message to each recipient, or whether it can
deliver any version of that message to the recipient.  

so as the proposal is written, any client which attempts to deliver a message
to multiple recipients in a single transaction must be prepared to abort the
current SMTP transaction (presumably by using RSET) after sending multiple RCPTs, 
to divide up the RCPTs according to which version of the message each is capable 
of receiving, and to start some number of new transactions for that purpose.  

if nothing else, that seems a bit confusing and it introduces the potential
for implementation errors.  

it's been claimed  that using RCPT in this way is faster that using a separate 
command, though I haven't actually seen an analysis of this.  I wonder if
such analysis is based on an assumption that it will usually be possible to 
downgrade the message to a common format that is acceptable to all recipients,
and I wonder if that will actually be true in practice.    but even if performance 
considerations justify using RCPT instead of a separate command, it would still 
be appropriate to document the need for clients to abort the current transaction 
if not all recipients can accept the same format.  the current proposal fails
to mention this at all.  this would be easy to fix.

another problem with RCPT is that it expects the server to return status codes
for error conditions that can only be distinguished on the client.

RCAP is just one of several ideas that have been suggested to do content
negotiation in a way that is simpler, more robust, and less confusing to 
implementors than the current proposal.  Dave is correct that there is no 
formal proposal for RCAP - though since the entire reason for proposing RCAP 
is to have something simpler, a detailed proposal hardly seems necessary to 
describe it.  Anyone with a good understanding of SMTP should be able to 
evaluate the relative merits of the current proposal, RCAP, and the other 
suggestions without having a detailed proposal for each one.

The following description for RCAP should be enough:

1. the command looks like this:   RCAP <recipient-address>

2. the server responds with one of the following  

2xx-recipient capabilities are as follows:
2xx-<conneg string goes here>
2xx

2yy recipient has no specified capabilities

2zz no information available about recipient capabilities

4xx recipient capabilities are temporarily unavailable

5xx error (for example, syntax error)

specific values for 2xx, 2yy, 2zz, 4xx, 5xx are to be determined.

3. if the server supports the ENHANCEDSTATUS codes extension then
the most appropriate enhanced status code should follow the 2xx,
2yy, 2zz, 4xx, or 5xx response code in the manner specified in RFC 2034.

4. the RCAP command is acceptable at any time that MAIL or RCPT 
would be acceptable.  clients MAY issue RCAP before or after MAIL,
and they MAY issue RCAP and RCPT commands in any order.
(though generally it makes more sense to issue RCAP for a 
recipient before sending RCPT for that recipient)
The RCAP response MUST be the same regardless of whether the
command is issued before or after MAIL, or before or after RCPT.

5. the RCAP command has no effect other than to query the server
about a recipient's capabilities.

6. the RCAP command does not indicate whether a recipient address
is valid or whether delivery of a message to the recipient will 
succeed.  any response - 2xx, 2yy, 2zz, 4xx, 5xx - is potentially
valid even for a nonexistent recipient or one which is not allowed
to receive mail.  for example, an SMTP server for a webmail 
environment which provided the same capabilities for all recipients
could return 2xx and the same conneg string for any recipient
address, regardless of whether that recipient were valid.

Keith