It got quite on this.
Does this mean that everybody feels just fine with BEEP?
No other nominations?
No OCPTRAN?
No more arguments?
Although BEEP seems to be a very good candidate to build OCP on,
I am still not convinced that it is the best choice.
I have little to no technical argumentation for this; it is more
personal gusto and ICAP support.
If we compare the work that needs to be done to adjust BEEP for OCP
plus the XML burdon that every implementor has to take with the
work that we'd need to do to define another transport protocol, is
there a huge difference?
As you know, I would like to see something that could be called
ICAP/2.0.
So maybe something that takes all the good elements of BEEP but
looks different, for example establishing a channel could look
like this:
C:OPEN icap://my-OPES-service.org/translate ICAP/2.0
C:Channel: 1
C:
S:ICAP/2.0 200 Channel Established
S:Channel: 1
S:
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.