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.