Hi Alex,
Thanks for clarifying AP#4 and response modification
cases. We may have a
scope problem here, similar to what we had with HTTP when we
realized that
we have to deal with 1xx responses. OPES/HTTP scope is
adaptation of a
single HTTP request or a single HTTP response augmented by
request info.
In OPES/SMTP, we currently seem to be talking about adapting
a single SMTP
command or a single SMTP command response (augmented by the
corresponding
command info, I guess?). Is that the right scope?
I guess we have consensus now that we concentrate on command
modification/satisfaction (see the other message I just sent
that double checks this).
Yes, I think we should consider one OCP request to correspond
to a single SMTP message.
It was
reasonable to
limit OPES/HTTP scope to request/response because HTTP is
mostly stateless
(and OPES is not allowed to adapt HTTP connections which are kind of
statefull in HTTP). However, could it be a design mistake to
introduce the
same scope boundaries for adaptation of a stateful SMTP
dialog? It seems
to me that results/information from earlier commands would
have to be
known to OPES callout servers adapting later commands.
We assumed that many OCP servers in the HTTP response profile
need the original HTTP request as meta data and will request this.
Same thing here I guess.
If a OCP server indicates that it wants to act on the RCPT or
DATA command, it may also require the MAIL FROM data to be sent
as meta data because it wants to know about this sender and not
only the one listed in the email message's From header.
I tried to illustrate this earlier. See my message from Jan 13:
While we see the need to involve the callout server on a per-command basis,
the commands and replies of one dialog belong together
and services may have the need to refer to earlier commands of the same
dialog.
Should
OPES/SMTP
scope be an entire dialog related to a "single" email (and
not a single
command from that dialog)?? Can a callout server reliably
adapt an SMTP
dialog by modifying isolated commands, without controlling
and knowing the
entire command sequence??
Depends on the service I guess.
This should be negotiated with the profile I think. Which
commands is the OPES processor wants to allow to modify?
Which commands is the callout server interested to modify
and which commands are needed as meta data with later command
mod requests?
This should be negotiated.
I wonder whether we can reduce data exchange for services that
want to act on multiple commands by doing several command
modification requests within a single OCP transaction context.
What is the primary difference between OPES/SMTP and Milter
approach: If
we wrap Milter calls in OCP, would we get OPES/SMTP?
Needs someone who knows Milter better than me to answer.
Regards
Martin