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).
I guess I remain to be convinced either way: That multiple versions schemes are
necessary or that a single version schemes are sufficient. I'd guess there's a
sweet spot somewhere in there. Unfortunately in this particular case the
location of that spot drives a bunch of design choices.
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,
I must say I don't see any of this as particularly useful in a relay scenario.
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.
I certainly agree with the common denominator above a threshhold. But given
that a single recipient per destination is likely to be a very common case, I'm
less sure that simpler approaches won't be commercially viable. Or perhaps
capabilities will be used to reduce the number of variants sent with
multipart/alternative.
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.
It may indeed turn out that per-recipient message copy is the right way to
finesse the feature set combination issues.
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.
I'm not sure I get what you're driving at here. The client gets
to choose whether the server treats a recipient with unknown
capabilities as an error or simply by indicating as much.
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.
I considered proposing this as well, but it seemed to be that knowledge
of what the client can actually do may determine how differing
feature sets are combined.
Ned