[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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