Subject: RE: OPES Status Update, Drafts, ICAP

From: "Martin Stecher" <[email-masked]>
Date: Wed, 25 Sep 2002 09:08:35 +0200

Hi Arumugam,

> 2. One concern over the request modification.
> 
>    Icap client sends  the client request to icap server. The 
> icap server
>    could sent an adapted request , an HTTP error message
>    indicating the client request is prohibited or ICAP error msg.
> 
>     The icap server sends ICAP error msg due to an error in ICAP
>     semantics such as ICAP request is not correct or service not
> available.
>     In this case , the icap client can either forward the original
>     request without any modification to OS or send an error msg to 
>     client stating that the service could not be provided.
> 
>     It would be useful if the draft says how to handle this scenario.
> 

There is no clear way how to handle this.
Examples:
 - If a virus filtering RESPMOD service sends an ICAP error, the original request is probably better not bypassed
- If an advertising removal RESPMOD service sends an ICAP error, bypassing the original response is probably the prefered option.
- If an Internet Access Management REQMOD service sends an ICAP error, there will be companies that would allow a bypass while others prefer to block the request.

So usually the bypass flag is an option to set with the ICAP service that is defined at the ICAP client. It does not belong to the protocol specs, I think.

> 
> 3. The draft is not posing any prerequisite to the tools used 
> to provide
>    the actual services. Based on the protocol , it seems to 
> be valid to
>    have few prerequisite on the service tools.
> 
>    1. The tool has to be run in non-interactive mode. GUI interface is
>       not needed.
> 
>    2. The tool should be started by cli. Allows to pass command line
>       arguments.
> 
>    3. In the simplest form, each instance of the tool serves only one
>       request.Considering the overhead due to the size of the 
> tool and 
>       time to load and make it ready , it would be fine to 
> make a single
>       instance of the tool to serve multiple requests either
>       sequentially or parallely. I am not sure how far this is
> achievable.
> 

Does this belong to the protocol specs?

> 
> 4. It could be possible to make use of the ICAP protocol for real
>    bandwidth savings.This is possible by providing a service 
>    called decompression.
> 
>    For example, consider a scenario.
>    The client makes a request to html page in OS. Due to ICAP 
> ,a request 
>    with  a url which points to the compressed copy of the html page is
>    sent to OS. This is done in REQMOD mode.
> 
>    OS sends back the compressed data. The compressed data is sent to
>    ICAP server which can decompress and send the data in the format 
>    requested by the end-user. This is done in RESPMOD mode.
> 
>    Thus the bandwidth needed to transfer the html page is 
> reduced to the
>    level of compression.
> 
>    If this service is considered as a valid one, then this 
> service could
>    be mentioned in the draft.
> 
> 

While having good examples in a draft is nice for easier understanding, it is impossible to provide the full list of all valid and usefull services.
I think a place like the ICAP forum is better to collect all ideas for ICAP services.

Regards
Martin

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 25 Sep 2002 10:01:27 -0400

Martin Stecher wrote:

 > So usually the bypass flag is an option to set with the ICAP
 > service that is defined at the ICAP client. It does not belong to
 > the protocol specs, I think.

I agree with Martin that this is *not* a protocol issue. The protocol 
only provides the means to inform the OPES proessor (i.e. the ICAP 
client) about the result of the callout service. The reaction of the 
OPES processr (i.e. the ICAP client) depends on the preferences as 
specified by the user - user A might want to simply bypass the 
service, while user B might want to block the transaction if the 
service cannot be executed (most likely will also depend on the type 
of service). This is not really related to the protocol, but much more 
to the rules specificatin language (which is also a work item of this WG).

 >> 3. The draft is not posing any prerequisite to the tools used to
 >> provide the actual services. Based on the protocol , it seems to
 >> be valid to have few prerequisite on the service tools.
 >> [...]
 >

Nup, don't think so. These are more (local) implementation decisions. 
And although the issues mentioned might make sense, they're 
independent and don't have an impact on the protocol itself.

 > While having good examples in a draft is nice for easier
 > understanding, it is impossible to provide the full list of all
 > valid and usefull services. I think a place like the ICAP forum is
 > better to collect all ideas for ICAP services.

An even better place would have been this mailing list, since the WG 
has been workig on a use cases draft :) Nevertheless, it's clear we 
cannot provide a complete list of examples, and the current use case 
draft should cover a representative set.

-Markus