RE: Filter Items and Absent Attributes

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Kurt,

I'd just like to make two points.

Firstly, X.500 haven't changed the rules. I've always worked from the 2nd
edition (1993) and found no ambiguity in the specification of filter
handling. The note in the 4th edition may have been a clarification for
those who missed the power of the logic.

The second one relates to (foo=*). In X.500, this would be converted to
foo:present, which is not UNDEFINED when the attribute is not in the entry.
However, LDAPv3, or some implementations, I'm not sure which, allows the
passing of '*' in a filter. In this case, a strict application of the X.500
rules would result in UNDEFINED. (Although the X.500 rules would then
require you to find '*' in each entry!) X.500 gateways would be expected to
convert this filter to foo:present and so they would operate correctly.

Therefore, I see no problems for anyone correctly implementing the X.500
standards.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, 27 February 2002 6:12
To: steven.legg@adacel.com.au
Cc: ietf-ldapbis@OpenLDAP.org
Subject: Re: Filter Items and Absent Attributes


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