I think there should be provision for specifying "On failure Actions" for every
rule author( publisher/consumer). And it should be certainly for end user(
consumer).
Few days back, I had put up these issues in mailing list. I had also
proposed changes in rule file by addition of one attribute "MANDATORY" to
"ACTION" element.
If attribute is MANDATORY, it specifies that, execution of this service is
MUST. If service couldn't be executed due to unavailability or crash, then some
error should be sent.
I had also suggested provision of alternate service location element in
rule
file,if rule author is providing a service location. Or,rule author can also
specify some default service( of same type) provided by OPES owner.It can be
virus scanning.
Comments ?
--Rajnish
Date: Wed, 15 Aug 2001 22:54:16 -0400
From: Markus Hofmann <hofmann(_at_)bell-labs(_dot_)com>
X-Accept-Language: en
To: Hilarie Orman <HORMAN(_at_)volera(_dot_)com>
CC: ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: OPES Failure Handling
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.imc.org/ietf-openproxy/mail-archive/>
List-Unsubscribe:
<mailto:ietf-openproxy-request(_at_)imc(_dot_)org?body=unsubscribe>
List-ID: <ietf-openproxy.imc.org>
Hilarie Orman wrote:
Well, the local system can actually override anything that
violates local policy, and if the local policy forbids download
from the alternative site, it doesn't have to execute that
action.
Hm, ok, but in this case one has to make sure that the user (i.e.
content provider or content consumer) is aware of local policy and
accepts it (otherwise the user might decide to not use the service).
It must not happen that local policy changes the behavior in a way
that was not intended by the user who authorized the service.
Your example, though, has rules for individual users
connected with failure of the service, and that's a more
complicated situation. The original rules were presumably
put there on behalf of the virus scanning service, in order
to quickly determine what content needs scanning and
which doesn't. Your scenario proposes that each user can
attach individual "on failure" actions to that service, and
I'd be concerned about getting too many user-specific
rules tied into the dispatch database.
Yup, I share your concerns about too many user-sepcific rules, good
point. However, I'd suspect that there won't be too many different
alternative actions for failure cases, so users could chose which
alternative they would like and could subscribe to the corresponding
tuple of servive and failure action.
For example, there might be a virus scanning service and two possible
actions in case of a failure: (a) deliver file without scanning, and
(b) block unscanned files. Subscribers to the virus scanning service
would have to pick one of the alternatives, and depending on their
choice, they would be included in either group A (virus scanning
subscriber with failure alternative (a)) or group B (virus scanning
subscriber with failure alternative (b)). We could then have two rules
like "if user is in A, do virus scanning and in case of failure
deliver content" and "if user is in B, do virus scanning and in case
of failure block content".
This means that users cannot necessarily attach individual "on
failure" cases, but can chose from a given set of alternatives.
-Markus