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