Alex Rousskov wrote:
If Reinaldo agrees with Andre's recollection of the conference call,
then there seems to be no conflict regarding support for non-TCP
application transport. This mini-thread started when jfc asked whether
OPES transport must be TCP, and I think my initial response remains
valid.
I can fully second Andre's recollection. During a call of the
"protocol requirements" sub-team, the author team agreed that
(a) the callout protocol MUST NOT negotiate the transport protocol
to be used for callout connections,
(b) the callout protocol MAY, specify that a certain application
message protocol (e.g. HTTP, RTP) requires the use of a certain
transport protocol (e.g. TCP, SCTP).
This is fully documented in Section 3.12 of the protocol requirements
draft.
Key point is that we do *not* have a transport protocol negotiation
mechanism in the OPES protocol. However, we're also *not* restricted
to a single transport protocol to be used for all purposes. Point (b)
above specifies that the transport protocol to be used for the callout
may depend on the application message protocol used between producer
and consumer (e.g. HTTP). Note, however, that this is different from
chosing the transport protocol for the callout based on the
application itself...
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?
-Markus