Subject: RE: Draft Agenda for IETF 56

From: "Reinaldo Penno" <[email-masked]>
Date: Wed, 12 Mar 2003 09:06:52 -0800

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Wednesday, March 12, 2003 11:37 AM
> To: [email-masked]
> Subject: RE: Draft Agenda for IETF 56
> 
> 
> 
> 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
> > 2. in keeping in mind what could be reused from a car 
> production later 
> > on, so we keep consistent.
> 
> 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?

My understading is that OPES is going to work for HTTP as the *application*
protocol in phase 0. That does not mean the callout protocol is HTTP or will
only work for HTTP.

If the OCP is protocol agnostic, supporting RTP or something else in a later
phase should be a matter of new specific messages/meta-data. I pushed a lot
for OCP to be protocol agnostic so that we do not need to redo it again for
every single application protocol, the intelligence remain on the end points
(OCP is basically an intelligent data mover) and interoperability could be
made easier.

[],

I just saw Markus' email and seems we are going down the protocol agnostic
approach in good shape. Your pre-draft speaks for itself.

> 
> 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 
> > different model?
> 
> 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.
>

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 12 Mar 2003 10:21:57 -0700 (MST)

On Wed, 12 Mar 2003, Reinaldo Penno wrote:

> My understading is that OPES is going to work for HTTP as the
> *application* protocol in phase 0. That does not mean the callout
> protocol is HTTP or will only work for HTTP.

I agree.

> If the OCP is protocol agnostic, supporting RTP or something else in
> a later phase should be a matter of new specific messages/meta-data.

Exactly! But it does not happen automagically, just because we have a
SHOULD in the requirements draft. If we forget about that SHOULD now,
and only think about HTTP, then I am positive that we will violate
that SHOULD soon and, more importantly, would have to redo a lot of
work to satisfy it again. That is why I am suggesting that we are not
prohibited from making the callout protocol general enough to support
more than just HTTP. Now.

> I pushed a lot for OCP to be protocol agnostic so that we do not
> need to redo it again for every single application protocol, the
> intelligence remain on the end points (OCP is basically an
> intelligent data mover) and interoperability could be made easier.

I fully agree that OCP SHOULD be protocol agnostic. Now we need to do
the legwork to make it that way.

Alex.