Re: slapd 2.0.7 rejects correct filters (ITS#986)

[Kurt@OpenLDAP.org]

At 12:23 AM 1/24/01 +0000, afm@othello.ch wrote:
>slapd 2.0.7 rejects all filters containing the <= or >= operators.

No, it evaluates assertions, including inequality assertions,
to True or False or Undefined.   If there is no ORDERING
matching rule defined for the attribute type, the assertion
evaluates to Undefined as required by RFC 2251.

>There is no indication to the client that the search operation has failed,

The search didn't fail.

>it simply returns nothing.

No, it returned all entries matching the filter.

>(note the missing declaration of the ORDERING matching rule).

The definition of name is taken from RFC 2256.  It should not
be altered.

>Surprisingly
>(to me), no similar problem appears for approximate matching.

Try approximate matching on a attribute type which has no
equality matching rule.

>Is there some
>initialization missing for the sat_ordering field? 

No.

>There are some remaining issues here:
>0. shouldn't there be some default matching rules from which all attribute
>   types inherit, even if no definition is found in the core.schema?

No.

>1. although get_ava concludes that the filter is bad, no ldap error is
>   returned to the client, there should be some inapropriate operation
>   or unwilling to perform error.

The current behavior is believed to be consistent with RFC 2251
and X.511.

>2. the functions prepare error message texts, but it seems they are never
>actually
>   displayed anywhere, or am I missing something?

The error texts are used in other contexts.

>3. how about a function to dump the database of attribute types and object
>   classes after it has been read, so that debugging schema definitions would
>   become eazier? Something like how named reacts to SIGINT.

Use LDAPv3 schema discovery.


>But in any event, please keep up the good work.