-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Wednesday, March 12, 2003 11:37 AM
To: ietf-openproxy(_at_)imc(_dot_)org
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.