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: a couple paramaters questions



I've been reviewing the latest 2.0 draft over the last two days, and I 
have a couple questions related to combining algorithm parameters. I 
should say up front that these have little to do with the mechanics of 
these features, and are more about some possible simplifications to the 
schema. I know we're up to the deadline, so a quick response (or maybe 
some time to discuss this at tomorrow's FG meeting) would be very 
appreciated!

In the current draft (13), I see that both PolicySet and Policy let you 
specify CombinerParameters, but in both cases it's inside the choice 
that allows any number of parameters. Since CombinerParameters is 
already a container for any number of parameters, why do we need to 
allow more than one per Policy[Set]? I can't figure out what value this 
adds. Unless I'm missing something, I'd like to see only one optional 
CombinerParameters per Policy[Set], which not only simplifies the 
schema, but also the spec, since we currently explain in a number of 
places that having multiple CP elements just results in them being 
concatenated together. If we only allowed one block, then we could 
remove all the extra text.

A related question has to do with parameters for specific 
Rules/Policies/PolicySets. We don't have different CombinerParameters 
types for policy and rule combining algorithms, but we do have 
different ones for policyset, policy, and rule. Why is this? The three 
all behave the same way and have the same contents. The only rationale 
I can think of is that this allows a Policy and a PolicySet to have the 
same identifier, but we already handle this case, in fact we're 
explicit about this in the text explaining how parameters for 
references are handled. Can someone help explain this to me? I'd like 
to use just one type, but I suspect there must be a reason for this 
naming choice...

Thanks!


seth



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