On Fri, 9 May 2003, Martin Stecher wrote:
for me it seems that we need to quantify the amount of work that
OCPTRAN will need. Without that number we will hardly get to a
consensus.
(I personally do not feel well in voting without a sure under-
standing what we loose and win with OCPTRAN and while I see
good reasons for OCPTRAN, I am not sure about the costs).
I think it will take me approximately 7-14 days to add OCPTRAN to the
current OCP Core draft. That is, if we decide to proceed down that
path on Monday, you will get OCPTRAN implemented (as a part of OCP
Core) in one or two weeks. This will not be the final implementation,
of course. Just something that is worse discussing in public and
polishing further, with this group active participation.
When we look at message design, channel and session management,
we have already some basic guidance by the generic OCP draft.
In addition we can benefit from the experience with already
invented wheels.
Yes, absolutely.
The main argument for BEEP to me seems to be the already done work
for transport security. But how much is it really to add this to
OCPTRAN too? When I look into RFC 3080 I find a couple of sections
on a few pages dealing with it. RFC 2818 dealing with HTTP over TLS
is a seven pages document which comes down to four pages of real
content. That is both not soo much.
What else needs to be done? And how much is it?
This is what concerns/bothers me as well. Indeed, the amount of
existing negotiation/security-related text in BEEP and similar specs
is rather limited. We are not going to rewrite TLS, we are going to
make its use possible/convenient, just like BEEP allows for its reuse.
If that's the end of the statement, than the amount of extra work is
marginal.
On the other hand, one might argue that other working groups will come
up with numerous extensions/profiles to BEEP that we would not be able
to benefit from directly if we do not use BEEP now. Thus, it may be
argued that while short-term benefits of resuing BEEP are marginal,
long-term benefits may be considerable.
This is an area where I lack expertise and am likely to miss something
important. Corrections/comments are requested.
And what is about Markus' very valid question: Who can and will
do this portion of the work?
[While I am willing to help, I am not able to do this alone.]
I can and will (if the group decides to go down OCPTRAN path).
Aren't there tasks that will even work out easier in OCPTRAN than in
BEEP so that we could also save some work on other ends?
Sure, many things would be easier to document and even implement (if
you are not using BEEP libraries) with OCPTRAN because it is a
domain-specific transport and not a general-purpose ten-sizes-fits-all
protocol.
I am thinking about capability negotiation for instance.
Can OCP's capability negotiation process be completly merged
into BEEP's greeting message concept?
Yes, it can. However, doing so may limit negotiation points to
session/channel establishment, which is not ideal. Depending on the
implementation, it may also require more extensive use of XML. As
usual, there are trade-offs. Virtually all BEEP mechanisms are
suitable for OCP. Virtually no BEEP mechanism are perfect for OCP. The
more you rely on BEEP native mechanisms, the less you will get out of
OCP (which is true for any general-purpose protocol/language/whatever;
I am not saying that BEEP is somehow at fault here).
Or is this something we need to define for OCP/BEEP in addition?
We can. It all depends how flexible and XML-dependent we want OCP
negotiations to be.
If building OCPTRAN, capability negotiations will become
an integral part and merging the option/requirement to use TLS
into this process could be nearly for free then.
Yes, it should be designed that way.
I hope my answers will help you to finalize/voice your preferences.
Alex.