[Date Prev][Date Next]
Re: (ITS#5517) add superclass of existing class fails
On Jun 5, 2008, at 6:31 AM, email@example.com 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.