On Mon, 16 Sep 2002, Markus Hofmann wrote:
time for a brief status update on our OPES activities and on
immediate
next steps.
[...]
As such, it's time for all of us to carefully read the ICAP
Internet Draft
"ICAP - the Internet Content Adaptation Protocol"
draft-elson-icap-01.txt
and to provide comments on this protocol specification in the context
of OPES. Please be aware that the ICAP specification is *not* a
product of the OPES WE, but represents an individual submission,
documenting a "status quo". Nevertheless, it's of quite some
relevance
for our WG, and we better have a careful look at and comment
on it. In
particular, it might be interesting to discuss:
(a) How does ICAP fit into the OPES context and how does it stack
up to the OPES protocol requirements?
(b) If there are open issues, would it make sense for the WG trying
to recommend extensions toICAP so that it'll meet all
requirements?
(c) What are the strengths, the weaknesses, and the limitations of
the current ICAP specification? Are there lesson to be learned
from the spec and from the work on ICAP?
(d) Given that there are several (commercial) implementations
of ICAP out and in use - are there any lesses learned from these
implementations? Is the current specification stable and clear,
or are there any open issues or issues to clarify?
I'm working on the ICAP client implementation for Squid. See
http://icap-server.sourceforge.net/squid.html for details.
The ICAP specs were quite useful to get the implementation
ICAP/1.0-compliant. In my opinion the specification is clear and ensures
that different ICAP implementations will work just fine together.
Regards, Ralf.
--
ruby -h | ruby -e 'a=[];readlines.join.\
scan(/-(.)\[e|Kk(\S*)|le.l(..)e|#!(\S*)/) \
{|r| a << r.compact.first };puts "\n>#{a.join(%q/ /)}<\n\n"'