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

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.


>   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.


>   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.


>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.  Arguing about generic principles 
and then trying to dismiss current work based on some subtle variation in 
interpretations of that abstract discussion is not going to be productive.

You might want to review prior work on interprocess communication, which 
explored trade-offs between a "sender makes right" model and a "receiver 
makes right system".

The significant difference between esmtp/connect and multipart/alternative 
is exactly this distinction.

(Hint:  sender makes right has nearly always been the preferred IETF 
choice.  esmtp/conneg is sender makes right.)


>Could you explain what you did mean?

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 Crocker <mailto:[email protected]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850