--On Tuesday, 02 July, 2002 17:20 -0700 ned(_dot_)freed(_at_)mrochek(_dot_)com
wrote:
--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"
...
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