Hi Jeremy,
just some quick thoughts and comments on the proposed modifications:
> 1- Chunked encoding will be required, instead of optional (this only
> 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...
> 3- We want to make the simplifying assumption that the ICAP server is
> 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
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:29 MST