Hi,
sorry, sick today, just came back from doctor.
good thread, however, the good thing here is the start of the work by alex
on determining the traceability/notification requirements.
My opinion at this stage, is that let us get it right starting with HTTP and
then determine how it relates to the other protocols.
thanks
abbie
-----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?
Alex.