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

[h.b.furuseth@usit.uio.no]

(I seem to be arguing myself into two different corners here, but
anyway...)

Kurt@OpenLDAP.org writes:
>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.

Yes, to my eyes it cleary says what you say was not intended.

>> 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).

Hpmh.  Not very, according to RFCs 4511-12.  Maybe we all "knew" it so
well that we never noticed, during several IETF WGs.

> For instance, (objectClass=*) is to match DSEs which don't have an
> objectClass attribute.

That's explicitly mentioned in RFC 4512 for the root DSE, as is the
(objectClass=subschema) special case.

Section RFC 4512 section 3.3 says each entry in the DIT has an
'objectClass' attribute.  Are other DSEs not in the DIT?

There is RFC 4511 section 4.5.1 (Search Request)'s statement that List
and Read operations can be emulated with a search for (objectClass=*).
Nowhere else can I find that (objectClass=*) is special.

> Likewise, objectClass=foo can match objectClass attributes which
> don't explicitly contain foo.

Not according what the RFCs say to my eyes, (below):

>> 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).

I don't see how that changes anything, but then I'm not a native English
speaker.

> 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.

Hard do argue with that.  I couldn't find these discussions though.  Do
you remember where/when?  All I found was this, which seems to imply the
opposite:
  http://www.openldap.org/lists/ietf-ldapbis/200403/msg00023.html

>> 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).

Clients will be surprised anyway.  Currently clients are being
surprised when (objectClass=A) matches even though A is absent.

And when they add the absent A and that fails, but we can fix that.

>> 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.

Well, it does when it adds missing naming attributes (since RFC4511,
ITS#5412).  I guess that is a better example.  And it "mucks with"
objectClass in a different way anyway, as you've just pointed out.

-- 
Hallvard