Re: slapd.oc.conf /slapd.at.conf

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

At 09:06 AM 8/17/00 +0200, Mikael Grehn wrote:
>When I fill my entry with data , distinguished name e.t.c. + linked list
>of attributes I (earlier) did not set the syntax for each attribute. This
>caused the test_filter to fail even thou is was obvious that the entry
>should be sent back to client.

Obvious to you, but not to test_filter.  The test_filter operates
based upon schema.  If you fail to provide schema, you get what
you deserve... limited functionality.

>I check this out I noticed that the
>default value for the syntax was NOT CIS but binary value (or no valid
>value at all).

First, please don't confuse ";binary" transfer (which is not a
syntax) with the binary syntax with the void syntax.

Second, the frontend allows the backend to return "undefined"
attributes types.  These are constructed as subtypes of an
attribute type which has void syntax and no matching rules.
The void syntax has the property that no value is valid per
the syntax.  These properties, by design, disallow wide use
of "undefined" attribute types as "undefined" attributes
were only meant to return attributes when a backend might have
stored with are no longer defined in the schema while preventing
all other uses (as use without schema cannot be defined).

>Inside the test_filter function there is a check if syntax
>is different from binary.

Actually, I think you are referring to the check for ';binary'
transfer of the values.

>If it is binary the filter always fails (for
>"begins with" filter for example, not "equals" which works).

Yes.  We don't decode values, such as certificates, transferred
using ';binary'.  We do, however, support equality matching
of such values via octetStringMatch.

>Shouldn't the syntax be set to CIS as default?

No.

>Why is there a binary check for "xxx*", "*xxx","*xxx*" filters (with
>wildcard(s)),ie. why does the test_filter function fail for these filters
>if data is binary?

Because the value is a BLOB.