RE: [draft-ietf-opes-smtp-use-cases-01]

At 11:02 20/01/2005, Martin Stecher wrote:
>Hi,
>seems that we first need a common understanding of the wording and
>deployment scenario.

Agreement. I apologize for not having been clear enough. I think I have 
used the concepts accurately but I did not say it, so you have understood 
it differently because you do not consider the same granularity. But I 
think we need it. I will try to explain.

>The filtering functionality is on the callout server.

Not in my scheme. The reason why is that we all know that an MTA is built 
in module and that a filtering/returning process may not be  the same 
depending where it happens and where it returns.

>No difference between HTTP and SMTP here. The callout server may
>even support adaptation of both messages for both protocols.
>That is our application agnostic approach. The callout server
>is an OCP server with some filtering services.

This is where I disagree in part: it may be several servers depending where 
in the MTA architecture it is related to and to which servers it is related 
to (through OCP or not).

Let assume that there is a decision to clean the outbound list for U2 when 
U1 has received the mail. This action cannot be taken before the outlist 
module because no other module will ever know it (a mail may stay a few 
minutes in the different modules and days in the outlist - or whatever the 
name for that type of MTA)

>The OPES processor is a standard device that sits in the data stream
>of the protocol we want to handle. That device gets enhanced by an
>OCP client that allows to vector out that data to the callout server.
>In HTTP the OPES processor is a proxy server; for SMTP we picked
>a MTA as the primary device that sits in the SMTP data stream.

This assumes that the OPES processor is an unique device/service. It can be 
in a network of OPES processor and take decisions on a mail depending on 
information negotiated on that network.

>Much too complicated in my view

I fully understand it. But what you propose here is a daisy chain http 
scheme. This is an exact but a-minima scheme. I do not see it scaling:
- one to one mail becoming one to many
- one single standard OCP action becoming different modules involvements
- no connection between OPES processors scaling to cross feedback among all 
the processors
- there is a single mail path when there are several mutually dependent 
(through OPESed modifications)

>Let me try to bring in the other M*A things here and map that to
>the normal programs that we see today when sending email:

No problem with that. But we have to document this RFC is for "normal" 
program and to define normality.

>Do we agree on what I wrote here?

With that limitation which transforms a mail in an asynchronous http, 
certainly. I think this may help to reduce the complexity of the real life 
applications (I opposed as too complex, if you remember). If this is 
something everyone agrees I am OK. All the more than I suspect that the 
code modularity will permit to do what I say - the complexity being on the 
OPES processors).

My question on text changes remains.
jfc