Subject: OPES Status Update, Drafts, ICAP

From: Markus Hofmann <[email-masked]>
Date: Mon, 16 Sep 2002 23:36:15 -0400

Hi,

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

Document Status
===============
Three WG drafts have been submitted to the IESG for consideration as 
informal RFC, namely

  "An Architecture for Open Pluggable Edge Services (OPES)"
  "Requirements for OPES Callout Protocols"
  "OPES Use Cases and Deployment Scenarios"

The first version of our "document on endpoint authorization and 
enforcement requirements", named

   "Requirements for Policy, Authorization and Enforcement of OPES
    Services"

has been published as Internet Draft. Please read it carefully and 
provide comments and feedback via this mailing list ASAP. We'd like to 
wrap up this draft very soon - please read and discuss it *now*!

A few folks are currently preparing a first version of our "document 
on threat/risk model for OPES services". We expect to have it 
pusblished as an Internet Draf in October, in time for the next IETF 
meeting.

OPES Protocol Work
==================
Since we hope being able to close pretty soon on the five initial 
documents that somehow lay the foundation for our more technical work, 
it's time to start thinking on how to get started on the OPES protocol 
work.

Looking at the charter, we see that "The working group will consider 
the ICAP protocol drafts as an OPES precursor and will will support 
development of an analysis that explains the limitations of ICAP, to 
accompany informational publication of that protocol.".

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

---

From: Geetha Manjunath <[email-masked]>
Date: Mon, 23 Sep 2002 16:42:00 +0530

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:
> ... stripped ...

---

From: Markus Hofmann <[email-masked]>
Date: Mon, 23 Sep 2002 22:49:57 -0400

Hi,

thanks to Ralf and to Geetha for their comments! It's good to get 
"real life" feedback from practial experience and implementation efforts.

So far, it seems that the ICAP protocol specification in its current 
form does not have major hiccups that would leave room for 
misinterpretation and interoperability problems. However, did somebody 
actually do some interoperability tests of different ICAP 
implementations? Do different, independent ICAP implementations that 
conform to the current spec easily interoperate with each other, or 
are there parts that leave room for different interpretations?

Now, we also need to look beyond questions about the clearness and the 
stability of the current ICAP specification. I'd like to get some 
feedback on how people feel of ICAP with respect to the laid out OPES 
architecture and the OPES protocol requirements. How does ICAP fit 
into this picture? Are their major roadblocks, minor issues that could 
be "fixed", or is the current ICAP perfectly fine?

Please take some time and think about it. If nobody has an opinion 
about it, we should probably declare ICAP to be "the" OPES protocol, 
declare victory, and check this item off our list of deliverables. If 
you don't like this idea, please raise your voice *now* and share your 
concerns, the limitations you see, and how they could be addressed best.

Geetha already had some very specific comments.

> optimizing response modification. 

I can see and agree that the "preview" mechanism is quite useful in 
several secnarios. However, it requires that the preview size is 
statically agreed on a-priori. I could imagine that there are services 
that can deliver a final response before receiving the entire message, 
but without knowing how many bytes (i.e. preview size) they need to 
see before being able to do so. Simple example: A filtering service 
searching for certain keywords in the message. As soon as a forbidden 
keyword is detected, there's no need to further analyze the reminder 
of the message, the transaction can be finished immediately. So, it 
would be nice to have a more general mechanism that would allow the 
callout server to present a final response to a transaction at any 
given time, and not only after receiving the preview or after 
receivingthe entire message.

> OPES Subscriber Identification.

Absolutely, such additions are a "must" for certain services. The 
draft you refer to above provides a simple solution for transmitting 
basic subscriber identification. It might be interesting to explore 
whether there's a need for transmitting more generl/comples subscriber 
information. The callout protocol should support that.

> supporting an additional header similar to WWW-authenticate.

The OPES protocol requirements seem to go even further...

> very useful [...]

I agree, although correct error hendling might become quite complex. 
For example, how should the system behave if one of the many services 
fails? What would be the response, how to signal the user which 
service failed, what about tracing of OPES services,...

> parties, viz., (a) client/subscriber (b) ISP and (c) content provider. 

OPES defines services to be executed only if authorized by either of 
*two* parties - the content consumer and/or the content provider. The 
ISP or network provider is not defined being able to authorize service 
execution.

> knowledge). 

The OPES WG will work on methods/languages for specifying rules, but 
it will *not* specify how these rules are actually distributed. (From 
our charter: "The working group will define one or more methods for 
specification of policies, as well as the rules that enable 
application endpoints to control execution of such services").

OK, thanks for the comments so far. Keep it rolling, we need much more 
input!

-Markus