Re: OPES Status Update, Drafts, ICAP


Hi All,
Thought I would share some of my experiences in implementing ICAP and
using the same in the OPES context as a response to Markus Hofmann's 
call. 

Some background: I have worked on providing ICAP client support in two
proxy servers: squid proxy cache and tinyproxy plus implemented an  ICAP
server in python with an IRML rule engine (at the server-side rather
than the client-side). 
So, some comments are specifically on ICAP and some or in the more
general OPES context.

Some observations:
1. ICAP *is* really a light weight protocol to encapsulate HTTP requests
and responses. 
  ** It requires minimal additional info apart from the payload to be
sent to the server.
  ** The static code size requirements for icap client in a restricted
mem environment was just about 2%  (an additional 6Kbytes to 273 KBytes
tinyproxy code).
2. The PREVIEW header support in the protocol is very useful in
optimizing response modification. Though I do not have real measurements
to prove this as of now, I have found a significant difference in the
response time. More so, when I have no specific filter applied at the
proxy  side and send out all responses for modification.
3. The specification is pretty clear and helps in building
interoperable  servers and clients.

Possible enhancements to ICAP protocol:
*   Standardizing some additional headers to convey client and
subscriber information may be useful - could be along the lines of the
draft on
OPES Subscriber Identification.
*   Security: Minimum support for security may be provided by just
supporting an additional header similar to WWW-authenticate.


OPES:
*   Though the decision on standardising multiple content modifications
is deferred here, personally I found multiple 'request' modifications
very useful and mostly without conflicts. They result in extremely
simple proxylets that can be combined very effectively to get the
required result. In  fact, the best way to get that going, I found, was
to do the rule processing in the ICAP server end rather than in the
proxy  server. That way  you need to send the HTTP request only once.
BTW, all these are w.r.t demo prototypes not really a commercial
deployment scenario.
*   OPES docs suggest control on content modification rules by three
parties, viz., (a) client/subscriber (b) ISP and (c) content provider. A
means for providing this  control is  yet to be proposed (to my
knowledge). Specifically, if the client needs to have a control on the
rules at the granularity of every request, this can   be done by
introducing an additional info in the HTTP header (or use the 
cache-control header).

Hope this is useful.

Thanks and regards,
Geetha

Markus Hofmann wrote:


Hi,

time for a brief status update on our OPES activities and on immediate
next steps.

... stripped ...

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?
  (e) Are there any findings/measurements with respect to ICAP
      performance that would be interesting to be shared with the WG?
  (f) More, more, more,... please add...

A good starting point might also be the individual Internet Draft on

   "Evaluating the ICAP protocol regarding the OPES callout protocol
    requirements"
    draft-stecher-opes-icap-eval-00.txt

So, please check out both ICAP-related drafts and share your thoughts
on this mailing list. Should be enough material for some interessting
discussions.

Cheers,
   Markus