RE: OPES Status Update, Drafts, ICAP

["Martin Stecher" <martin.stecher@xxxxxxxxxxxxx>]

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