RE: Draft Agenda for IETF 56

This was my initial point. We are asked to build a bicycle. We see that we 
can also build a car. Let avoid building an Harley Davidson everyone will 
enjoy but no one will use.
1. let build the bicycle
2. in keeping in mind what could be reused from a car production later on, 
so we keep consistent.
This is why I think we should do as you say: http. The real project I would 
propose would be a redirect system upon decision of a server (I have a real 
need :-). I suppose that if a few ones could have in mind a similar 
application, we could confront with real life examples.
Then we could list every time there is a decision how it would work with 
other entry systems and other callout protocol transport solution. Choosing 
the simplest transport solution to implement (may be local interaction?) 
for that part, so we can test quickly and exchange code?
Then may be we could check SMTP to be sure it works well in a different model?
jfc





On 12:39 12/03/03, Abbie Barbir said:

> Hi all,
>
> This discussions are really getting interesting.
>
> However, it seems to be that we should fundemantely agree on the 
> deployment (where, what and for what) of OPES in the services area.
> The discussions give me the feeling that we are trying to design a (very 
> flexible) system that is looking for a place in the field.
> I could see the benefits to have various bindings for the callout 
> protocol. It gives felexibility. But at what expense? I really have 
> problems developing an architecture/protocols that can go all over the field.
> The architecture document states that the example protocol is HTTP. I know 
> that we should be open minded in the design of the callout protocol.
> However, I would like to start with HTTP and then come up with a callout 
> protocol that can work with it. After that, I would like to see how we 
> address all of the IAB issues regarding OPES. We can then move the 
> excerise to RTP (SRTP etc..), and use that knowledge to ensure that we 
> have a flexible protocol.
> At this point, the issues of notification/tracing have not been brought up 
> (yet?).
> Abbie
>
> > -----Original Message-----
> > From: Alex Rousskov 
> [<mailto:rousskov(_at_)measurement-factory(_dot_)com>mailto:rousskov(_at_)measurement-factory(_dot_)com] 
>
> > Sent: Wednesday, March 12, 2003 12:24 AM
> > To: OPES Group
> > Subject: Re: Draft Agenda for IETF 56
> >
> >
> >
> >
> > On Tue, 11 Mar 2003, Markus Hofmann wrote:
> >
> > > General question now is whethr we feel that coupling the transport
> > > protocol for the callout to the application message protocol is
> > > flexible enough, or whether we need more flexibility?
> > >
> > > For example, is it OK to assume that whenever the
> > application message
> > > protocol is A, that the transport protocol for the callout
> > is B. Or is
> > > there a case to make that for the same message protocol A, we
> > > sometimes need to use transport protocol B for the callout, and
> > > sometimes transport protocol C (substitute A, B, and C with your
> > > favorite protocols :) If so, how is this achieved without protocol
> > > negotiation?
> >
> > I was not on that conference call so I may be missing some
> > important caveats. Said that, it seems to me that we should
> > not care about the ways transport protocols are selected as
> > long as we do not have to support true negotiations. In most
> > cases, protocol selection can be handled by static
> > configurations (with rules if needed), and should be out of
> > our current scope.
> >
> > No need to limit the selection/matching rules; just prohibit
> > in-protocol negotiations. Let implementations decide what is
> > the right protocol selection method is.
> >
> > $0.02,
> >
> > 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