11:12 p.m.
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?
12:29 p.m.
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)".
10:36 p.m.
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?
9:40 a.m.
--On Monday, April 20, 2015 12:06 PM +0530 dE <de.techno(a)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
5:30 a.m.
On 04/20/15 22:10, Quanah Gibson-Mount wrote:
--On Monday, April 20, 2015 12:06 PM +0530 dE
<de.techno(a)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.
10:16 p.m.
dE wrote:
On 04/20/15 22:10, Quanah Gibson-Mount wrote:
> --On Monday, April 20, 2015 12:06 PM +0530 dE <de.techno(a)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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:59 a.m.
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.
3:22 a.m.
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(a)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?
3:06 a.m.
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
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
9:51 p.m.
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?
2:23 a.m.
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
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------
10:06 p.m.
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.
3138
days inactive
3147
days old
openldap-technical@openldap.org
11 comments
6 participants
participants (6)
-
Andrew Findlay -
dE -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ryan Tandy