Re: (ITS#5517) add superclass of existing class fails

[Kurt@OpenLDAP.org]

On May 24, 2008, at 2:37 PM, h.b.furuseth@usit.uio.no wrote:

> ando@sys-net.it writes:
>> The issue right now is caused by the fact that comparing present
>> values with the asserted one causes objectSubClassMatch() to check  
>> for
>> match including superiors.
>
> This looks like a bug to me.

Maybe in the RFCs.

> objectClass has EQUALITY matching rule
> objectIdentifierMatch, which does not follow the object class
> inheritance chain.

Yes, but objectClass is quite special (despite being a  
userApplications attribute).

For instance, (objectClass=*) is to match DSEs which don't have an  
objectClass attribute.
Likewise, objectClass=foo can match objectClass attributes which don't  
explicitly contain foo.

> See RFC 4517 section 4.2.26.  RFC 4512 section 3.3
> (the 'objectClass' attribute) does not special-case this.
>
> What makes slapd work is that it also disobeys RFC 4512 section 3.3:
>   "When creating an entry or adding an 'objectClass' value to an  
> entry,
>   all superclasses of the named classes SHALL be implicitly added as
>   well if not already present."

> This doesn't say the classes shall be considered to be implicitly
> present, like slapd does.

You are reading 3.3 as if it said "SHALL be added (by the server)".   
It doesn't say "SHALL be added (by the server).  It says "SHALL be  
implicitly added" (presumedly by the server).

This was discussed during LDAPbis discussions.  As the Editor of RFC  
4512, I can say that it was my intent to allow servers to merely treat  
superclasses as being present.

> Instead slapd should add the missing classes to the actual object,

Doing so is problematic.  A client which adds B then deletes B would  
be surprised by non-net-zero result of the operation(s).

> just like it adds some other attribute/values
> implicitly (createTimestamp, subschemaSubentry, etc).

These are operational attributes.  ObjectClass is an userApplications  
attribute.  Servers should not muck with the values of userApplication  
attributes.

> I don't know what to do about it now though.  Will replication work
> between current servers and servers which obeys the RFCs? Is this a  
> RE25
> fix, so we should stay with fixed like previously suggested in  
> RE24?  Or
> yet another thing to do with the last RE23, for the sake of  
> replication?
>
> -- 
> Hallvard
>
>