Subject: RE: AW: Using XML in OCP transport

From: "Martin Stecher" <[email-masked]>
Date: Fri, 9 May 2003 15:11:49 +0200

Hi,

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).

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.

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?

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.]

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?

I am thinking about capability negotiation for instance.
Can OCP's capability negotiation process be completly merged
into BEEP's greeting message concept?
Or is this something we need to define for OCP/BEEP in addition?
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.

Regards
Martin

> -----Original Message-----
> From: Markus Hofmann [mailto:[email-masked]]
> Sent: Friday, May 09, 2003 2:20 AM
> To: [email-masked]
> Subject: Re: AW: Using XML in OCP transport
> 
> 
> 
> Folks,
> 
> just a note that there's nothing like an official voting process or 
> so. Please continue to express your opinion and preference using 
> technical arguments on this mailing list, and it will be noted 
> accordingly to find consensus.
> 
> I'd also like everyone to indicate to what extend you'd be able to 
> actively contribute to realize your preferred option. An option only 
> becomes viable if there are enough committed resources to help 
> realizing it!!
> 
> Thanks,
>    Markus
> 
> 
> jfcm wrote:
> > 
> > At 23:48 08/05/03, Alex Rousskov wrote:
> > 
> >> Just for the record, in the parallel terminology used in prior
> >> e-mails and on jfc web site, this vote is equivalent to:
> >>
> >>         ICAP/1.1:  5%
> >>         ICAP/2.0: 75%
> >>         OCP/BEEP: 20%
> >>
> >> >From now on, let's avoid confusing references to ICAP for the
> >> OCP/OCPTRAN solution. So let's use these:
> >>
> >>         ICAP/1.1    (polished ICAP, very similar to 
> existing ICAP/1.0)
> >>         OCP/OCPTRAN (OCP over OCPTRAN)
> >>         OCP/BEEP    (OCP over BEEP)
> > 
> > 
> > Reworded site for you. I am to go home. Now. May I expect your list?
> > Also we could record the people's position in % as decision factor.
> > See site. http://jefsey.com/ocph.htm
> > 
> > 
> > 
> > 
> > 
> >> Both OCP/OCPTRAN and OCP/BEEP may eventually be called ICAP/2.0 for
> >> political/marketing reasons, but let's ignore the naming issue for
> >> now.
> > 
> > 
> > 
> 
> 
> ------------------------------------------------------------
> This mail has been scanned by wwsmtp.webwasher.com
> (WebWasher 4.4 beta Build 499)
> ------------------------------------------------------------
>

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 9 May 2003 10:04:22 -0600 (MDT)

> 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.

> In addition we can benefit from the experience with already

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.
>

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.

> [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.

> 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.

> 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.