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(_at_)tribalwise(_dot_)com>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850