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