Re: OPES Status Update, Drafts, ICAP

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.

> 2. The PREVIEW header support in the protocol is very useful in
> 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.
> 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.
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.
> *   Security: Minimum support for security may be provided by just
> supporting an additional header similar to WWW-authenticate.
The OPES protocol requirements seem to go even further...

> *   Though the decision on standardising multiple content modifications
> is deferred here, personally I found multiple 'request' modifications
> 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,...
> *   OPES docs suggest control on content modification rules by three
> 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.
> means for providing this  control is  yet to be proposed (to my
> 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