On Tue, 6 May 2003, Marshall Rose wrote:
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.
This is a catch-22. If there were a final description of OCP
requirements, we would not have to have this conversation.
High-level requirements are not detailed enough. OCP details are not
completely known yet. Many OCP aspects can be supported differently,
depending on the transport protocol we chose. We know that OCP is for
efficient asynchronous exchange of [possibly large] metadata,
[possibly large] data, and small command messages. That is "clear" but
not [precise] enough to say whether BEEP is the best way to proceed.
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.
True. But BEEP is not an ideal transport for all connection-oriented
protocols that do things like sasl, tls, framing, and multiplexing (no
single transport can be!). BEEP designers had to make some choices
that made BEEP imperfect in some beep-like environments. Most of these
choices are well documented; use of XML and message exchange
limitations are some of them. We have to decide whether those
imperfections are major or minor in OCP case.
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...
Anyone who thinks that supporting XML comes for free has a very skewed
set of applications.
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.
Yes, #4 is an argument for BEEP, not against it. OCPTRAN cannot reuse
any profiles "as is" because OCPTRAN is a new protocol. The question
is how much more work we would need to do if we start from scratch.
Alex.