- 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