On Mon, 5 May 2003, Martin Stecher wrote:
It got quite on this.
Does this mean that everybody feels just fine with BEEP?
No other nominations?
No OCPTRAN?
No more arguments?
Personally, I am waiting for feedback from others. Hilarie mentioned
OCPTRAN once, but has not provided any details/arguments since. I do
not want to spend time detailing OCPTRAN if nobody backs it. If
Hilarie argues for OCPTRAN and/or this discussion drives you towards
OCPTRAN, then there will be somebody backing it...
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?
If two "average" OCP implementors start from scratch, I do not expect
a huge difference in implementation effort of OCP/BEEP versus
OCP/OCPTRAN. BEEP implementations will benefit from the existing code
and expertise, even if they do not use that code directly. OCPTRAN
implementors will benefit from a simpler, domain-specific protocol and
may benefit from existing ICAP code/expertise if OCPTRAN is similar to
ICAP.
I think a big difference is in supporting things like transport
encryption (e.g., TLS) and similar add-ons that BEEP gives us, the
protocol writers, for "free". It would take us a while to document
those things in OCPTRAN (or we would have to leave them unspecified
for the first version of the protocol). It would take implementors a
while to implement them without having much experience/code out there.
As you know, I would like to see something that could be called
ICAP/2.0.
Political issues aside, I think it is possible to call OCP "ICAP/2.0"
regardless of the transport protocol choice. We are doing the same
conceptual thing ICAP does. Transport is just a low-level detail.
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:
Possible, if we are OK with losing existing BEEP support for session
encryption.
Also, one good thing about BEEP messages is that they all have a
known, easily-available size (encoded as an integer value in the first
line of a message). The above looks similar to HTTP and loses the
known-size advantage. The size can be added as a "Content-Length"
header, of course, but you have to parse a lot more to get to that.
Alternatively, we can add size to the first line and lose similarity
with ICAP/HTTP.
I think what we need to understand is whether you do not want BEEP
just because it uses XML or because it does not look like ICAP/HTTP.
Once we know the true obstacle, we can try to see how BEEP can be
modified to remove that obstacle.
For example, it is probably possible to define OCPTRAN as "XML-less"
BEEP while providing a simple BEEP-to-OCPTRAN conversion and, hence,
reusing (redefining without much effort) most of the existing BEEP
work. This approach would be similar to, say, binary XML that exist
for wireless protocols (binary XML gets virtually all the advantages
of XML but uses different representation for various performance
reasons).
Similarly, we can "convert" BEEP to HTTP-like BEEP.
Comments?
Alex.