OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xacml] functions issues


On Tue, 27 Aug 2002, Simon Godik wrote:

> I think that if a designator is raising error while matching target
> 'error' must be returned.

Okay then we will need a change request for this since the document only
specifies "Match" or "No-Match" for rule evaluation.

I imagine that a policy will evaluate to Indeterminate if there is an
ERROR in the target.

Other questions, do the "logical OR" and "Logical AND" in specified in the
"Match" constructs and "Target" follow the same semantics as the ones
we have as far as ERROR/Indeterminate goes?

-Polar

> Simon
>
> ----- Original Message -----
> From: "Polar Humenn" <polar@syr.edu>
> To: "Simon Godik" <simon@godik.com>
> Cc: <xacml@lists.oasis-open.org>
> Sent: Tuesday, August 27, 2002 12:14 PM
> Subject: Re: [xacml] functions issues
>
>
> > On Tue, 27 Aug 2002, Simon Godik wrote:
> >
> > > I'm ok with the way 'or', 'and' are descirbed in the latest document:
> > >
> > > 'or': First to last, 'true' if one arg evaluates to 'true'. If any arg
> raises an error, return an ERROR.
> > > 'and': First to last, 'false' if one arg evaluates to 'false'. If any
> arg raises an error, return an ERROR.
> > > In any case, if definitive result can be concluded, the rest of the args
> is not evaluated.
> > >
> > > Here is a variation that forces all args computation, even in the
> presense of an error:
> > > (Longer, but gives your a better chance to succeed):
> >
> > Actually, the "variation" a better approximation to the formal result, and
> > it sort of matches the semantics that we have chosen for our combinators.
> >
> > > Compute all 'and', 'or' args first to last. If 'error' is raised use it
> as placeholder until all computation is complete.
> > > If 'error' could be substituted with either (true, false) without
> changing an outcome, return outcome.
> > > Otherwise return error.
> >
> > > In any case, I do not see any errors being 'hidden', meaning changing an
> outcome of computation.
> > > Simply some errors are relevant and some are not.
> >
> > > I do not agree with defining error functions and default values.
> >
> > I don't see what the big fuss is. The fact is that if you have errors, you
> > notice them, it follows that you just may want to handle them, and then
> > you should have formal mechanisms to do so. I'm just trying to be
> > thorough and complete. However, I'll take them out.
> >
> > Further more, I would like to know what happens when a SubjectMatch or
> > ResourceAttributeSelector, or ActionMatch results in an ERROR for the
> > target of a rule, a policy?
> >
> > Cheers,
> > -Polar
> >
> >
> >
> >
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC