Subject: ICAP suggested changes/ call for comments

From: Jeremy Elson <[email-masked]>
Date: Wed, 04 Oct 2000 02:14:58 -0700

Hi,

Some of the early implementors of the new ICAP protocol have been
meeting over the past couple of weeks to discuss how the protocol is
broken based on recent implementation experience.

Based on these discussions we would like to change the protocol in
certain ways that we think will make it better but will break
interoperability with existing implementations (hey, it was just a
draft, right? :-) )

The purpose of this message is to ask any other implementors of ICAP
to please join us in our current discussions.  In particular, if you
have any proposed changes that you think would make the protocol
better but would break interoperability, this is a good time to speak
up since we're breaking it anyway (and only want to break it once).

Please let me know if you'd like to be included in our teleconferences
that are Thursday mornings at 9AM Pacific time.

The current (proposed) changes that break interoperability are:

1- Chunked encoding will be required, instead of optional (this only
affects clients since servers need to understand chunking anyway)

2- Encapsulation Forwarded HTTP requests and responses will be
changing.  Both forwarded bodies *and* forwarded headers will be
contained completely in the body of ICAP message instead of
encapsulating the (inner) forwarded headers in the (outer) headers of
the ICAP message.

3- We want to make the simplifying assumption that the ICAP server is
in the same admin domain as ICAP client.  Parts of the protocol had
already made this assumption (e.g. for configuration and
authentication purposes) but it would make things easier if this was
assumed throughout.

Also, at the suggestion of some within IETF we will most likely define
ICAP to use a port other than 80.  (No one on our side of the fence
feels strongly at all about this issue; we're just doing what we're
told :-))

If you have feedback please let us know at [email-masked], or
join our teleconf on Thursdays.

Regards,
Jeremy

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 04 Oct 2000 18:34:10 -0400

Hi Jeremy,

> affects clients since servers need to understand chunking anyway)

This assumes that either no (interception) proxies/caches are on the
path between ICAP client and ICAP server, or that all proxies/caches on
that path support chunked encoding and forward the message chuncked.
This might limit scenarios in which ICAP can be used. Could this be kept
optional? This might increase implementation complexity a bit, but it
would allow usage of ICAP in the above mentioned environments (having
the buffering problem again, of course).

Hm, the problem might also be "solved" by using a port different from 80
et. al and by assuming that no other proxy/cache on the path will
"intercept" this port... don't want to start the discussion about
"interception proxies" again... but they might be there...
 
> in the same admin domain as ICAP client.  

Hm, this might simply things at the moment, but in general it might not
be a good idea to base the protocol design on this assumption. We can
imagine scenarios in which a cache service provider collaborates with,
for example, a translation service provider - in different admin
domains. We would like to have a solution that also works in such an
environment - which, of course, would also require mechanisms for
authentification and authorization (which might be added later on, but
the basic protocol design would still work).

Another suggestion we have: Would it make sense to allow multiple
ICAP-URIs in a single message? Example: We want to execute two services
in Response Modification mode at the same ICAP server, e.g. ad insertion
and translation (or vice versa :). Instead of sending two requests in
sequence to the same server, it would make sense to send only a single
request including both ICAP URIs (i.e ad insertion and translation).
What would be the syntax, and what about the ordering (ssems to be
important, too).

-Markus and Andre