On Wed, 2011-01-12 at 10:14 -0500, ext Richard L. Barnes wrote:
> Good question! Here's my opinion, by no means authoritative:
>
for me, you are authoritative enough...
> Short answer: TRUE.
>
agreed, clearly the better option.
> Mathematical answer:
> As one of my university math professors used to say, "Anything is true for every member of the empty set". What the <conditions> element does logically is specify a set of propositions for which the conjunction (AND) must be true in order to grant permission. So
> <conditions><P1/><P2/> ... </conditions>
> is the same as the formal proposition
> P1 && P2 && ...
> Then you can note that TRUE && X == X for any X, in which case the above becomes:
> TRUE && P1 && P2 && ...
> So when you take all the individual propositions out of the <conditions> element, you're left with:
> TRUE
>
ok, i don't recall anymore if my prof tried to teach this sort of
math ;-)
But a programmatic way, if m means matching:
m = TRUE
if (P1 != TRUE || P2 != TRUE ...)
m = FALSE
if (m)
<actions/>
And the alternative simpler interpretation:
if (P1 == TRUE || P2 == TRUE ...)
<actions/>
would lead to no match with empty set.
But I'm perfectly fine with the "default" being TRUE.
And since the schema also allows to leave out <conditions> element
altogether, this same unconditional TRUE match also applies then, i
suppose.
> Linguistic answer:
> The <conditions> element specifies "conditions" on the grant of permission described in the <actions> <transformations> elements, in the sense that it limits the scope of that permission. So a permission with an empty <conditions> element grants "unconditional" access.
>
> Practical answer:
> A rule with a <conditions> element that always evaluates to FALSE would be useless. You might as well delete it. (If you want a way to temporarily invalidate a rule, you could, for instance, insert a validity time in the past.)
>
> --Richard
>
Right, FALSE default would be no-op. TRUE is a simple way of giving
default policy which applies always (though it can easily be done e.g.
with <identity/> constraint)
I still re-read the spec, and couldn't digest this "self-evident" rule.
So after the sentence in section 6: "If all of the expressions evaluate
to TRUE, then the rule is applicable to this request."
"If there are no expression constraints, i.e. the <conditions> element
is missing or it has no child elements, the rule is also applicable to
this request."
or something similar. It might be good to add this as errdata since i'm
pretty certain this can be seen in iop tests.
thanks, Jari
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
