Re: Keywords for "SMTP Service Extension for Content Negotiation"

[Keith Moore <moore@xxxxxxxxxx>]

> 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