Re: [xacml] IIC012: syntax-error or processing-error?

[Polar Humenn <polar@syr.edu>]

On Wed, 4 Dec 2002, bill parducci wrote:

> > 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.

Any output is acceptable.

> 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.

I would admit that may be logical, but say that the offending piece is in
buried deep a poriton of the policy decsription that may not be evaluated according to
some models, and may be evaluated according to other models, against the
same inputs? Then what will you say the "conforming" result MUST be?

> 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".

In this case it all depends on the combining algorithm used.


-Polar

> > 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
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>