Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard
Dave Crocker <[email protected]>
| Newsgroups | gmane.ietf.fax |
|---|---|
| Message-ID | <[email protected]> |
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:[email protected]> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850