On Tue, 22 Apr 2003, Abbie Barbir wrote:
u have to deal with this option anyway. Once u define generic OCP
you will end having OCP over XXX over yyy over zzz etc...
We could decide on one transport protocol for OCP Core and have no
other transport alternatives (this still allows for SOAP to be used as
another callout protocol, of course; by "OCP" I mean the protocol we
are working on right now, I wish it had a specific name to distinguish
it from other callout protocols).
Alex.
-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Tuesday, April 22, 2003 11:52 AM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: SOAP and OCP
Abbie Barbir wrote:
1. SOAP is not a transport protocol. Would you
require a specific transport protocol to
be used if OCP is implemented using SOAP?
For example, would you require that BEEP/TCP and
only BEEP/TCP is used under SOAP?
Yes, but there are bindings defined for SOAP (like HTTP,
BEEP ?). No
we will not require specific bindings. We have agreed that this OCP
draft basically define metadata/state machine for OCP and that
bindings will be defined later. IF we use SOAP, then SOAP
can have its
own bindings. This way we define SOAP/OCP and then SOAP
over ... can
be defined by anyone else.
I'm not convinced that this would be an attractive option, since it
opens up again the issue of interoperability. I bet we'll see vendors
implementing "OCP over SOAP over A" and other vendors implementing
"OCP over SOAP over B", thus not being able to interoperate.
We already see this happening in the SIP area, where some
vendors only
implement SIP over TCP, and others only SIP over SCTP - whether this
is "allowed" by the standards or not...
-Markus