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