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?
Out-of-band component may be used to get more detailed info, but as
in-band tracing is a must it has to be protocol-specific. For the
tracing purposes callout server role is not that important, the
essential thing is if there are changes made. OPES architecture
provides for OPES service implementation on the OPES computer,
and placement the application functionality on one computer or
another are details that should be isolated from the other
OPES-flow participants. If my application (end-user or content
provider application) somehow interacts with OPES it should not
depend on such details.
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. If user
requests are coming in-band OPES communication with callout
processor provides better reliability and simplifies synchronization,
but this may depend on actual tracing specification.
Oskar
-----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 12:33 PM
To: OPES Group
Subject: Re: Draft Agenda for IETF 56
On Wed, 12 Mar 2003, Markus Hofmann wrote:
Just a reminder - although we've a SHOULD requirement that states
that our solutions should be protocol agnostic (and I think we all
agree on that), our charter is focused on HTTP (and RTP, although we
agreed the main focus being on HTTP).
What it means to me is that:
- we MUST support HTTP as an application protocol
- we SHOULD support more than just HTTP
- in case of a specific design conflict, HTTP-arguments MAY
have higher priority than arguments for other application
protocols
The above is different from
- we MUST support HTTP as an application protocol
- we MUST NOT consider other application protocols
until HTTP is supported
- we SHOULD check other application protocols
after HTTP is supported
I'd suggest we go down a similar path as we currently do with the
callout protocol, namely discussing required functionality and
general design issues, first (rather than starting to discuss how
and in which specific form to do it). I.e. what exactly do we need
to signal (one example is the "OPES bypass"), what are the
interaction schemes, what needs to be signaled, etc. Then we can
discuss what's the best way to do this (e.g. "in-band" vs.
"out-of-band") etc.
I, obviously, agree.
[Note: Just to avoid confustion - this is *not* about the callout
protocol, this is about the application protocl path).
There is some interaction between the two though. For example, we need
to decide whether the callout server or OPES dispatcher/processor is
responsible for tracing (could be both too!). If callout server is
responsible, then the callout protocol may have to provide appropriate
support, especially if we decide to use out-of-bound (#2) approach.
Hmm... The latter actually demonstrates another weakness of the
out-of-bound approach: it makes it difficult for callout servers to
participate in tracing and similar activities because the "end" is not
talking to them but to the proxy. On the other hand, maybe this is a
sign that callout servers must not participate?
Alex.