ietf-openproxy
[Top] [All Lists]

Re: OPES Status Update, Drafts, ICAP

2002-09-25 07:01:33

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.
>> [...]
>
> Does this belong to the protocol specs?

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


<Prev in Thread] Current Thread [Next in Thread>