Re: (&) [was: Re: Linux Perl LDAP <-> MS2K NTDS]

[Chris R. <chr...@ma...>]

On 10/1/03 8:14 pm, Kurt D. Zeilenga <Ku...@Op...> wrote:

> At 01:51 AM 1/10/2003, Chris Ridd wrote:
>> I don't think that's a valid search filter in LDAP (you can empty '&'
>> filters in DAP if I recall),
> 
> LDAPv2 actually allowed empty AND/OR sets on the wire
> yet the LDAPv2 filter string representation was
> defined such that one element was required.  When
> LDAPv3 was defined, instead of correcting the string
> representation to allow empty sets, a restriction
> was placed upon the protocol.  This is unfortunate
> as now clients have no standard way to assert absolute
> truth or absolute false.

I hadn't looked as far back as LDAPv2 :-)

You're right though, there does sometimes need to be a way to have a filter
which is always true or false.

>> Try a filter of "(objectclass=*)" instead, as this will normally match every
>> entry.
> 
> Yes, ***normally***.  There are cases where (objectClass=*)
> may evaluate to False (or Undefined and, hence, treated as
> False).

Indeed. Access controls might prevent the filter match, there may not *be*
an objectclass in the object (like in a DSE), that kind of thing.

> A number of LDAP servers however do support assertions
> with empty AND/OR sets.  For example, OpenLDAP 2.1.
> Because this feature is considered generally useful, I've
> written draft-zeilenga-ldap-t-f to (re)introduce them
> back into LDAP as an extension.

Obviously the string representation of search filters document needs
updating too; the BNF I posted from 2252 doesn't permit empty AND/OR sets
(ie filterlist = 1*filter)

Cheers,

Chris