--On Tuesday, 02 July, 2002 21:57 -0700 ned(_dot_)freed(_at_)mrochek(_dot_)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(_at_)bar(_dot_)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