[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. Regards, Erik 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]