Alex Rousskov wrote:
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)
Although our charter does not necessarily require us to be application
agnostic, general consensus of the WG has been that our solution
SHOULD try to be so. As such, I would assume that the WG doesn't want
to follow this approach.
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
We would have to worry about and to work on many things that are
already solved by BEEP, thus possibly distracting from making progress
on the "main delta" to existing solutions.
Would anyone commit the time and resources required to drive this
forward in a timely manner without impacting our progress on the core
OPES issues?
- some pummeling from IETF powers for not reusing BEEP?
I wouldn't worry about this if we have good arguments and a strong
case for not using 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
It's not just "less work", it would also simplify life in avoiding
pitfalls and in "solving" challenging problems others already took
care of in the past.
- kudus from Marshall and IETF powers for reusing BEEP?
That should not be the decision making factor, we should focus on
technical issues.
-Markus