RE: OCP transport vote, commitment

hi,

This is my vote at this stage.

At the beginning of this discussion, my vote would have been:
 
        ICAP/1.1:        0%
        OCP/OCPTRAN:    50%
        OCP/BEEP:       50%
 
 
(After a quick recount) My current vote is:
 
        ICAP/1.1:        0%
        OCP/OCPTRAN:    100%
        OCP/BEEP:       0%

Putting it in Alex justification, I really do not like the white Box
approach and it seems to me that the black box is not that black afterall.

ps: I will be happy to work on OCPTRAN.

Abbie
 

> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com] 
> Sent: Friday, May 09, 2003 2:00 PM
> To: ietf-openproxy(_at_)imc(_dot_)org
> Subject: OCP transport vote, commitment
>
>
>
>
> At the beginning of this discussion, my vote would have been:
>
>       ICAP/1.1:        0%
>       OCP/OCPTRAN:    15%
>       OCP/BEEP:       85%
>
>
> My current vote is:
>
>       ICAP/1.1:        5%
>       OCP/OCPTRAN:    55%
>       OCP/BEEP:       40%
>
> I would be willing to lead OCP/OCPTRAN development and 
> probably can have the first draft ready in 2 weeks or so. I 
> would be willing to lead OCP/BEEP development as well, 
> provided BEEP experts such as Marshall contribute a lot; I 
> would expect first OCP/BEEP draft to be available in a month 
> or so. Finally, I would be happy to help with ICAP/1.1 work, 
> but I think ICAP experts such as Martin should lead that activity.
>
>
> Here is some justification of my current views.
>
> * BEEP versus OCPTRAN: There are two issues for me here. Wheels reuse
>   and XML scare. Initially, I thought that we should just go ahead
>   and reuse BEEP. Reuse is great. However, as the discussion got
>   more specific, I realized that there are two kinds of reuse.
>   Let me call them black box reuse and white box reuse.
>
>   Black box reuse is simple: you take existing something (protocol,
>   library, whatever) and build on top of it using published
>   interfaces. There is a clear boundary between the "reused" entity
>   and its new "owner". In many cases, you can use or invent another
>   something that can be reused instead, without modifying the
>   owner much. Examples of black box reuse are: writing a C program
>   (reusing C language and libc library), wget (reusing HTTP), reliable
>   syslog (reusing BEEP)
>
>   White box reuse is integration/merging with existing something
>   (protocol, library, whatever) based on the knowledge of internal
>   structure of that something. The boundary becomes less clear.
>   In many cases, it is impossible to change the "reused" entity
>   without also causing significant changes in its "owner". Examples
>   of white box reuse: writing a Perl program using internal Perl
>   datastructures for optimization purposes (reusing existing
>   Perl datastructures), HTTP/1.1 (reusing HTTP/1.0), any protocol
>   that defines its own BEEP message types (reusing BEEP)
>
>   Black box reuse is great. White box reuse often, but not always,
>   leads to long-term inefficiencies and wasted energy. "Clone and
>   modify" is often better than white white box reuse, IMO. For
>   example, I believe HTTP/1.1 folks made a strategic mistake by making
>   HTTP/1.1 "semi-backword compatible" with HTTP/1.0 (and even having
>   two conflicting RFCs for HTTP/1.1 itself!). It looks like ICAP
>   suffered the same problem when migration from ICAP/0.9 to ICAP/1.0
>   led to major ICAP vendors going different ways while offering
>   relatively few advantages to justify the loss.
>
>   In our case, OCP transport is border-line. We can, of course,
>   use BEEP as a black box. The resulting protocol will be somewhat
>   awkward to document and understand, but it will work (black box
>   approach). We can also add our own message types to BEEP, yielding
>   a more elegant design, but losing compatibility with existing
>   BEEP libraries while still having to leave with certain BEEP
>   features that cannot be simply "extended" (white box approach).
>
>   BEEP folks say they saved the world by building something many
>   working groups will reuse instead of writing specs from scratch. I
>   agree. Unfortunately, BEEP is not universal enough (nothing
>   is) -- it makes choices regarding message exchange patterns and
>   channel negotiations that are not perfect for OCP. It requires XML.
>
>   If we proceed with OCPTRAN path, we can (but do not have to) try to
>   make a similar (but smaller scale) contribution -- future working
>   groups might be able to reuse our protocol when what they do is more
>   similar to OCP than to BEEP (efficient asynchronous bidirectional
>   exchange of large number of opaque application messages that may be
>   very small or very large). But that's probably too much to hope for.
>
>
> * XML scare:
>
>   Many people worry about XML in an "efficient communication" context.
>   Perhaps my circle of life is too biased or too small, but that is my
>   observation. To maximize OCP adoption chances (by ICAP community),
>   we SHOULD NOT use XML (all other factors being the same, which they
>   are not). We MUST NOT use XML for each application message exchange;
>   using XML for connection-related negotiations MAY be OK, if we
>   really need that kind of flexibility.
>
>   Why do I care about ICAP community? Because if those folks do not
>   migrate to OCP, OCP will probably die, and all our efforts will
>   be wasted.
>
>
> * ICAP/1.1
>
>   Since we are so unsure about OCP transport, and since some belive
>   that work minimization must be our top priority, polishing an
>   existing and working protocol may be worse talking about. If we
>   adopt ICAP/1.0 almost "as is" we can concentrate on other OPES
>   aspects and, perhaps, make them slightly better.
>
>   Migration for ICAP community will be simplified as well, especially
>   if we make ICAP/1.1 100% backword compatible to ICAP/1.0.
>
>
> Alex.