> 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