RE: OPES Status Update, Drafts, ICAP

["Martin Stecher" <martin.stecher@xxxxxxxxxxxxx>]

Hi.

> 
> So far, it seems that the ICAP protocol specification in its current 
> form does not have major hiccups that would leave room for 
> misinterpretation and interoperability problems. However, did 
> somebody 
> actually do some interoperability tests of different ICAP 
> implementations? Do different, independent ICAP implementations that 
> conform to the current spec easily interoperate with each other, or 
> are there parts that leave room for different interpretations?
> 

I tested the WebWasher ICAP server against five different ICAP clients and I tested the WebWasher ICAP client against three different ICAP servers.
During testing (or later in productive environments) we found some communication problems. But for all of these problems the protocol draft gave us a clear statement which side was correct and which side was wrong. After fixing the problems we run with all the mentioned clients and servers without having any special workaround code except of one setting that addresses a typical problem I found several ICAP clients have in the beginning and which is usually solved in later revisions of the ICAP client: Handling an ICAP response header which is sent in multiple TCP packets. (This problem is beyond the protocol specifications)

So from my experience the protocol draft is really clear in how to design interoperable implementations.
On the other hand I already saw a switch in another ICAP client to set the type of ICAP server. I have no testing experience with the servers mentioned there. So there may be protocol problems that I am not aware of or just bugs that have been worked around that way.

I hope that the guys that experienced the reason for such a switch will speak up in this forum and share their experience with this group.


> Now, we also need to look beyond questions about the 
> clearness and the 
> stability of the current ICAP specification. I'd like to get some 
> feedback on how people feel of ICAP with respect to the laid out OPES 
> architecture and the OPES protocol requirements. How does ICAP fit 
> into this picture? Are their major roadblocks, minor issues 
> that could 
> be "fixed", or is the current ICAP perfectly fine?

ICAP is good but not perfect I think. Please check again my evaluation paper (draft-stecher-opes-icap-eval-00.txt)
It could be a good starting base. For me the OPES protocol could be an ICAP/2.0 implementation.

> 
> > 2. The PREVIEW header support in the protocol is very useful in
> > optimizing response modification. 
> 
> I can see and agree that the "preview" mechanism is quite useful in 
> several secnarios. However, it requires that the preview size is 
> statically agreed on a-priori. I could imagine that there are 
> services 
> that can deliver a final response before receiving the entire 
> message, 
> but without knowing how many bytes (i.e. preview size) they need to 
> see before being able to do so. Simple example: A filtering service 
> searching for certain keywords in the message. As soon as a forbidden 
> keyword is detected, there's no need to further analyze the reminder 
> of the message, the transaction can be finished immediately. So, it 
> would be nice to have a more general mechanism that would allow the 
> callout server to present a final response to a transaction at any 
> given time, and not only after receiving the preview or after 
> receivingthe entire message.
> 

I fully agree: Having a flexible number of decision points in the protocol would be a big plus.

Beside this I believe that although ICAP is simple, the protocol could even be simpler. It's one and a half year ago that I started the discussion about the Encapsulated headers and a proposal to simplify things using more chunk extensions.

Meanwhiletime I have strong interest to have a callout protocol that it able to support many different application protocols. OPES wants to concentrate on HTTP and RTP first which is fine but we should prepare the protocol from the very beginning to be easily extendable.

We have some experience how to encapsulate FTP and even SMTP into ICAP although ICAP is specifically designed for HTTP and while FTP encapsulation is still simple, the SMTP stuff is much harder because of one important difference: The HTTP and FTP data is sent to one recipient (the requesting client) while a mail message is sent to many different recipients that could have different filtering needs. ICAP is not prepared to handle this.


Martin