Re: (ITS#4688) Missing objectClass attribute in an ldapsearch

[Kurt@OpenLDAP.org]

At 09:57 AM 9/27/2006, ashish@ratboy.net wrote:
>Full_Name: Ashish Gawarikar
>Version: 2.3.27
>OS: Linux
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (63.211.143.38)
>
>
>The messageStoreRecipient class is a subclass of messageRecipient and hence the
>search succeeds.

As it should.

>But, as per RFC 4512.
>
> 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.

I think you read more into this requirement than the text actually
makes.  It seems you read this text as imparting some requirement
for servers to return all values of this objectClass when requested.
The text does not discuss what should be returned, it discusses
what should be implicitly added.  The quoted requirement should
not read as precluding a server's freedom to restrict the return
of values of this (or any attribute) attribute otherwise granted
in the LDAP Technical Specification.

I note that client developers should not expect a returned
objectclass attribute to be complete.  There are a host of
reasons that some superclass might not be listed.   In
particular, where an LDAP server is returning an entry
provided to it by a DAP-only server (which certainly is not
governed by this SHALL), the LDAP server cannot be expected
to be capable of (even if it new of the classes and their
superclasses) of back filling values.  If the server
behavior is allowed in this case, it must be generally
allowed, as whether the LDAP server is or is not a DAP
gateway is an implementation detail.

>and
>   Servers SHALL restrict modifications of this attribute to prevent
>   superclasses of remaining 'objectClass' values from being deleted.

I believe slapd(8) adhere to this requirement.


>("SHALL" in those sentences denotes an absolute requirement; see
>RFC 2119 for details.)
>
>
># bin/ldapsearch -x "(&(objectClass=messageRecipient)(mailRoutingAddress=admin@mc3.com))"
># extended LDIF
>#
># LDAPv3
># base <> with scope subtree
># filter:
>(&(objectClass=messageRecipient)(mailRoutingAddress=admin@mc3.com))
># requesting: ALL
>#
>
># admin@mc3.com, SysAccounts, mc3.com
>dn: mailRoutingAddress=admin@mc3.com,ou=SysAccounts,dc=mc3,dc=com
>objectClass: top
>objectClass: person
>objectClass: organizationalPerson
>objectClass: inetOrgPerson
>objectClass: extensibleObject
>objectClass: messageStoreRecipient
>mail: admin@mc3.com
>mailRoutingAddress: admin@mc3.com
>mailLocalAddress: admin@mc3.com
>cn: admin
>sn: admin
>description: Admin account
>mailHost: abcd
>userPassword:: e1NTSEF9S2xMMlhvRjVibHBxVlZDYnQrbS9OTEgyME5qckpBZkw=
>
># search result
>search: 2
>result: 0 Success
>
># numResponses: 2
># numEntries: 1
>
>---
># strings slapd | grep OpenLDAP | grep slapd
>@(#) $OpenLDAP: slapd 2.3.27 (Sep 13 2006 07:47:17) $
>---