--On Tuesday, 02 July, 2002 17:20 -0700 ned.freed@mrochek.com
wrote:
>> --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"
>>...
> 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.
Me too, fwiw.
> 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.
Yes, but I'd think that is exactly how one would have to do it.
If one were going to find a greatest common denominator among
the recipients with the intent of sending that format with a
single DATA command, you would want to know the format before
you started issuing RCPT commands. That would be especially
important if everyone could accept a high-function format except
one recipient -- it would be rational to remove that one from
the RCPT list and send the low capability format to that mailbox
in a separate transaction.
Is this complex? Sure it is. But, if one is going to end up
with least common denominator, the limiting (and probably
common) case is to just send that and forget about capabilities
negotiation. Or, if the number of useful differentiated formats
is _very_ small, just sending both with multipart/alternative
might turn out to be easier and cheaper than messing around
trying to find feature intersections. There isn't nearly enough
information in the spec for me to be able to guess if that would
be the case. There shouldn't be if this is a general purpose,
multiple-recipient, capabilities negotiation mechanism but, if
it is, I don't see much hope other than dealing with the
complexity (or deciding we don't need something that general).
> 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.
Agreed.
> 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.
Ignoring all of the relay issues, which I still don't think the
document addresses, and the fallback to fax while claiming it
isn't fax-specific, etc., I'd partition the above a bit
differently. I'd guess the dominant approach (especially if one
generalizes beyond fax) is going to be greatest (most capable)
common denominator above a threshold. I.e., if there is some
minimal, default, capability, and some recipients can support
only that (e.g., they don't handle option negotiation at all),
then two messages are going to be sent: one corresponding to the
common feature set of the more capable recipients and one for
the minimal/default feature set. Everyone gets downgraded to
the minimum/default because one recipient isn't highly capable
just doesn't feel commercially viable to me, while assuming a
mix of high-function and low-function hosts does. Other
combinations are possible, but my sense of reality says they
would rapidly turn into message-copy-per-recipient rather than
strange combinatorics on feature sets.
But, in that "two message" case, one really doesn't want 5yz
codes coming back from the server in response to a RCPT TO. If
the "one digit" rule is observed, there is no way to
differentiate between "bad mailbox" and "bad parameter". If it
is not, and three digits are processed, the server cannot
effectively differentiate between a bad parameter to CONNEG and
one to some other option by the code -- the reply string has to
be parsed, and that leads to bad trouble. So I would think
that a batch of capability-determining commands before the first
RCPT one would be a better idea, complexity notwithstanding.
Again, the way to get most of the complexity out of this, IMO,
is to change the problem. For example, if the server makes the
determination of the common capability set among all recipients
and returns it only once (a bit tricky with the SMTP model, but
not impossible), then the client doesn't have to figure out how
to intersect whatever comes back, break things up into separate
messages, etc. But I don't know if that would do the job; it
certainly doesn't handle a mix of high- and low-function
recipients in a plausible way.
john
