Subject: [Geopriv] empty conditions element in common policy (rfc4745)

From: jari urpalainen <[email-masked]>
Date: Wed, 12 Jan 2011 08:29:53 +0200

Hi !

A clarification question: an empty conditions element without any child
elements evaluates to FALSE or TRUE ?

Section 10.1 says: "A rule matches if all conditions contained as child
elements in the <conditions> element of a rule evaluate to TRUE", which
imo implies FALSE for the "empty" case. The schema allows "empty"
<conditions/>, and e.g. not understood conditions evaluate to FALSE. My
personal programmatic interpretation goes for FALSE, but what's the
correct one ?

br, Jari

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 12 Jan 2011 10:14:02 -0500

Good question!  Here's my opinion, by no means authoritative:

Short answer: TRUE.  

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

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

On Jan 12, 2011, at 1:29 AM, jari urpalainen wrote:

> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Jari Urpalainen <[email-masked]>
Date: Thu, 13 Jan 2011 09:34:49 +0200

Thanks Richard,

> Good question!  Here's my opinion, by no means authoritative:
for me, you are authoritative enough...
 
> Short answer: TRUE.  
agreed, clearly the better option.

> So when you take all the individual propositions out of the <conditions> element, you're left with:
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.

> 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, inse…
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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 13 Jan 2011 10:50:20 -0500

> But a programmatic way, if m means matching: ...

Actually, I was thinking of something like the following:

bool m = true;
for (int i=0; i<conditions.size() && m; ++i) {
    m = m && conditions[i].test();
}

Either way, you have to iterate through the conditions.

> pretty certain this can be seen in iop tests.

I'm not familiar enough with the erratum process to say whether this is appropriate, but I agree that this seems like a good thing to clarify.  It might make sense to write a brief I-D with clarifications to RFC 4745, especially if there are other interop issues.

--Richard

---

From: Jari Urpalainen <[email-masked]>
Date: Fri, 14 Jan 2011 10:29:50 +0200

> I'm not familiar enough with the erratum process to say whether this is appropriate, but I agree that this seems like a good thing to clarify.  It might make sense to write a brief I-D with clarifi…
The errdata process <http://www.rfc-editor.org/errata.php> is imo just
enough, since this is a pretty minor clarification where a one liner fix
will make the intended behavior unambiguous. I don't mind if someone
wants to make a bigger stab on this, but certainly, i'm _not_ proposing
that. Imo, for implementors, errdata is authoritative and fast enough
(instead of referring to some mailing list thread discussion). 

The rfc authors have been silent though...

br Jari