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