[ speaking as the beep guy... ]
I wish the situation was that simple/straightforward. I do not think
it is. Your comments assume that "beep-like things" are well-defined.
They are not! We are, in fact, trying to answer that very question:
"Is OCP doing something that BEEP is appropriate transport for?"
Clearly, BEEP RFC itself does not (cannot) answer that question --
defined BEEP scope is too broad and not specific enough. Do you,
personally, think that the answer is clear?
if there were a clear description of what ocp's requirements are, then
it would be trivial to answer these questions.
in general, if you come up with a new connection-oriented protocol that
does things like sasl, tls, framing, and possibly multiplexing, then you
are doing beep-like things.
just so we're clear: later on today, i'm going back to being the process
guy, and markus can see if he can get the working group to decide what
to do.
There are many aspects to consider, but the primary ones seem to be:
1) XML (required in BEEP)
anyone who thinks that implementing xml to support beep is a problem has
a very skewed set of priorities...
2) ICAP migration (more smooth with OCPTRAN than with BEEP)
sure.
3) message exchange (a single channel may be required for each
data and metadata exchange, in addition to control
channel(s); OCPTRAN can have better, more natural
and efficient mapping)
hmmm...
4) profile reuse (to support transport security, etc.)
anything you can do with tls or sasl, you can do with tls or sasl under beep.
Since channel management (closely related to item 3) requires XML, and
since OCP is going to be different from ICAP anyway, I believe the two
biggest issues are XML and profile reuse.
amusingly enough, these are the two i see as non-issues...
/mtr