kurt@OpenLDAP.org wrote:

quanah@zimbra.com wrote:

...

Kurt@OpenLDAP.org wrote:

...

On Jun 14, 2012, at 2:10 PM, quanah@openldap.org wrote:

...

Handling "!" with objectClasses appears to be broken. For example, if I perform the following ldap query:

zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "" '(!(objectclass=junk))'

This result appears incorrect to me. I would expect it to return all entries without that objectClass (which in this case, would be every entry).

which object class (by OID)? If the server doesn't know what junk is (!(objectClass=junk)) is just as undefined (objectclass=junk) is.

So basically the question is: What is the negation of undefined in this context. You're saying undefined and this would mean False.

But I agree with Quanah: I also expect the server to return all entries if object class 'junk' is not in the server's schema. This seems to be canonical behaviour. Various other LDAP server vendors have implemented it like this (tested on OpenDJ).

if the server doesn't know what objectClass (by OID) the descriptor refers to, it doesn't know whether the objectClass is in the schema or not.

The server already evaluates this to "undefined" based on what's in the server's schema. So I don't understand your argument.

'junk', for all the server knows, could refer to the same objectClass the 'top' descriptor refers to.

Why?

...

I don't think it should fail to evaluate.

It evaluates the expression to Undefined, which is exactly the situation. Junk is not defined. To evaluate (objectClass=junk) to true or false requires the server to know exactly what object class 'junk' refers to. It doesn't in this case.

I don't think that in case of negation a server has to mean exactly what object class 'junk' refers to. It has to simply know that none of the existing object classes refer to 'junk'. If 'junk' is not in the server's subschema the negation evaluates to True.

...

Clearly, if none of the objects match the filter, it should return them.

No, that's not clear. junk could be defined as:

( 2.5.6.0 NAME ( 'top' 'junk' ABSTRACT MUST objectClass )

If this object class description is not in the server's schema this argument is not relevant at all.

You are making assumptions regarding how junk is actually defined. The server should not make any assumptions.

Yes, the server should only look in its schema. Still I don't see any true argument why the fact that (objectClass=junk) cannot be true leads to the conclusion that (!(objectClass=junk)) is not true either.

Also, even if junk was defined in the client's schema: ( 1.1.1.1 NAME ( 'junk' 'crap' ) AUXILIARY MUST objectClass )

and the server could easily have in its schema: ( 1.1.1.1 NAME 'crap' AUXILIARY MUST objectClass ) in its schema and lots of entries belonging to this class.

Such a situation is not relevant for this discussion. And IMO there is no such thing like a client's schema (saying this while being the author of a LDAP client which makes the most versatile use of subschema information with a fall-back schema on the client's side).

Ciao, Michael.