Re: (ITS#7307) Inconsistent "!" evaluation

[michael@stroeder.com]

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.