At 10:57 12/05/03, jfcm wrote:
At 14:43 11/05/03, Oskar Batuner wrote:
My vote is:
ICAP/1.1: 0%
OCP/OCPTRAN: 80%
OCP/BEEP: 20%
Initially I was much more in favor of BEEP. One of the main
reasons to shift my preferences to OCP/OCPTRAN is what Alex
calls "clone and modify" approach to reusing BEEP mechanisms
in OCPTRAN.
I will add thios to the page today. I have however a concern about that
you guys with better experience about IETF's way may respond.
to what Oskar reponds:
<quote>
"We do not believe in voting. We believe in rough consensus and in
running code." - Harald Alvestrand
</unquote>
what is strange for someone who says "may vote is" to someone
who just responded to Martin
<quote>
However it is not a "vote" it has been updated on http://jefsey.org/ocph.htm
The pattern starts being a good quantified mirror of the discussion. But
still probably too early to finalize with 5 positions over probably 20
active participants?
</unquote>
As Alex says this is to a vote (you can change your mind as you want). This
is intended to be a decision help and it would be great we have a complete
review of the participnts feelings and may be reasons.
This presupposes that BEEP mechanisms are carved in stone. What
if they update sometimes in a way OCPTRAN cannot or does not
want to support. What will be the real life impact (this was as stated
the reason why I kept interest in the BEEP solution too).
to what Alex responds
<quote>
(1) It is up to us whether we want to support upward
compatibility with future modifications of BEEP (if any).
For example, we can specify the exact protocol to be used.
This is what BEEP itself does with respect to XML -- BEEP
specifies that XML/1.0 is to be used (not XML/1.1 or any
other version).
(2) BEEP has no versioning mechanism and, thus, its
mechanisms are carved in stone.
In short, this should not be a problem.
</unquote>
I do not say it is a problem. I say it needs clarification. Either we want
to save time and efforts now and capitalize on the present experience of
BEEP and it is true it is not a problem.
Or we want to save time and money for implementation and maintenance in
sharing modules with BEEP what was my understanding?
This is what is unclear to me and motivates my "distribution" of support
points.
jfc