At 02:22 PM 7/14/2002 -0400, John C Klensin wrote:
First of all, I don't find, anywhere in the document, a statement
that the originator, in attempting to use CONNEG, is authorizing
any intermediate MTA that might touch the message to alter its
content.
For a specification that is designed to permit a sending agent to know how
to tailor the form of a content, it is difficult to imagine what benefit
there can be in having that specification contain a statement saying that
an implementation is "authorized" to tailor the form of that content.
Dave, that may be what your specification is *designed* to do. It is
not what your specification *does*, except in the rare case where the
sender's UA is able to communicate directly with the recipient's MX.
And the sender's UA is the only "agent" that is typically under control of
the sender.
Nor do I find in the "security considerations" an
explanation of that authorization and the associated risks.
You clearly have a better sense of this issue than I do, since I do not see
that there is a problem.
So, feel free to offer some text.
How about this:
This extension MUST NOT be used by any SMTP client which is not authorized
to perform conversion by either the sender or the recipient of the message.
We have
typically tried to keep that transmission stream as opaque to
message content as possible.
Yup. It sure is scary to try to do new things.
Except when there is a well-established basis for doing them.
I am not inclined to dismiss that established basis solely because it came
from a non-IETF effort, particularly given the scale of success of that
prior work.
Nor, apparently, are you inclined to cite that established basis.
Perhaps it is because it is not applicable?
But, unless I read the above incorrectly, you are suggesting that
* Hence intermediate/relay MTAs have the right/authority
to make content changes based on their inferences about
what the receiver wants.
Let's try to stay on the current topic.
Yes, lets. Why don't you actually address these technical criticisms
of your proposal rather than disingenenously pretending that they don't
apply?
What I mean is very simple:
The behavior that is specified in esmtp/conneg is a careful
increment in functionality and is based on extensive prior experience and
is known to be useful.
Dave, unless you can actually cite relevant experience in the field of
multi-hop, store-and-forward multimedia messaging, I see no reason why we
should not conclude that you have no basis whatsoever for claiming that your
current proposal is worth any more consideration.
Keith