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] 2.0 draft 13 comments



Thanks for the comments on the comments! Comments (on comments (on 
comments)) in line :)

>> Section 5.20: The last sentence ("* represents any sequence of digits 
>> of
>> length zero or more") should be removed, as it is inaccurate. Also, 
>> this
>> section might be better placed near the start of section 5, so it's in
>> correct descent order, like the rest of the elements described in this
>> section, but I don't think that's too critical.
>
> I just think it needs to be reworded, not removed.
>
> The expression "(\d+\.)*" means a zero or more length sequence of the
> expression contained within the parentheses, which is a sequence of one
> or more digits then followed by a dot.

Sounds fine to me.

> However, I don't understand these:
>
>> Section 5.26: Lines 2331 and 2332 should be removed.
>>
>> Section 5.27: Lines 2361 and 2362 should be removed.
>>
>> Section 5.28: Lines 2392 and 2393 should be removed.
>
> Unless I got the wrong line numbers, you are saying to remove:
>
> <CombinerParameter> [Any Number]
> 	A single parameter. See Section 5.25.
>
> This is merely an explanatory item that by convention we have in the
> document that explains the child elements of the element being 
> specified.
>
> I see its just because the type extends CombinerParameters, which
> includes those. Should we state maybe that by virtue of extending
> "CombinerParameters" the <RuleCombiningParameters> element contains 
> the the
> following:
>
> <CombinerParameter> [Any Number]
> 	A single parameter. See Section 5.25.

The issue is that the structure being described doesn't include that 
element, it just happens to extend an element with that element (as you 
note). If we duplicated description everywhere we extended a schema 
element, we'd add several pages. We should explain in the three 
elements what they contain, and then reference the base type which in 
turn already explains the CombinerParameter element (which is how this 
is done elsewhere). I think it's fine to include a sentence that says 
the element includes parameters, but we shouldn't call out the element 
as if it's a new element of each of the three types, since that breaks 
with the convention in the rest of the spec (and, actually, most other 
XML specs I've seen).

>> Section 7.5: The sentence on line 3340 starting "An element of the
>> bag..." should end with ", as explained below." Otherwise its unclear
>> how this works. Also, the end of the sentence starting on line 3355 is
>> incorrect. A function used in a TargetMatch needs to accept base types
>> as both parameters. So starting on line 3357, the text should read 
>> "the
>> extension function returns a boolean result and takes two single base
>> types as inputs."
>
> Actually, the lines that you talk about are completely wrong! It should
> read:
>
> In addition, functions that are strictly within an extension to XACML 
> MAY
> appear as a value for the MatchId attribute, and those functions MAY 
> use
> data-types that are also extensions, so long as the extension function
> takes two arguments and returns a boolean result. Since the first 
> argument
> to the function will come from the <AttributeValue> element of the
> <SubjectMatch>, <ActionMatch>,<ResourceMatch>, or <EnvironmentMatch>,
> their data-types must coincide. Since the second argument to the 
> function
> will come from the bag of items generated by the <AttributeDesignator> 
> or
> <AttributeSelector> of the match constructs, their data-types must
> coincide. The function used as the value for the MatchId attribute 
> SHOULD
> be easily indexable. Use of non-indexable or complex functions may 
> prevent
> efficient evaluation of decision requests.

Sounds fine to me. Thanks for the more detailed language!

>> Section 7.6: The sentence on line 3398 starting "The target value
>> SHALL..." should be removed. We now support empty targets, but not
>> absent targets. Also, the sentence starting on line 3406 "The target
>> value SHALL..." is incorrect. It should either reference Subjects,
>> Resources, Actions, and Environments, or should replace "target" with
>> "Subject, Resource, Action, or Environment"...perhaps we want to have
>> both pieces in there? On line 3414, the word "True" should be
>> replaced with "Match". Finally, in table 3, the second row should read
>> "No 'No match' and at least one 'Indeterminate'" instead of "and at
>> least one 'Indeterminate'".
>
> I agree. Actually, most of that text should be removed, and refer to 
> the
> table, which is precise. Trying to "explain" what happens is hard, and
> often confusing, such as with:
>
> The target value SHALL be "No-match" if the value of a <SubjectMatch>,
> <ResourceMatch>, <ActionMatch> or <EnvironmentMatch> element is False.
>
> Which of course, only applies if none of them threw an indeterminate.
>
> We should state that the semantics of matching is defined by the table.

Sounds fine to me. Would you like to see all the text removed, or 
should we leave in the correct text? I think we want some text, if we 
can make it clear, so it's easier to make the leap to what the table is 
showing, but I'm happy to just go with the table if it's clear what the 
meaning is.

>> Section 7.11: On line 3496, "rule-combining algorithm" should simply
>> read "combining algorithm" and the reference to section 7.10 should be
>> dropped.
>
> It should probably say "policy-combining algorithm". Shouldn't it?

I'm not sure. Maybe that whole section needs to be re-whacked. I think 
I thought it was talking about both rule and policy combining 
algorithms, but I don't have the spec in front of me now. If it's 
talking only about policy algorithms, then yes, let's make that change.

>> Section 10.2.7: The xpath-expression datatype should be removed from
>> the table.
>> Section A.2: The reference to, and definition of the xpath-expression
>> datatype should be removed.
>>
>
> I think that they should remain. We are not getting rid of it yet.

Right. I sent in the comments last night when I thought we had concesus.

>> Section A.3.12:
>>
>>   all-of-any: The second sentence should read "The expression SHALL be
>>   'True' if and only if the supplied predicate is 'True' between each
>>   element of the first bag and any element of the second bag." Also,
>>   starting on line 4609 with the sentence "The expression SHALL be
>>   evaluated", the remaining text in the paragraph should be removed. 
>> In
>>   its place should be the following: "The expression SHALL be 
>> evaluated
>>   as if the 'urn:oasis:names:tc:xacml:1.0:function:any-of' function 
>> was
>>   applied to each value of the first bag and the whole second bag 
>> using
>>   the supplied xacml:Function, and the results were combined using
>>   'urn:oasis:names:tc:xacml:1.0:function:and'." Under the example, the
>>   text should read "This expression is 'True' because each of the
>>   elements of the first bag is greater than at least one of the
>>   elements of the second bag."
>
> I'm pretty sure I'm okay with this.

Thanks. The old text, I think, was actually copy-pasted from 
all-of-all, which was part of my original confusion.

>>   any-of-all: The second sentence should read "The expression SHALL be
>>   'True' if and only if the supplied predicate is 'True' between each
>>   element of the second bag and any element of the first bag." Also,
>>   starting on line 4651 with the sentence "The expression SHALL be
>>   evaluated", the remaining text in the paragraph should be removed. 
>> In
>>   its place should be the following: "The expression SHALL be 
>> evaluated
>>   as if the 'urn:oasis:names:tc:xacml:1.0:function:any-of' function 
>> was
>>   applied to each value of the second bag and the whole first bag 
>> using
>>   the supplied xacml:Function, and the results were combined using
>>   'urn:oasis:names:tc:xacml:1.0:function:and'." Under the example, the
>>   text should read "This expression is 'True' because for all of the
>>   values in the second bag, there is a value in the first bag that is
>>   greater."
>
> I'm pretty sure I'm okay with this, as well.

Thanks


seth



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