[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] [Polar] PH09: New section 7.4.2 Attributes
>And are you ok with the performance/size overhead this incurs? yes >Also, this means > that a function will never know about an empty bag and be able to treat it > differently than an error case, since *-one-and-only is defined to return > Indeterminate if no values are found. functions that do not take attribute bags as arguments do not care about empty bags. > A second, though much smaller problem, is that it effectively requires coders > who create new attribute types to create a *-one-and-only function for each > attribute type they invent if they want this behavior that is correct, if new type is defined every type-* function must be defined as well Simon ----- Original Message ----- From: "Seth Proctor" <seth.proctor@sun.com> To: "Simon Godik" <simon@godik.com> Cc: <xacml@lists.oasis-open.org> Sent: Monday, November 04, 2002 9:59 AM Subject: Re: [xacml] [Polar] PH09: New section 7.4.2 Attributes > > On Mon, Nov 04, 2002 at 09:39:22AM -0800, Simon Godik wrote: > > use type-one-and-only function: > > > > apply string-equal > > apply string-one-and-only > > subj-attr-desig attrid string-uri issuer must-be-present > > attr-val string-uri hello > > And are you ok with the performance/size overhead this incurs? Nearly every > function in the spec is defined to take single values, which means that > nearly every AD/AS used in a policy will need this wrapping. Also, this means > that a function will never know about an empty bag and be able to treat it > differently than an error case, since *-one-and-only is defined to return > Indeterminate if no values are found. When I originally rasised that issue, the > TC was adamant that functions should have the ability to differentiate > between an error case and an empty bag. > > A second, though much smaller problem, is that it effectively requires coders > who create new attribute types to create a *-one-and-only function for each > attribute type they invent if they want this behavior. Why not just have > language in the spec that lets a PDP do this implicitly, and save on size, > computation time, complexity, and flexibilty? > > > seth > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC