> 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
