Alex,
could you already give some real life examples how OCP over BEEP will look like?
I am not sure how much XML and Content-Type statements will be necessary to be
BEEP compatible.
While I like many of the BEEP concepts and agree that they are very useful for
OCP, I am not sure that I will like the protocol's look and feel.
This may change by seeing a real example, or it will encourage me to create an
alternate proposal ;-)
That's why I am also very interested how OCPTRAN could look like.
Regards
Martin
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Thursday, April 24, 2003 5:41 PM
To: ietf-openproxy(_at_)imc(_dot_)org
Subject: OCP transport nomination
I would like to nominate BEEP as the only OCP transport. My primary
reasons for nominating BEEP are:
- reuse of BEEP negotiation capabilities for
transport encryption and such
- availability of efficient transfer for
opaque ("binary") data
There are several issues that we would need to resolve if BEEP is
selected by the group (e.g., selecting BEEP message exchange model and
defining OCP message encoding), but I would like to hear other
protocol nominations (Hilarie?) or any objections to BEEP before
discussing BEEP-specific details.
I hope I am not making a mistake by giving BEEP a preference over
SOAP. I would really like to use SOAP because that is what web
services world is using, and we are doing something very similar.
Unfortunately, SOAP suffers from a legacy of being started as an RPC
protocol and has no standard way of handling large opaque data
[efficiently]. If BEEP is selected, we would essentially trade
"efficient transfer" for "current deployment". I hope that is the
right choice, especially since SOAP can still be used as another
callout protocol in environments where efficient transfer is not
important. If you think otherwise, please speak up now.
We have talked about all known transport candidates except Hilarie's
OCPTRAN. Let's move this discussion to a closure. OCP work cannot
proceed much further without the transport selection.
Thank you,
Alex.