At 09:31 PM 7/3/2002 -0400, John C Klensin wrote:
Would you
expect the client to work its way through those combinatorics in
real time,
yes.
no matter what the details are, computing the intersection is not that
difficult and the computation of such issues does not take that long. No
matter what the computations are.
As to the question of real-time generation of the chosen transform(s), that
bridge was crossed as soon as the client went down the path of CONNEG. In
other words, if the client wants to do ESMTP/CONNEG, it has better be
programmed to do the necessary real-time transforms.
Alternately, the client could notice that the different
recipients had different capabilities (_that_ ought to be fairly
easy in real time, especially if each of them announced its
capabilities in the same order and using the same syntax --
which the spec doesn't seem to require)
doesn't use the same syntax?
as to order: were we doing data processing of millions of records, fixed
position formats might make sense. We don't do it for message or content
headers, why should we do it for these attributes?
but the potentially-long SMTP connection
times (in the RSET, figure out the formats and build them while
the SMTP connection is still open, and then send them
separately) or abandoning the connection and starting over
and RSET is markedly inefficient, yes. that's clear.
my personal expectation is that a client will either be designed to send
the least common denominator of the address list response capabilities, or
it will send the addresses one per DATA and tailor each.
the alternative that has been the subject of such delightful speculation,
here, with the RSET required, strikes me as worth very little of any
implementor's time.
Just trying to understand the expected situation...
The spec is pretty simple, and it is mostly based on a set of previous work
involving CONNEG.
The situations for the spec's use are also pretty simple.
The actual uses will no doubt have some surprises, because new features
always have surprises.
So what *I* would like to understand is where this is going.
There are some small writing errors in the specification that have been
noted and will be changed. There are some suggestions for clarification
and/or guidance that seem pretty reasonable, to.
As to the rest of the discussions about the thread, I have so far failed to
detect any analysis that discloses a failure in the specification, of the
type: "it won't work".
So, as I say, what *I* would like to understand is where this is going.
d/
----------
Dave Crocker <mailto:dave(_at_)tribalwise(_dot_)com>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850