Re: HTTP as OCP transport, ICAP/2.0

Alex Rousskov wrote:

>         + ICAP uses HTTP as transport; we can make
>           OCP look like ICAP/2.0, which may
>           significantly improve OCP survival/adoption
>           chances
Hm, does ICAP really use HTTP as transport, i.e. run on top of HTTP? 
I'd say ICAP is a protocol that looks very much like HTTP and uses TCP 
as the transport. Indeed, RFC 3507 states "ICAP uses TCP/IP as a 
transport protocol.  The default port is 1344, but other ports may be 
used.".
In the early stages of ICAP, it was supposed to run over HTTP, but 
this was dropped at some later point.
>         + 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
An additional pro might be firewall traversal, although this might not 
be that big of an issue in deployment scenarios OCP will play a role (?).
> 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
The kind of "streaming capabilities" of HTTP (i.e. chunking) is kind 
of limited.
If running over HTTP, would we expect problems with HTTP 
intermediaries sitting in-between the OPES processor and the callout 
server (for example if OPES processor and callout server ane in 
different adminsitrative domains).
-Markus