RE: Conneg with intermediaries

I would suggest looking at RFC 3238 for all of the requirements for "things that change things in the network."

There is a lot more, like traceability, that SMTP conneg would have to do.  It's not impossible, but I doubt we would get anything through the IESG that did not satisfy RFC 3238.

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Saturday, November 16, 2002 11:34 AM
> To: IETF-FAX
> Subject: Conneg with intermediaries
> 
> 
> 
> Folks,
> 
> I'd like to explore the an approach changing SMTP-based 
> Conneg. There is a
> very basic concern that an intermediate SMTP relay will make arbitrary
> changes to the sender's content.
> 
> How can the sender "authorize" an intermediary to make 
> changes using CONNEG?
> 
> How can the sender tell the intermediary which changes are 
> authorized and
> which ones are not?
> 
> One idea is for the sender to added its own list of CONNEG 
> features to the
> message. Because the list is attached to the message, 
> intermediaries are
> authorized to make changes. The list specifies the features 
> ("capabilities")
> that are authorized for changing. An intermediary MUST NOT 
> make content
> changes for any feature not listed by the sender.
> 
> 
> ----- So the scenario for doing SMTP Conneg has the following:
> 
> A message travels through a sequence of SMTP relays.  
> Eventually it reaches
> an SMTP transition in which the receiving SMTP server 
> announces that it
> supports CONNEG.
> 
> The sending SMTP relay also supports the feature.  But is it 
> authorized to
> use it?
> 
> The message contains a Conneg list that was provided by the 
> sender.  (Let's
> not talk about how this is attached to the message.  We can 
> consider that
> after we agree on the basics of this authorization mechanism.)
> 
> The fact that the Sender's Conneg list is present means the 
> SMTP client
> relay is authorized to make transforms.
> 
> The SMTP client relay does a logical intersection between the 
> list provided
> by the sender and the client relay's own list of capabilities that it
> supports.
> 
> Assuming that the intersection results in a non-zero set of authorized
> transforms, the client relay then queries the receiver for an 
> addressee
> and the receiving SMTP server returns the CONNEG capabilities for that
> addressee.
> 
> The client relay performs another logical intersection between its own
> conneg list and the list from the receiving SMTP server.
> 
> It now has a list of content forms that are authorized by the 
> sender and
> supported by the receiver and that the intermediary can support
> transforming.
> 
> ----- end of scenario
> 
> Is this acceptable?  If yes then I will try to specify 
> changes to the SMTP
> Conneg draft.
> 
> d/
> -- 
>  Dave Crocker  <mailto:[email protected]>
>  TribalWise <http://www.tribalwise.com>
>  t +1.408.246.8253; f +1.408.850.1850
> 
>