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] Question on xacml 2.0 - multiple action-id Request/Action elements


Rich,

I think that it does introduce complexity in that once compound  
actions are introduced the relationship between them is ambiguous  
unless further machinery/description is also introduced to handle it.   
The comma used in  "read,write" lacks referenceable meaning in the  
current specification and therefore lends itself to open  
interpretation. In general we have always tried to avoid this type of  
situation because it tends to lessen the chances for interoperability.

Therefore I would offer that is not just a complexity/performance  
issue. One could argue that the TC doesn't dictate attribute values,  
however it seems to me that there is merit in discouraging the  
creation of non-normative syntax for creating compound attribute  
values, particularly since there seems to be a viable alternative at  
hand that provides the desired functionality.

b

On Sep 18, 2008, at 10:31 AM, Rich.Levinson wrote:

> Hi Erik,
>
> I agree there are multiple ways to address the problem. Personally,  
> I do not believe the approach I have suggested necessarily results  
> in any significantly increased complexity.
>
> However, I do not think that can be the basis for how the TC  
> presents its recommendations and guidelines. For example, the fact  
> that the whole policy structure and requests and responses are  
> written in the spec in xml does not constrain the implementor to use  
> xml at all, as I understand it.
>
> It is very possible that different implementation technologies lend  
> themselves to more or less efficient policy processing depending on  
> how one writes the policies. Just because an XML representation of a  
> Policy is complex doesn't mean that the underlying implementation of  
> that Policy necessarily has to be complex.
>
>   Thanks,
>   Rich



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