MHonArc v2.5.2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [xacml] Function Document Issues
On Mon, 26 Aug 2002, Daniel Engovatov wrote:
>
> >that said, my 'proposal' is to ask that you post to the list the
> >specifics of what you think we should limit the discussion to. that
> >would help clarify the situation (to me anyway :o)
>
> >thanks
>
> >b
>
> I believe we ended up the call agreeing on the document, as it is, minus
> the *-on-error functions, that Polar added a bit later. We should certainly
> discuss those. My personal opinion - is that having some additional
> error-hiding functions is not necessery, and it never came up previously,
> though I do not object that it may be useful for some use cses that I am
> unaware at the moment.
If we use the definitons of AND, OR, and N-OF that we have now, we have
Error Hiding functions, which came after the call.
> Attached is the specification document, as we finished the discussion today.
> We resolved several open issues. I would propose that we review it and vote
> on accepting.
> If I understand correctly there are two change requests open for discussion.
> 1) Add Error catching functions as proposed by Polar
> 2) Rewrite "or" and "and" specifications to allow accepting invalid(error)
> arguments for the cases, when them having an explicit boolen value would not
> change the result.
I don't agree with forcing anything opportunisticly to a vote without some
level of agreement from all of us. I don't want to "freeze" anything that
is still in gel form, just to railroad it into a brick.
Let's keep discussing the issues and productively come to a conclusion on
the matters before we vote on anything.
Cheers,
-Polar
> Please correct me if I missed anything.
>
> Thanks.
>
> Daniel.
>
>
> On a side note:
> Also I do not think that, given that we do have arithmetic operations and
> missing external data occurring as a normal operational procedure, declaring
> of a simple, definitive and deterministic way of computing INDETERMINATE
> result of a rule evaluation is in any way an "abhorent" practice - so far I
> have not seen any clear use cases or concrete examples demonstrating
> otherwise.
>
> If I remeber correctly - addition of INDETERMINATE, as a separate evaluation
> result from NONAPPLICABLE is something we all agreed on for quite some time
> - thus we do need explicit rules of computing such result.
>
> It would not quite work if encountering an overflow, when adding two numbers
> received from PEP, one PDP will subsitute resulting value with some default,
> other make rule NONAPPLICABLE, other produce INDETERMINATE for one rule and
> yet another one halt evaluation.
>
>
>
>
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC