> --On Tuesday, 02 July, 2002 15:33 -0600 Alexey Melnikov > <mel@MESSAGINGDIRECT.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