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

Subject: Re: [xacml] Optimization and side effects

Hi Seth,

Thanks for pointing this out. I didn't find this section when I was 
looking for a statement like this. I think this is good enough as it is 
since it states both that no side effects are allowed and that the order 
cannot be guaranteed. So, I withdraw my proposed change.


Seth Proctor wrote:
> Hi Erik. FYI, if you look at the final section of appendix A you'll 
> see that we do actually require that no extensions introduce 
> side-effects. A big part of this was explicitly because of concerns 
> over re-ordering operation. Of course, I don't think we say the same 
> thing about policy reference/retrieval, so theoretically you could 
> still introduce side-effects at the policy-combining level.
> Certainly the spec is supposed to allow you to re-order many aspects 
> of evaluation, though I think it does this by omission of any specific 
> prohibitions rather than any explicit statement. For what it's worth, 
> I think it's ok to include some comment about allowing re-ordering, as 
> long as it doesn't confuse people into thinking that there's an 
> obvious way that things *should* be re-ordered in practice. I think 
> part of why we never called this out explicitly was to make sure that 
> when people first look at XACML, they focus on the basic in-order, 
> recursive model, and then start thinking about how to extend it.
> seth

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