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

[Kurt@OpenLDAP.org]

On Jun 5, 2008, at 6:31 AM, h.b.furuseth@usit.uio.no wrote:
> And when they add the absent A and that fails, but we can fix that.

I think the best is option is disallow addition of an unlisted subject  
and disallow the removal of a unlisted subclass (except by replace).   
This will provide more a more consistent and symmetric behavior.

In your initial report, it was this inconsistent and non-symmetric  
behavior that was your most significant concern.

As far as RFC conformance goes, I argue that with this change, the  
behavior would be fully conformant.  No where in the RFCs does it  
require servers to return implicitly added values, no where in the  
RFCs does it preclude servers from removing implicitly added values  
upon removal of values which caused there addition.

The concern I have is impact on clients which add a class and then  
delete that class, expecting it just to work.  But if that class is  
subclass, and the add causes the insertion of some other class, then  
the delete will either leave that other class there or lead to an  
error, both undesirable and unexpected behaviors.

I think the mistake that LDAP designers made (long ago) was not to  
require LDAP CLIENTS to provide all (non-top) classes, as is required  
of DAP clients.

Regarding objectClass being special (especially with regard to its  
equality matching rule): consider (objectClass=top) and X.500 "top may  
be omitted" statement.

-- Kurt