Subject: RE: HTTP as OCP transport, ICAP/2.0

From: "Martin Stecher" <[email-masked]>
Date: Thu, 24 Apr 2003 14:42:16 +0200

Hi,

> 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.

I am just returning from an easter holiday, sorry for the delay.

I fully agree to what Hilarie and John explained regarding the ICAP history and the motivation to have it in a HTTP-like style.

ICAP developers from the first hours that migrated from ICAP/0.9 and ICAP/0.95 to ICAP/1.0 already experienced the development from a pure HTTP implementation to a standalone protocol (which is still very much like HTTP though).

It is definetly a plus that ICAP developers can benefit from their HTTP protocol experience and probably have already some source code around that can be reused when implementing ICAP.

On the other hand ICAP/1.0 is different from HTTP and that may require changes to existing HTTP handling code which may introduce new problems as well, e.g. the existence of two zero-end-chunks within one message.
If you look in the ICAP implementation within the Squid project you will also find that reusing the HTTP code for ICAP can make things hardly readable.

Getting this together I believe that ICAP/2.0 can have a different transport than HTTP. Creating a new ICAP version without touching the transport layer seems nearly impossible to me.
Picking a fully binary protocol would be a too big difference though. I think ICAP TNG should still have some text elements and some ICAP-known syntax elements like icap-URIs.

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 24 Apr 2003 09:28:40 -0600 (MDT)

On Thu, 24 Apr 2003, Martin Stecher wrote:

> Getting this together I believe that ICAP/2.0 can have a different
> transport than HTTP. Creating a new ICAP version without touching
> the transport layer seems nearly impossible to me. Picking a fully
> binary protocol would be a too big difference though. I think ICAP
> TNG should still have some text elements and some ICAP-known syntax
> elements like icap-URIs.

Thank you for detailed comments, Martin. Given your position (and
absence of other HTTP-related comments/objections), I will nominate
BEEP as the OCP transport (I will do that on a separate thread
shortly). With BEEP, we can keep the OCP headers text-based while
still allowing for fast, efficient parsing. Or we can have them
XML-based (also text but not optimized for parsing). I also agree that
we should reuse "good things" from ICAP, as much as possible.

Thank you,

Alex.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 24 Apr 2003 09:41:06 -0600 (MDT)

I would like to nominate BEEP as the only OCP transport. My primary
reasons for nominating BEEP are:

	- reuse of BEEP negotiation capabilities for
	  transport encryption and such

	- availability of efficient transfer for
	  opaque ("binary") data

There are several issues that we would need to resolve if BEEP is
selected by the group (e.g., selecting BEEP message exchange model and
defining OCP message encoding), but I would like to hear other
protocol nominations (Hilarie?) or any objections to BEEP before
discussing BEEP-specific details.

I hope I am not making a mistake by giving BEEP a preference over
SOAP. I would really like to use SOAP because that is what web
services world is using, and we are doing something very similar.

Unfortunately, SOAP suffers from a legacy of being started as an RPC
protocol and has no standard way of handling large opaque data
[efficiently]. If BEEP is selected, we would essentially trade
"efficient transfer" for "current deployment". I hope that is the
right choice, especially since SOAP can still be used as another
callout protocol in environments where efficient transfer is not
important. If you think otherwise, please speak up now.

We have talked about all known transport candidates except Hilarie's
OCPTRAN.  Let's move this discussion to a closure. OCP work cannot
proceed much further without the transport selection.

Thank you,

Alex.