HTTP as OCP transport, ICAP/2.0

Here are the reasons to use HTTP as OCP transport:

        + ICAP uses HTTP as transport; we can make
          OCP look like ICAP/2.0, which may
          significantly improve OCP survival/adoption
          chances

        + HTTP applications are our primary target;
          it would be easier to add OCP support to
          HTTP intermediaries (OPES processors) if
          OCP transport is also HTTP

        + it is likely that many existing web services already
          support HTTP (e.g., as a part of SOAP over HTTP);
          it would be easier to add OCP support to
          such services (OPES callout servers) if
          OCP transport is also HTTP

        + HTTP is fairly well-understood protocol as
          far as basic transport functionality is
          concerned


Here are the reasons to avoid HTTP as OCP transport:

        - HTTP makes it difficult to support a pipeline of OCP
          messages without converting every message into
          a request/response pair; this limits OCP flexibility
          and/or performance

        - ICAP uses HTTP as transport; if we try to make OCP
          to look like ICAP/2.0, we may have to sacrifice
          some (many?) OCP properties and clean design to
          retain some form of backward compatibility; for example,
          OCP metadata should be distinct from HTTP metadata,
          which may be difficult to achieve while
          preserving compatibility with ICAP/1.1.

        - HTTP lacks appropriate connection management
          primitives because persistent connections were
          added on top of an existing protocol (HTTP/1.0)
          and are just a performance optimization; HTTP is
          not really design for long-lived connections many
          OCP agents would enjoy

        - HTTP lacks appropriate native support for security
          and authentication; compared to SOAP and BEEP,
          little reuse of other protocols/mechanisms is
          possible in this context

        - HTTP specification (RFC 2616) is a big, complicated
          document; HTTP comes with many features that OCP
          probably does not need

Did I miss anything important? ICAP/OPES issues are also discussed, in
part, in the draft-stecher-opes-icap-eval-00 document:
http://www.faqs.org/ftp/internet-drafts/draft-stecher-opes-icap-eval-00.txt

IMO, the primary reason to use HTTP as OCP transport would be
"compatibility" with ICAP. I wonder if ICAP proponents would consider
it possible for ICAP/2.0 or ICAP-NG to use something other than HTTP
as transport? Or will selection of other transports kill the
opportunity to merge ICAP/2.0 and OCP?

What do you think? I am especially interested in comments from Martin
Stecher and anybody else with first-hand ICAP experience.

Thanks,

Alex.