Re: Filter Items and Absent Attributes

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

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

At 08:07 PM 2002-02-25, Steven Legg wrote:

>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