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] IIC012: syntax-error or processing-error?


> Undefined is NOT a value. It merely states that a specific result is not
> deducible from the inputs. It is outside the specification.

precisely my point. it must, however, lead to a value that is an acceptable output. if you look at our options (PERMIT, DENY, INDETERMINATE, NOTAPPLICABLE) INDETERMINATE is appropriate for the JIT crowd because the PDP may have no idea what would have happened to the decision had the policy been readable, but something had to occur to indicate that it *was* applicable. 

NOTAPPLICABLE, on the other hand is appropriate for the precompile crowd (as long as no other polices are found to be relevant) since the policy "doesn't exist".

> You have a lot of work to do deciding which evaluation models to use, such
> as indexing, the way in which you index, the way in which you evaluate
> Ands and ORs. That is, you have to decide or lock down the way in which
> And and ORs are evaluated. Where do you start runtime typechecking, where
> do you stop? The Policy? The Rule? The And expression? Do you do the same
> for syntax?  Remember <Policy/> is valid XML, so a stupid parser will pick
> it up just fine.

implementation issues. this is why option 'b' is not palatable.

> And then you have to strictly call out the scenarios in which badly formed
> policies or badly formed expressions that are not evaluated by one
> interpretation of a combining algorithm against another combining
> algorithm or expression evaluator.
> 
> It's not that simple.

with a little word smithing i think that we can convey the difference. will it be utterly definitive? no, but we can take a shot at indicating basic behaviors (in those case where JIT mechanisms are used, run-time errors must return INDERMINATE/error...)

being an integrator at heart, what i am trying to achieve is a model whereby problems with the system are discernible as part of the fundamental communication progress. this is why i am a big fan of mandatory status codes. if there is a better way to achieve this, then i am all ears, but i would like to try to come up something, even if it is philosophical, that will encourage similar behavior amongst similarly architected solutions.

b



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


Powered by eList eXpress LLC