-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
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?
Independent of in vs out of band, IMO the end points always talk to the OPES
processor. The OPES processor will use whatever means necessary to perform
the requested services, including use of a callout server. You might even
use a callout server for a certain service only if your CPU is above a
certain watermark, so there is no pre-established behaviour of what the OPES
processor will do to honor the request.
Whatever tracing messages the callout might include on the message, the OPES
processor can easily relay them to the end points with its own tracing.
[],
Alex.