It looks like the big question here is about control over user
preferences. To me, it seems unreasonable to assume that all user
preferences are handled at the OPES processor. It is just too rigid of
a model and often very inefficient since the processor knows very
little about filtering and the filter (OPES server) may need to know a
lot. If we restrict user preference handling to OPES processor, we end
up passing a lot of preference information to the OPES server just so
that it can process a transaction.
I'm afraid we are going too deep with analysis of this specific scenario.
If I understand correctly Martin used preferences just as an example of
the reason why callout processor may produce multiple responses
for a single request.
There may be any number of reasons for the callout processor to
produce multi-message response, the protocol just SHOULD (MUST?) support
multiple responses while preserving transactional integrity.
We should not (MUST NOT) impose any limitation on what
information is available to the callout processor (including
preferences) and how OPES processor and callout processor assign
tasks between themselves while performing a collaborative
processing - this is application specifics and should be
out of scope for protocol design.
Oskar
Ideally, OPES processor should manage user preferences that affect the
decision of what to filter. OPES server should manage user preferences
that affect the filtering algorithm. But we should not assume a
one-size-fits all scheme.
Thus, it looks to me that Martin's example is valid. I am just not yet
sure whether the performance optimization is worth the complexity.
That is why I asked for more similar uses.
Alex.
On Mon, 17 Feb 2003, Martin Stecher wrote:
I have a different view on this.
Your filtering example is based on delivery to an SMTP server that
knows that the recipient of the single message is actually an alias.
No, I am not talking about an alias.
It is a very common SMTP behavior that one message is sent to
multiple recipients, especially if they belong to the same domain.
This happens in the SMTP dialog.
After the first HELO and MAIL FROM messages the sending MTA sends
multiple RCPT TO messages which get all acknowledged one by one.
The receiving SMTP MTA keeps the list of all recipients and
delivers to all of them (sometimes it needs then to create copies,
sometimes not).
The OPES service must know the expansion of the alias to the 20
recipients (any one of which could actually be an alias for another
list). This means that the SMTP service and the OPES service are very
tightly coupled. As I said, I'd always assumed that the OPES
processor
would have the user preferences, and that's the whole reason for the
rules, etc., and for having the OPES processor be the
enforcement point
for privacy policy. But, I guess that assumption is open to debate.
I believe that there will be several implementations of OPES
processors that do not want to deal with the complete user
preferences and rule engine, but leave this work for the callout service.
But there's another reason that I'm still not convinced that this SMTP
example applies to OPES. If this service and all the user preferences
are handled by a callout server, there's no reason that the callout
server cannot just forward the transformed SMTP message to a real SMTP
server for final delivery. Because SMTP is a store-and-forward
service, not end-to-end, this works better than OPES would - there's
less I/O involved.
This could be done. But we will loose the biggest benefits of the
callout strategy at all:
Especially for EMail no message must be lost. The OPES processor
is the thing that the user trusts, that has long experience what to
do with messages that cannot be delivered immediatly, how to manage
queues and so on.
The callout service is "just" for filtering the messages. If it
crashes or fails or has a disk crash, it does not affect all
waiting messages. That's a very important point I think.
Martin