At 08:32 PM 7/3/2002 -0400, John C Klensin wrote: >I don't either. My concern is that it is fairly poorly defined >in relay scenarios What needs to be defined that is not defined? This is a hop-by-hop protocol, just like all of SMTP. If there is relaying with CONNEG support, then CONNEG is used at each hop. Just like for DSN. Do I think that this is the epitome of efficiency? No. But then, hop-by-hop mechanisms often suffer with respect to some aspects of efficiency. The reason for hop-by-hop is not "efficiency" but rather for reliability/safety. And the current specification is only one way to obtain CONNEG information. If a better one is available and satisfactory, then by all means use it. > -- partially, I assume, because its utility is, at best, unclear right. it is not at all obvious that an organization might want to have a corporate email firewall accept the message with a CONNEG exchange and then relay it through the corporate network to the mailbox. after all, such a scenario for regular email is not all that popular. > 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. see above. and it strikes me that the idea of having an SMTP option that is prohibited from use in relaying is rather more massively significant than whether this particular option will work well in relaying circumstances. >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. One might also want to consider that the concept of obtaining per-recipient capabilities rather naturally suggests a tendency to do per-recipient tailoring of content. One does not need any history of fax to note the likelihood of the one-to-one case being dominant. One might even suspect that it is inherent. > 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. Complicated? I guess it is not clear what would be simpler and equally useful (as well as equally flexible.) So please, provide an example of this alternative to the current specification that is sufficiently simpler so as to render the current specification inappropriate. It also would be good to make a distinction between working well in the most likely scenario, versus preventing any scenario except the most likely. d/ ---------- Dave Crocker <mailto:dave@tribalwise.com> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850