Subject: Filter Items and Absent Attributes

From: "Steven Legg" <[email-masked]>
Date: Tue, 26 Feb 2002 15:07:34 +1100

Folks,

A statement that is in the 4th edition of X.511, but not in the 2nd
edition, was recently brought to my attention. I found it surprising.
I suspect I not the only one.

In X.511:2001, Clause 7.8.2:

  "An assertion" ... "evaluates to UNDEFINED if it relates to an attribute
   value and the attribute type is not present in an" [ entry ] "against
   which the assertion is being tested."

This means, for example, that a filter item like (givenName=Bob) evaluates
to UNDEFINED, rather than FALSE, if an entry doesn't have the givenName
attribute. This affects how negated filter items are evaluated.
For example, the filter (!(givenName=Bob)) only returns entries
that have the givenName attribute, but not the givenName value "Bob".
The entries that don't have the givenName attribute are not returned
(giving the impression that they *do* have "Bob" as a givenName).

Apparently this behaviour was the original intention in the 2nd edition
of X.511 as well. It just wasn't explained properly.

Personally, I think returning UNDEFINED instead of FALSE would be
counter-intuitive to most users, and therefore a bad idea.

Does anyone's server implementation evaluate filter items to UNDEFINED
instead of FALSE when the attribute doesn't exist (obviously mine
doesn't) ? The answer determines how I apply access controls to searches
in my I-D on X.500 Basic Access Control for LDAP. The current specification
is based on the assumption that everyone else is returning FALSE too.

If that is the case then we have to decide whether we want to define
LDAP searches to behave exactly like X.500 searches (and change our
implementations), or explicitly specify that LDAP behaves differently,
or influence the X.500 working group to change X.511.

Regards,
Steven

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 26 Feb 2002 11:12:15 -0800

Ugh!

Logically, I understand the distinction being made in the
4th edition.  The problem I see is that most server implementation
likely don't implement it this way and it might be every difficult
for them to change.  Changing the logic of a filter evaluation
routine is likely simple enough, but changing the logic of
indexing supporting filter evaluation would likely be quite
complex.

Briefly (just to indicate why implementations might find it
difficult to implement the 4th edition semantics), if one has
an equality index where AVAs are used as key, the AVA selects
the set of entries which have that AVA is True (or may be True).
For all entries which are not in this set, the filter won't
evaluate to True.  However, the equality index doesn't say
whether it would evaluate to False or Undefined.  For this,
another index (such as for presence) must be used.

I've run into clients which desire the semantics which the
4th edition suggests.  They tend to use (&(foo=*)(foo=bar))
to achieve this as, I believe, most implementations do
not consistently evaluate (foo=bar) as described in the 4th
edition.

I note as well that the 4th edition statement is somewhat
problematic as it implies (not intentionally) that (foo=*)
should be Undefined if the entry doesn't contain the
attribute foo.  RFC 2251, of course, clarifies that (foo=*)
cannot evaluate to Undefined.

Anyways, I think the first thing we need to establish is
whether there are multiple interoperable implementations
of filters as clarified in the 4th Edition.  Ron states
he has one implementation, are there others?

Kurt