-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Alex
Rousskov
Sent: Wednesday, March 12, 2003 2:18 PM
To: OPES Group
Subject: RE: Draft Agenda for IETF 56
On Wed, 12 Mar 2003, Oskar Batuner wrote:
As per architecture:
"The OPES architecture requires that tracing be feasible
on the OPES flow per OPES processor using in-band annotation. "
This requirements is essential, it provides participants with the
ability to detect OPES in the course of normal interaction. It is
necessary to satisfy IAB. Without in-band tracing one should undertake
special query to find out if there was something done to the data.
This may be not feasible - how do you know where to look without
tracing info?
Good catch! It looks like we have an answer as far as tracing is
concerned unless we want to add per-service tracing.
However, we do not have an answer for communicating user preferences
(e.g., bypass). You cannot make the same argument there because if a
user [agent] wants to communicate OPES preferences, it has to support
something new, possibly a new out-of-band protocol.
For that matter I'd suggest that callout processor should not be
able to communicate with OPES participant directly, only through
OPES server. This will provide the required level of isolation. OPES
processor may use callout protocol to communicate certain requests
to callout processor and send responses back to the user/server.
On the other hand, callout servers already communicate with ends, by
modifying application messages (which is their primary purpose)!
And they send these messages ONLY through the OPES processor. My point
is that as OPES processor is the principal point of contact between
OPES flow ends and the OPES application it should be the only
point exposed to the end user/server. In your previous example
about preferences end user does not know the OPES application
composition (what functions are performed at what point), and
preferences relate to the OPES application as a whole.
Distribution of OPES application functions between components may
even change dynamically as adaptation to the load conditions. Let's say
until your OPES box is underloaded application functions are performed
there, if load is too high - callout processor is invoked, if load is
too high for callout processor a new one is added - either by the OPES
processor or by callout processor. Certain things may break - I've
already notified OPES server and one callout processor that I don't
want adult contents, but now load balancer switched me to the new
callout processor that does not know my preferences!
If you have a single user contact point this may scale pretty well,
otherwise the user has to be involved in the process in which he/she
is not interested at all - function distribution between OPES components.
As soon as the user is aware of OPES existence and knows the contact
point (this information MUST be provided in-band) further communications
may be ether in-band or out-of-band, depending on the particular protocol
and application.
Oskar