Re: OPES Failure Handling

[Rajnish Pandey <Rajnish.Pandey@xxxxxxx>]

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@xxxxxxxxxxxxx>
> X-Accept-Language: en
> To: Hilarie Orman <HORMAN@xxxxxxxxxx>
> CC: ietf-openproxy@xxxxxxx
> 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@xxxxxxx?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