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.