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