RE: Draft Agenda for IETF 56

Dear Folks,
when I suggest we build a bicycle first, in keeping in mind that we want to 
build a car further on and to reuse parts, I probably mean the same thing 
as Alex except that I wish to start on something real and responding to the 
IAB request for a bicycle. I just did that by my own and I was immediately 
confronted with the need to understand what I was doing, not yet in term of 
protocol, but in term of architecture.
1. to have a clear model and that model to be open
2. to have a clear wording of each component from that model
3. to understand what the protocol(s) relate(s) and how the servers will work

Otherwise we will have a perfect protocol we will try to patch to a model 
and applications.
Don't you think that there are already too many protocols around? To me the 
main interest of the callout protocol is that it is probably to address a 
large number of different needs, so it should be a good candidate to 
replace and simplify some other protocols (plural) rather than to add/copy 
one and to add in complexity by superseding many others.
jfc











At 19:50 12/03/03, Oskar Batuner wrote:


> As per architecture:
>
> "The OPES architecture requires that tracing be feasible
>    on the OPES flow per OPES processor using in-band annotation. "
>
> This requirements is essential, it provides participants with the
> ability to detect OPES in the course of normal interaction. It is
> necessary to satisfy IAB. Without in-band tracing one should undertake
> special query to find out if there was something done to the data.
> This may be not feasible - how do you know where to look without
> tracing info?
>
> Out-of-band component may be used to get more detailed info, but as
> in-band tracing is a must it has to be protocol-specific. For the
> tracing purposes callout server role is not that important, the
> essential thing is if there are changes made. OPES architecture
> provides for OPES service implementation on the OPES computer,
> and placement the application functionality on one computer or
> another are details that should be isolated from the other
> OPES-flow participants. If my application (end-user or content
> provider application) somehow interacts with OPES it should not
> depend on such details.
>
> For that matter I'd suggest that callout processor should
> not be able to communicate with OPES participant directly,
> only through OPES server. This
> will provide the required level of isolation. OPES processor
> may use callout protocol to communicate certain requests to callout
> processor and send responses back to the user/server. If user
> requests are coming in-band OPES communication with callout
> processor provides better reliability and simplifies synchronization,
> but this may depend on actual tracing specification.
>
> Oskar
>
>
> > -----Original Message-----
> > From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
> > [mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Alex 
> Rousskov
> > 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.
> >
> >
>
>
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.459 / Virus Database: 258 - Release Date: 25/02/03