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:markus(_at_)mhof(_dot_)com]
Sent: Friday, May 09, 2003 2:20 AM
To: ietf-openproxy(_at_)imc(_dot_)org
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)
------------------------------------------------------------