Filter Items and Absent Attributes

["Steven Legg" <steven.legg@adacel.com.au>]

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