BEEP is a good candidate for OCP transport. Here are a few major
arguments for/against using BEEP as OCP transport. I hope that
Marshall Rose can review this and offer his insight both as BEEP
author and as a co-author of a syslog protocol build on top of BEEP.
1. BEEP exists but is new
BEEP Core specification is a stable "Standards Track" RFC.
However, only few protocols over BEEP have been documented
and, as far as I can tell, none are super popular yet.
This means that we do not need to reinvent the wheel, but
we may also find yet-unknown problems with the existing
wheel design.
2. BEEP uses XML
If we choose BEEP, any compliant implementation
would have to parse XML elements. BEEP documentation
asserts that many great XML libraries exist, some
optimized for performance. While I agree, I also assert
that most (if not all) of the existing libraries are
usually not suitable "as is" for a given decent-size
project that is concerned with efficiency,
portability and/or licensing restrictions. I do not see
much MIME code reuse in HTTP implementations and I expect
the same to be true about similar XML-based protocols.
Using BEEP for OCP essentially implies that every OPES
processor or callout server will have to include an
XML library. Unless we think that this is already the
case for 90% of implementations that will support
OCP, we should think twice about this new burden.
On the other hand, we could try to make OCP/BEEP less
extensible but also less XML-dependent by mandating or
recommending semi-fixed structure of required XML elements.
Parsing or generating such elements would be simple
and possible without any XML library. This kind of violates
protocol boundaries (though BEEP appears to do similar
things when it limits XML to exclude entity references).
3. BEEP is connection oriented
Some suggested that there should be OCP transport
that can run on top of UDP or even raw IP. Selecting
BEEP would then imply that we need two transport
protocols because BEEP cannot run on top of UDP.
However, lossy protocols such as UDP or raw IP are
prohibited by OCP requirements draft. Moreover,
no arguments have been made (yet) to justify
the need for a lossy transport.
Moreover (Marshall, please do not read this sentence),
it is probably technically possible to implement
BEEP on top of UDP to preserve the same high-level
semantics. One would essentially have to define what
to do when a UDP or IP packet is lost and implement
congestion avoidance. I hope we do not have to do
this ugly hack though.
4. BEEP exchange styles are close fit, but not perfect
BEEP requires replies to every BEEP MSG. OCP does not.
We can add "null" replies, of course, but the
protocol does not need them (it would be a waste from
technical point of view).
Some might argue that mandatory replies will actually
make OCP easier to understand.
I wonder why BEEP assumes that replies must be required
(being so flexible in other aspects), but it is
probably too late to change that assumption. Can BEEP
exchange styles be extended? Probably not without
losing compatibility with existing BEEP libraries.
5. BEEP Core does not determine transport
We would still have to decide whether OCP runs
on top of BEEP/TCP only or allow other BEEP
transport bindings.
6. BEEP Core does not determine encoding
We would still have to decide how to encode OCP
messages. BEEP defaults to application/beep+xml,
but other MIME types can be used.
7. BEEP channels allow simple low-overhead OCP connections