Hi,
see comments inline
abbie
-----Original Message-----
From: The Purple Streak, Hilarie Orman
[mailto:ho(_at_)alum(_dot_)mit(_dot_)edu]
Sent: Monday, February 17, 2003 5:55 PM
To: batuner(_at_)attbi(_dot_)com
Cc: ietf-openproxy(_at_)imc(_dot_)org
Subject: RE: SMTP filtering use case
On Mon, 17 Feb 2003 at 17:17:18 -0500 Oskar Batuner avowed,
in replying to Alex Rousskov:
> 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.
Discussions that reveal schisms in the meaning of the
architecture are very important, whether or not it was the
intention of the original message. The lack of specifics to
date has been difficult for everyone, and I'm sure that there
are more surprises lurking as we discuss a real protocol for
real uses.
---------- abbie
agree, this is why we said that the fun begins now.
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.
I think it's not as collaborative and loose and all that.
The OPES processor is the enforcement point for privacy.
It's designed to be a very fast and fine-grained,
policy-based, application-layer switch. If it is not the
repository for user preferences, then all the policy
enforcement and authentication requirements get pushed to the
callout servers. This leaves the OPES processor with almost
no function - it might as well be a dumb hardware switch
operating at layers 4 through 7.
Hilarie
---------- abbie
Hilarie, good points (agree with u here).
We can not assume that the callout server will be the PEP (or at least the
main one). Otherwise, we get in trobule if the callout server is in
different administration domain, etc... The way I look at it, the OPES
processor may use different callout servers based on different services, so
this means that the OPES processor must be the PEP, the callout server can
be a secondary PEP if chaining is used.
abbie