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@xxxxxxxxxxxxxxxxxxxxxxx]
> 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.
>
>