On Mon, 5 May 2003, Marshall Rose wrote:
That's basically what I mean. Learning all the good things from
BEEP and reusing as much as possible for OCPTRAN.
unfortunately, you've taken exactly the wrong lesson here.
if you're trying to do beep-like things, you should use beep.
because, frankly, this group isn't going to be able to make better
decision decisions than the group that did beep. quite the reverse.
obviously, if there are parts of beep that you don't like, then:
- if they're optional, then don't use them.
- if they're not optional, then you're not trying to do
beep-like things.
and if the answer is the latter, then go off in another
direction, and that's just fine.
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?
There are many aspects to consider, but the primary ones seem to be:
1) XML (required in BEEP)
2) ICAP migration (more smooth with OCPTRAN than with BEEP)
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)
4) profile reuse (to support transport security, etc.)
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.
Alex.