ietf-openproxy
[Top] [All Lists]

Re: Draft Agenda for IETF 56

2003-03-12 11:12:09

Alex Rousskov wrote:

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

Concur! We start designing an application-agnostic approach, and only if there's a conflict or if it would become far too complex, we would limit the approach to a specific application protocol(s) and would put highest priority on HTTP. But for now, I'd say we're good for moving forward with a protocol-agnostic design approach.

[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.

If you talk about tracing, I completely agree thatthere's interaction (and I tend to say both OPES precesor and callout server need to be involved).

But for a general OPES bypass, I don't see that interaction between the application protocol and the OPES callout protocol would be required. If the user signals "no OPES, please", the callout protocol is not involved at all.

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?

Hm... I tend to believe the callout servers must participate in tracing, since the user doesn't really know on which specific server a requested service will be executed (i.e. we assume late service binding for now). If the user now suspects that something goes wrong, (s)he better want to know what specific servers have been involved. Hm, however, this information is probably readily available on the OPES processor and the OPES processor might insert the approriate tracing info... Would that be enough?

-Markus



<Prev in Thread] Current Thread [Next in Thread>