Subject: RE: Draft Agenda for IETF 56

From: jfcm <[email-masked]>
Date: Wed, 12 Mar 2003 15:01:11 +0100

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:[email-masked]>mailto:[email-masked]] 
>
> > 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

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 09:36:49 -0700 (MST)

On Wed, 12 Mar 2003, jfcm wrote:

> 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

Bicycle is pretty much useless if you want to end up with a car. If
you want a car, you would have to get rid of the bicycle and start
from scratch. OPES architecture draft explicitly says that OPES is
application agnostic. Do you have any specific objections to keeping
it this way?

0. we are asked to build at least a Geo Metro
1. let's build a Honda Civic because it is not that much harder
2. later, when/if we have time/need/desire, we can build a Porsche
   and a Ford truck.

But these analogies are pretty useless because nobody can define a
bicycle or a car well enough. We need more specific
objections/arguments to change the architecture draft and protocol
development process.

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

Redirection discussion is already on the meeting agenda, so we are
moving forward. I do not see any reason to keep redirection
HTTP-specific at this time. Do you?

> Then may be we could check SMTP to be sure it works well in a

And if it does not? Start from scratch? Also, when is "then"? I think
"then" should be now.

Again, if you prefer to think of just one specific protocol and use
case, that's fine, but why prohibit others from supporting more when
possible?

Alex.