As per https://tools.ietf.org/html/rfc4512#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.
That means the top object class will always be there.
Or is it that only the most subordinate object class in the multivalued attribute is considered by the client and server?
On Sun, Apr 19, 2015 at 11:42:16AM +0530, dE wrote:
As per https://tools.ietf.org/html/rfc4512#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.
That means the top object class will always be there.
Basically correct. Note "implicitly" means it's treated as present, even if the entry doesn't actually contain "objectClass: top".
Or is it that only the most subordinate object class in the multivalued attribute is considered by the client and server?
The following facts may answer your question:
- every entry satisfies the filter "(objectClass=top)".
- an entry with "objectClass: inetOrgPerson" satisfies the filter "(objectClass=person)".
On 04/20/15 00:59, Ryan Tandy wrote:
On Sun, Apr 19, 2015 at 11:42:16AM +0530, dE wrote:
As per https://tools.ietf.org/html/rfc4512#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.
That means the top object class will always be there.
Basically correct. Note "implicitly" means it's treated as present, even if the entry doesn't actually contain "objectClass: top".
Or is it that only the most subordinate object class in the multivalued attribute is considered by the client and server?
The following facts may answer your question:
every entry satisfies the filter "(objectClass=top)".
an entry with "objectClass: inetOrgPerson" satisfies the filter
"(objectClass=person)".
I'm concerned about the attributes. Does adding of the top object class (or person) add all attributes to the entry?
--On Monday, April 20, 2015 12:06 PM +0530 dE de.techno@gmail.com wrote:
I'm concerned about the attributes. Does adding of the top object class (or person) add all attributes to the entry?
No. Look up the difference between "MUST" and "MAY". It means it is *possible* to set any of the attributes in an entry, with a value. MUST attributes are required, MAY are optional.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 04/20/15 22:10, Quanah Gibson-Mount wrote:
--On Monday, April 20, 2015 12:06 PM +0530 dE de.techno@gmail.com wrote:
I'm concerned about the attributes. Does adding of the top object class (or person) add all attributes to the entry?
No. Look up the difference between "MUST" and "MAY". It means it is *possible* to set any of the attributes in an entry, with a value. MUST attributes are required, MAY are optional.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
Ok, so you can add attributes which are not included in the 'MAY' of the most subordinate object class the entry belongs to.
dE wrote:
On 04/20/15 22:10, Quanah Gibson-Mount wrote:
--On Monday, April 20, 2015 12:06 PM +0530 dE de.techno@gmail.com wrote:
I'm concerned about the attributes. Does adding of the top object class (or person) add all attributes to the entry?
No. Look up the difference between "MUST" and "MAY". It means it is *possible* to set any of the attributes in an entry, with a value. MUST attributes are required, MAY are optional.
Ok, so you can add attributes which are not included in the 'MAY' of the most subordinate object class the entry belongs to.
Location in the objectclass hierarchy is irrelevant here. You can add attributes that are included in the MUST or MAY of *any* of the classes associated with the object. An object can only have one governing structural object class, but can have arbitrarily many auxiliary object classes, as limited by any DIT content rules that may be in effect for that structural class.
Most LDAP deployments don't use DIT content rules, so there are usually no limits on which auxiliary classes may be used.
Howard Chu wrote:
Most LDAP deployments don't use DIT content rules,
I doubt this statement is true given that MS Active Directory makes heavy use of DIT content rules.
so there are usually no limits on which auxiliary classes may be used.
A schema-aware LDAP client not capable of dealing with DIT content rules cannot do any meaningful with MS AD.
Ciao, Michael.
On 04/26/15 10:46, Howard Chu wrote:
dE wrote:
On 04/20/15 22:10, Quanah Gibson-Mount wrote:
--On Monday, April 20, 2015 12:06 PM +0530 dE de.techno@gmail.com wrote:
I'm concerned about the attributes. Does adding of the top object class (or person) add all attributes to the entry?
No. Look up the difference between "MUST" and "MAY". It means it is *possible* to set any of the attributes in an entry, with a value. MUST attributes are required, MAY are optional.
Ok, so you can add attributes which are not included in the 'MAY' of the most subordinate object class the entry belongs to.
Location in the objectclass hierarchy is irrelevant here. You can add attributes that are included in the MUST or MAY of *any* of the classes associated with the object.
And *any* includes all object classes in the superclass chain of the object classes the entry explicitly belongs to?
On Mon, Apr 20, 2015 at 11:06:07AM +0530, dE wrote:
I'm concerned about the attributes. Does adding of the top object class (or person) add all attributes to the entry?
No. 'top' is defined in RFC4512:
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
so every entry MUST contain an objectclass attribute. It does not say anything about any other attributes.
In any case, objectclasses do not directly add attributes to entries. They do permit (MAY) or require (MUST) certain attributes. It is up to the user or application to supply values for MUST attributes and for any MAY attributes that you want to use. LDAP does not support 'present but empty' attributes, so there must be a non-null value in each MUST attribute.
Andrew
On 04/21/15 15:36, Andrew Findlay wrote:
On Mon, Apr 20, 2015 at 11:06:07AM +0530, dE wrote:
I'm concerned about the attributes. Does adding of the top object class (or person) add all attributes to the entry?
No. 'top' is defined in RFC4512:
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
so every entry MUST contain an objectclass attribute. It does not say anything about any other attributes.
Yeah, so that's the question, can any attribute which is in the MAY of the top object class be added to any entry in the DIT regardless of what object class it belongs to?
On Tue, Apr 28, 2015 at 10:21:25AM +0530, dE wrote:
No. 'top' is defined in RFC4512:
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
so every entry MUST contain an objectclass attribute. It does not say anything about any other attributes.
Yeah, so that's the question, can any attribute which is in the MAY of the top object class be added to any entry in the DIT regardless of what object class it belongs to?
The top object class does not have any MAY attributes. If it did then yes you could use them in any entry in the DIT as all normal entries are members of top.
Andrew
On 04/19/15 11:42, dE wrote:
As per https://tools.ietf.org/html/rfc4512#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.
That means the top object class will always be there.
Or is it that only the most subordinate object class in the multivalued attribute is considered by the client and server?
Ok.
It appears that I've some other confusion.
Starting a new discussion about that.
openldap-technical@openldap.org
-
Andrew Findlay -
dE -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ryan Tandy