BEEP as OCP transport

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

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