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] [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