Re: Conneg with intermediaries

Dave,

#I'm still in Japan. I leave here in Tuesday evening.

Basically, I agree. But, before that, I have a question.

In the latest I-D (-03), senarios for relay is described in Appendix.
If my understanding for your intension is correct,
the relay case is informative and the description does not
mandate the behaviour.
Do you think the idea below should be included in Appendix?

Also, although you tell not to mention it now,
how is the list conveyed?

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: [email protected]



From: Dave Crocker <[email protected]>
Subject: Conneg with intermediaries
Date: Sat, 16 Nov 2002 08:34:16 -0800

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