Re: OPES Status Update, Drafts, ICAP

[Ralf Horstmann <Ralf.Horstmann@xxxxxx>]

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"'