Subject: RE: AW: Using XML in OCP transport

From: "Abbie Barbir" <[email-masked]>
Date: Thu, 8 May 2003 15:23:53 -0400

Alex,

good points, I agree with you.

So far it seems that the debate will go on.
I wonder how we can come to a closure?

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Thursday, May 08, 2003 2:41 PM
> To: OPES Group
> Subject: Re: AW: Using XML in OCP transport
> 
> 
> 
> 
> On Thu, 8 May 2003, jfcm wrote:
> 
> > At 18:23 08/05/03, Alex Rousskov wrote:
> > >I am sure there are other points. These biased lists are 
> based on two 
> > >points of views: OCP author and OCP/ICAP implementor.
> >
> > I would like we clarify which is which (author, implemtator 
> to try to 
> > best decide and document);
> 
> Both authors and implementors/coders care about the scope 
> (item #1) and XML worries.
> 
> "less/more OCP work for us" is mostly for authors; however, 
> Marshall and others may argue that this group is doomed to 
> produce inferior specs and, thus, the less work we do 
> ourselves (the more we reuse), the better for everybody 
> involved, including coders.
> 
> Implementation complexity is mostly for implementors/coders 
> but it also reflects authors ability to write simple protocols.
> 
> Migration motivation and complexity is mostly for those who 
> advocate/market the new protocol or sell/install products 
> based on the new protocol.
> 
> IETF pummeling is mostly for us, the authors. However, the 
> same factor can be viewed as "reuse of existing technology".  
> The latter is important to implementors.
> 
> > I do not really see a product description for an implementator.
> 
> By "implementor", I meant those who will code or program OCP 
> specification. What those people need is a protocol 
> specification. We already have most of it for ICAP/1.1 case. 
> We probably have enough for the other two cases; see the 
> current OCP Core draft and the BEEP specification, and I also 
> posted some examples.
> 
> By "author" I meant us, the working group.
> 
> 
> > I made a draft in HTML. I can keep doing it if I receive additions 
> > from others. http://jefsey.com/ocp.htm
> 
> You can make it a table to ease comparison (something I could 
> not do in ASCII in the original e-mail): "OCP flavors" as 
> horizontal heading, "decision factors" as vertical heading, 
> and things like none/low/average/high as table cells.
> 
> Alex.
>

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 8 May 2003 13:42:59 -0600 (MDT)

On Thu, 8 May 2003, Abbie Barbir wrote:

> So far it seems that the debate will go on. I wonder how we can come
> to a closure?

I would love to see a closure soon; this issue is stalling OCP
progress. Should everybody vote with, say, 100 "shares" that one can
allocate in any proportion among the three known candidates (ICAP/1.1,
OCP/OCPTRAN aka ICAP/2.0, OCP/BEEP)? We can total the results by
Monday and see if there is a clear winner. We can then try to
reach/confirm the consensus based on the result.

This looks like a unique opportunity for the working group chairs to
step up and lead us to a closure :-).

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 8 May 2003 15:03:05 -0600

I am developing a strong preference for OCP/OCPTRAN; I think it will
smaller and cleaner than BEEP for our purposes, and more likely to be
able to encompass other protocols.  My preferential expression would be
75% OCP/OCPTRAN, 20% OCP/BEEP, 5% ICAP2.0.

Hilarie

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 08 May 2003 17:38:06 -0400

> step up and lead us to a closure :-).

So far, we've basically heard only from two folks about their opinion 
and preferences - I would say that's not enough to declare any form of 
consensus.

I can only recommend anyone interested in this to speak up NOW and 
express your opinion (but, please, also provide arguments for your 
positionm, and indicate to what extend you'd be willing to help 
realizing your prefeence!)

-Markus

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 8 May 2003 15:48:23 -0600 (MDT)

> 75% OCP/OCPTRAN, 20% OCP/BEEP, 5% ICAP2.0.

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)

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.

Thank you,

Alex.

---

From: jfcm <[email-masked]>
Date: Fri, 09 May 2003 01:50:30 +0200

>         OCP/OCPTRAN (OCP over OCPTRAN)

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

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 08 May 2003 20:19:49 -0400

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

---

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

> accordingly to find consensus.

Yes. I think I was careful to explicitly state that the voting is just
to help us to find consensus (e.g., stop spending time on discussing
candidates that receive no votes). The voting "winner" does not
automatically become the group decision. Voting is not a
consensus-based process and, thus, we cannot use its results without
also building consensus around them.

Also, since one gets 100 "shares" to vote with, it is easier to cast a
vote (no all-or-nothing situation) and the result gives us much more
than a single "winner".

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 9 May 2003 11:59:53 -0600 (MDT)

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.

---

From: "Oskar Batuner" <[email-masked]>
Date: Sun, 11 May 2003 08:43:10 -0400

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. 

Here I'm in favor of reusing not just ideas, but the whole 
sections of the BEEP protocol mechanisms. 

As far as I understand Hilarie has objections against reusing 
BEEP security mechanisms. If this is the case we should make a 
decision on that too.

Oskar

---

From: jfcm <[email-masked]>
Date: Mon, 12 May 2003 10:57:46 +0200

>calls "clone and modify" approach to reusing BEEP mechanisms

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.

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

jfc

>---
>Incoming mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.478 / Virus Database: 275 - Release Date: 06/05/03

---

From: "Oskar Batuner" <[email-masked]>
Date: Mon, 12 May 2003 09:33:59 -0400

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of jfcm
> Sent: Monday, May 12, 2003 4:58 AM
> To: Oskar Batuner; [email-masked]
> Subject: RE: OCP transport vote, commitment
> 
> 
> 

"We do not believe in voting. We believe in rough consensus and in 
running code."  - Harald Alvestrand

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 12 May 2003 09:17:00 -0600 (MDT)

> running code."  - Harald Alvestrand

Again, this particular voting does not make any decisions and, hence,
does not violate any IETF rules/principles/etc. It is meant to help us
to find rough consensus, and I think it is working as intended so far.
Better process alternatives are welcome, of course.

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Mon, 12 May 2003 09:30:05 -0600 (MDT)

On Mon, 12 May 2003, jfcm wrote:

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

Two answers:

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

Alex.

---

From: Marshall Rose <[email-masked]>
Date: Mon, 12 May 2003 10:38:30 -0700

[ speaking as co-chair... ]

> running code."  - Harald Alvestrand

the actual quote is:

	we do not believe in kings, presidents, or voting.
	we believe only in rough consensus and running code.

	-- Dave Clark, original Internet Architect, 1981

/mtr

---

From: jfcm <[email-masked]>
Date: Tue, 13 May 2003 08:04:40 +0200

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

>the reason why I kept interest in the BEEP solution too).

to what Alex responds

<quote>

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

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 May 2003 09:05:16 -0600 (MDT)

On Tue, 13 May 2003, jfcm wrote:

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

I am not sure I see the difference between the above two "eithers". If
you are talking about "ideas reuse" versus "code reuse", then I do not
expect much sharing of existing code libraries regardless of the path
we take (OCPTRAN or BEEP), especially for already written
performance-sensitive implementations. Reusing a protocol library "as
is" is often impossible under these circumstances. The best we can
hope for is reuse of code fragments when it comes to parsing or
similar semi-isolated components of existing BEEP and MIME code. Ideas
reuse is always going on, of course.

Alex.

---

From: jfcm <[email-masked]>
Date: Tue, 13 May 2003 17:44:01 +0200

At 17:05 13/05/03, Alex Rousskov wrote:
>Reusing a protocol library "as

I misunderstood then. The removes my worries. I agree was that.
I will then change ma position to HTTP 25 and OCPTRANS 75.

I still believe there might be a need for some light HTTP oriented need
until I fully understand where OCPTRANS may lead into.

Thank you for what you do.
jfc

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 May 2003 09:56:51 -0600 (MDT)

On Tue, 13 May 2003, jfcm wrote:

> I misunderstood then. The removes my worries. I agree was that. I
> will then change ma position to HTTP 25 and OCPTRANS 75.
>
> I still believe there might be a need for some light HTTP oriented
> need until I fully understand where OCPTRANS may lead into.

I assume by "HTTP" you mean "ICAP" or "MIME". My intention is to make
OCPTRAN similar to ICAP/MIME approach when it comes to headers and
such. The rationale is to ease transition for the current ICAP
community and have something most people can recognize. It has to be
quite simple/efficient as well, of course. It remains to be seen
whether these intentions materialize, of course.

Alex.