--On Tuesday, 02 July, 2002 21:57 -0700 ned.freed@mrochek.com
wrote:
>> 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 agree completely.
>> 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.
I don't either. My concern is that it is fairly poorly defined
in relay scenarios -- partially, I assume, because its utility
is, at best, unclear -- but that the document says it applies to
relays. That leaves us in what may be an "almost nothing but
edge cases" situation, which is typically a bad way to be doing
standards. If we can't see enough utility for relay situations
to justify working out the cases --and I can't-- then why not
ban the relay cases until and unless someone demonstrates that
they are relevant is does the work.
>> 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.
Makes sense. Makes much more sense if relaying is banned.
Otherwise, "one recipient per destination" slides over really
easily into "send everything to her, and let her deal with
splitting the stuff up by destinations and capabilities", and
that introduces all the complexity.
That still leaves "one virtual fax, one recipient" (and, by
definition, one destination) as a probably-very common case,
given real-world fax behavior today. Also given that behavior,
that case is certainly commercially viable. But this is
awfully complex for that case: we could generalize it into a
single command or capabilities statement.
>> 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.
Of course, that is another generalization of "one virtual fax,
one recipient": one message, one recipient, one set of
capabilities. And a vastly simplified protocol.
>> 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.
Suppose the client sends
RCPT TO:<foo@bar.baz> CONNEG=REQUIRED;bazoption=REQUIRED
and gets back
504 option parameter stinks - REQUIRED
or
504 bad parameter - CONNEG REQUIRED
in the one-digit case, it can't distinguish either one from
500 Never heard of foo
in the three-digit case, the first 504 variant doesn't give a
clue as to the difference between "don't know the client's
capabilities" and "REQUIRED is not a valid parameter for
bazoption". The second variant is better, but requires parsing
of a string whose format is not precisely specified. To some
degree, this is a general problem with multiple ESMTP
option-parameter sets, but it seems to be that the CONNEG case
is a little worse than average.
>> 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.
Yes, but what a nightmare. To really get it right may require
fairly complete knowledge of what the client can actually do
_and_ fairly complete knowledge of what the recipient (not just
the receiving server) can actually do. In a better world, that
requires an MUA-MUA negotiation, but we don't have any semantics
for talking about that (especially in SMTP). Of course, forcing
the problem into
one receiving MUA
no relay
would permit getting close without giving all of us a bad
headache. But I don't know if that is feasible. What I'm
getting fairly sure of is that the present document is rather
seriously underspecified for the mind-boggling general case.
john