[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] IIC012: syntax-error or processing-error?
I also like option a: - Allow for implementations that will NEVER try to evaluate a syntactically invalid policy at the time a Request is received: such implementations will be exempted from the tests that have syntactically invalid policies. - If an implementation MAY EVER try to evaluate a syntactically invalid policy at the time a Request is received: specify that the Decision is to be Indeterminate and the StatusCode Value is to be "urn:...:syntax-error" I will modify the Conformance Tests that currently generate an "Indeterminate" by a type incompatibility to use either a missing MustBePresent attribute or a divide-by-zero, except in the cases where I was explicitly testing the handling of an invalid policy file. I can use a validating XML parser to do the XML syntax checking of all the Conformance Test policies, but I do not have a way of checking type correctness at this time. If someone could make a pass through the Conformance Test *Policy*.xml files to check for type correctness, I would appreciate it. Anne On 4 December, bill parducci writes: Re: [xacml] IIC012: syntax-error or processing-error? > From: bill parducci <bill.parducci@overxeer.com> > To: "'XACML TC '" <xacml@lists.oasis-open.org> > Subject: Re: [xacml] IIC012: syntax-error or processing-error? > Date: Wed, 04 Dec 2002 10:28:46 -0800 > > > Polar Humenn wrote: > > For the case when you have a single malformed policy to be evaluated > > against a request, the answer is just simply undefined. The implementer > > can choose. Therefore, there should not be a "CONFORMANCE" test for it. > > 'undefined' needs to manifest itself somehow in the decision. > > back to the run-time vs. precompiled topic for a sec.. > > supposing that there is a use case/conformance test that has a mis-typed (or otherwise malformed) policy: under the precompiled model, this policy will simply be thrown out upon being communicated to the system; under the run-time model it will generate a status code 'other than OK' and issue a decision of INDETERMINATE. with this in mind we can: (a) allow for both of these scenarios to have it owns conformance criteria; (b) take a stand on which evaluation mechanism is supported; (c) consider it out of scope and allow for unlimted of decision/status combinations. > > i personally think that option 'a' is worth considering because option 'b' forces us to make an implementation decision and option 'c' is a bit loose for my taste. > > b > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC