This is a very good start. Thank you.
I suggest we put that on an exell table (I can do that, but may be you are
more informed) and to keep an HTML page on it on the site. I am not
technically good enough to understand everything in here (I am here to make
sur my needs are covered and to learn how I could cover them should them
not to be met). But I feel there may be other points and I understand this
is seen from the OCP developper point of view, not so much yet from the
developper having to use OCP point of view?
jfc
At 06:25 08/05/03, Alex Rousskov wrote:
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.
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.474 / Virus Database: 272 - Release Date: 18/04/03