People sometimes get worried about the trust model that governs the
web. well, it turns out that without the trust model for congestion
control, TCP and the entire internet would fail tomorrow.
ICAP cannot doing anything truly new; you could always in the past
pull a proxy skeleton core off the shelf and do what ICAP does. So,
the arguments about trust models and how to enforce trust models in
the fetch pipeline are kind of rendered impotent by this alternative.
Before we can argue about how to enforce trust models in a system
containing an ICAP device, it would be necessary for the proxy engine
cores to be banned as "controlled substances" by the DEA and licensed
& controlled as such.
ICAP will provide features that *control* and inter-operate with a
network cache so that ICAP + Network Cache can give you a huge bang
per dollar invested in ICAP server development. The idea is to pull
most of proxy and service-writer complexity into the cache, jack up
the performance, and allow ICAP applications to proliferate.
We can spend time writing trust guidelines for proxy service authors,
but I'd be reluctant because it doesn't seem like custom proxy-writers
are running amok right now.
Most of the things that can be done with ICAP can be done with local
applet, and I am not aware of a set of trust model guidelines for
As for the ASP protocol that might run between an ICAP service (or
custom proxy) and the ASP central service site, i think that this area
is a little new and we should wait a year or two and then enlist the
ASP's into putting forward some proposals in this area.