--On Tuesday, 02 July, 2002 15:33 -0600 Alexey Melnikov
<mel(_at_)MESSAGINGDIRECT(_dot_)COM> wrote:
More comments about the document.
The draft doesn't explain what to do if the same fax messages
was sent to multiple recipients with different rendering
capabilities. Should it downgrade for the least capable
recipient? Or should it use RSET and start multiple mail
transactions to differently capable recipients? Correct me if
I am wrong, but it seams that extending VRFY command is more
appropriate for the purpose than using RCPT.
Hmm. _That_ is an interesting idea, since we have always
permitted VRFY to do somewhat more poking around in real time
than one might normally expect of RCPT (where "poking around"
efforts more often result in a 250 code and an email rejection
if needed). While VRFY is, I think, less and less often
supported in a serious way, an SMTP extension that could not be
advertised unless it was supported for this function would get
around that problem.
I considered proposing this back when I initially reviewed the document. It is
certainly far more aesthetically appealing to me than the RCAP command Keith
proposed.
However, after looking at the actual use cases I become convinced that this
isn't the clear win it appears to be a first glance.
The advantage of having a separate command that returns recipient capabilities
withing adding that recipient to the set of active recipients is, of course,
that you don't have to RSET and start over if you uncover an incompatibility
between multiple recipients.
But there's a serious side effect: Advance capability retrieval tends to stall
the pipeline. And while it is natural to view SMTP as a series of commands and
responses, the way modern SMTP clients and servers need to work to be efficient
is by sending batches of commands and getting back batches of responses.
The naive implementation of capabilities exchange in a separate command then
becomes the worst case scenario: If you send a VRFY (or RCAP) prior to sending
each RCPT TO you end up with at least one round trip per recipient.
Of course you can work around this by sending all the VRFYs/RCAPs in a batch
prior to sending any RCPT TO. But the implementation complexity here is
starting to be a serious issue.
Another alternative would be to allow capabilities retrieval on either RCPT TO
or VRFY. But now the client has a lot of options and approaches to choose from,
which I don't think is a good thing.
I think the determining factor needs to be how clients will actually handle
recipients with differing capabilities. If the least common denominator is
going to be the dominant approach (and I suspect that it will be) then RCPT TO
capabilities return is the simplest and most direct approach. If, on the other
hand, messages tailored for a each recipient is going to be the norm, then
VRFY is the correct approach.
Ned