Hilarie,
I did not meant to say that this discussion has no point. I'm
just trying to look at the protocol features that are needed to
support the application requirements that surfaced in the
discussion about Martin's scenario. Essentially this are
transaction integrity and one-to-many mapping between the
protocol messages and the application messages.
Application architecture discussion in fact raises one more
issue - performance requirements for OPES processor and
callout server. One approach is to go from OPES server
performance required to keep up with the request flow.
If callout server has to be in this flow the callout protocol
should be light weight, SOAP and XML do not look good for that.
On another hand we may look at the task performed by the
callout processor. If each request requires significant
processing protocol parsing becomes comparatively less
important - even for heavy weight protocols. If callout
server is powerful enough to keep up with processing requirements
it should be able to do parsing too (this is the situation
when functional request processing is much more demanding than
parsing of heavyweight protocol). Problem of keeping up with
performance requirements that exceed capabilities of single
server may be approached from two directions - either by building
a server farm or by distributing requests from OPES processors to
multiple callout servers. We may look at protocol features that are
helpful to support each approach.
Oskar
-----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.
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