Alex,
Can you please elaborate on some of the points in your comparison chart:
Polished ICAP/1.1
What specific problems should be solved? What problems remain?
How will it work with non-HTTP application protocols, especially
streaming? If I recall correctly streaming was declared as a
"desired" goal.
Also I'm afraid I cannot agree with the following consideration:
- little incentive to upgrade existing ICAP installations and
implementations
IMHO the incentive is driven by the problems solved in the new version,
not by the passion for innovation. If an upgrade solves important
problem - incentive becomes high, if this upgrade is small - incentive
becomes even higher. The same applies to BEEP - in my view the following
two positions contradict one another:
- more incentive to upgrade existing ICAP installations and
implementations
- more difficult migration path
Another question - OCP on top of BEEP vs. OCP/OCPTRAN:
Do you agree with the following statement:
The most attractive/useful BEEP features for OCP are security
negotiation mechanism and channel control/multiplexing connection,
the most problematic are XML syntax and message exchange styles.
If yes - we can combine the best of two worlds by copying
security and channel control mechanisms and just describing them
in HTTP style syntax. A kind of "white box reuse". Should also
satisfy some of "IETF powers" concerns as we do not invent any
new and maybe inferior transport mechanisms - just grammar.
Oskar
-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Alex
Rousskov
Sent: Thursday, May 08, 2003 12:25 AM
To: OPES Group
Subject: Re: AW: Using XML in OCP transport
On Thu, 8 May 2003, jfcm wrote:
- "polish" ICAP (e.g., document encryption) [ call it
ICAP/1.1? ]
- write OCP on top of TCP [ call it ICAP/2.0? ]
- write OCP on top of BEEP [ call it OCP/BEEP ]
I fully agree that these are the options. (except that I would also
consider on top of IP). I suggest that now this is clear, I suppose,
to everyone, we go a step further and try to quantify the resulting
qualities (there are not con and pros, just how it will be) of each
solutions for a decision grid.
Polished ICAP/1.1:
- OCP stays application specific (though we may be able
to hack SMTP support, in since real implementations already
do that now)
- less OCP work for us
- little incentive to upgrade existing ICAP installations and
implementations
- very easy migration
- implementation complexity comparable to ICAP/1.0
- no XML worries
New ICAP/2.0 on top of TCP:
- OCP becomes the best protocol we can come up with, fixing
known ICAP problems or limitations
- more OCP work for us
- more incentive to upgrade existing ICAP installations and
implementations
- preserves original ICAP look and feel to ease the migration
- implementation complexity somewhat higher than of ICAP/1.0
- no XML worries
- some pummeling from IETF powers for not reusing BEEP?
OCP on top of BEEP:
- OCP fixes known ICAP problems or limitations
- some tension between BEEP and OCP transport needs will
be visible in protocol design and may limit BEEP library
reuse (but we do not expect much code reuse anyway)
- less work for us when it comes to transport security
negotiations and such (BEEP community already did that)
- more incentive to upgrade existing ICAP installations and
implementations
- more difficult migration path
- high implementation complexity
- XML worries
- kudus from Marshall and IETF powers for reusing BEEP?
I am sure I missed some points, but I hope the above is sufficient for
us to start making the final decision.
Alex.