On 04/20/15 22:56, Michael Ströder wrote:
dE wrote:
Does adding of the top object class (or person) add all attributes to the entry?
Nope. Which text in RFC 4512 leads to your presumption?
Ciao, Michael.
Sorry for the late response. I was out of town.
From the responses, it appears the question has not been understood correctly, I what I meant to ask was --
Does adding of the top object class (implicitly) make it possible to add all attributes in the DIT to the entry? I'm talking about attributes which are out of the 'MAY' in the most subordinate object class the entry belong to.
dE wrote:
On 04/20/15 22:56, Michael Ströder wrote:
dE wrote:
Does adding of the top object class (or person) add all attributes to the entry?
Nope. Which text in RFC 4512 leads to your presumption?
Sorry for the late response. I was out of town.
From the responses, it appears the question has not been understood correctly,
Yes, very likely. But maybe you also did not understand the responses?
Does adding of the top object class (implicitly) make it possible to add all attributes in the DIT to the entry?
No.
Please read RFC 4512 more closely.
You could also read some source code, e.g. method SubSchema.attribute_types() herein:
http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ld...
Ciao, Michael.
On 04/26/15 15:27, Michael Ströder wrote:
dE wrote:
On 04/20/15 22:56, Michael Ströder wrote:
dE wrote:
Does adding of the top object class (or person) add all attributes to the entry?
Nope. Which text in RFC 4512 leads to your presumption?
Sorry for the late response. I was out of town.
From the responses, it appears the question has not been understood correctly,
Yes, very likely. But maybe you also did not understand the responses?
Does adding of the top object class (implicitly) make it possible to add all attributes in the DIT to the entry?
No.
Please read RFC 4512 more closely.
You could also read some source code, e.g. method SubSchema.attribute_types() herein:
http://python-ldap.cvs.sourceforge.net/viewvc/python-ldap/python-ldap/Lib/ld...
Ciao, Michael.
Ok, then that makes it clear. Thank you for clearing that.
Super this is the superclass chain --
A->B
A is defined by MUST ObjectClass MAY ( cn abc xyz cxy ) B is defined by MUST ObjectClass MAY ( cn cxy )
Then an entry belonging to B (explicit) and A (implicit, automatically added) cannot have attributes abc and xyz.
dE wrote:
Super this is the superclass chain --
A->B
A is defined by MUST ObjectClass MAY ( cn abc xyz cxy ) B is defined by MUST ObjectClass MAY ( cn cxy )
Then an entry belonging to B (explicit) and A (implicit, automatically added) cannot have attributes abc and xyz.
No!
B would have MAY ( cn abc xyz cxy ).
Example for A:
objectclass ( <some-oid-for-A> NAME 'A' MAY ( cn $ abc $ xyz $ cxy ) )
These three variants have the same MAY attribute set ( cn $ abc $ xyz $ cxy ):
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ abc $ xyz $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A )
Ciao, Michael.
On 04/26/15 17:13, Michael Ströder wrote:
dE wrote:
Super this is the superclass chain --
A->B
A is defined by MUST ObjectClass MAY ( cn abc xyz cxy ) B is defined by MUST ObjectClass MAY ( cn cxy )
Then an entry belonging to B (explicit) and A (implicit, automatically added) cannot have attributes abc and xyz.
No!
B would have MAY ( cn abc xyz cxy ).
Example for A:
objectclass ( <some-oid-for-A> NAME 'A' MAY ( cn $ abc $ xyz $ cxy ) )
These three variants have the same MAY attribute set ( cn $ abc $ xyz $ cxy ):
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ abc $ xyz $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A )
Ciao, Michael.
Ok.
So the significance of subordinate classes is to add a MUST attributes only. The possible attributes that any object can have is defined in the TOP object class; regardless of what object class the entry belongs to, any attribute listed in the TOP object class can be added to it.
dE wrote:
On 04/26/15 17:13, Michael Ströder wrote:
dE wrote:
Super this is the superclass chain --
A->B
A is defined by MUST ObjectClass MAY ( cn abc xyz cxy ) B is defined by MUST ObjectClass MAY ( cn cxy )
Then an entry belonging to B (explicit) and A (implicit, automatically added) cannot have attributes abc and xyz.
No!
B would have MAY ( cn abc xyz cxy ).
Example for A:
objectclass ( <some-oid-for-A> NAME 'A' MAY ( cn $ abc $ xyz $ cxy ) )
These three variants have the same MAY attribute set ( cn $ abc $ xyz $ cxy ):
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ abc $ xyz $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A )
Ok.
So the significance of subordinate classes is to add a MUST attributes only.
No! Which text in RFC 4512 says that?
Also I don't understand what the term "significance of subordinate classes" means to you in this context.
The possible attributes that any object can have is defined in the TOP object class;
No!
regardless of what object class the entry belongs to, any attribute listed in the TOP object class can be added to it.
You should really read RFC 4512 more carefully and look at existing subschema. I give up now to explain.
Ciao, Michael.
Am Sonntag, 26. April 2015 20:07 CEST, Michael Ströder michael@stroeder.com schrieb:
Also I don't understand what the term "significance of subordinate classes" means to you in this context.
Yes. Might it be possible that dE (miss)reads 'SUB' as 'subprdinate' when it actually means 'subclass'? When talking about LDAP the term 'subordinate' does have a well defined meaning (that is irrelevant to this discussion).
The possible attributes that any object can have is defined in the TOP object class;
No!
regardless of what object class the entry belongs to, any attribute listed in the TOP object class can be added to it.
Hmm - but while this might be true it's a tautology. Given:
objectclass ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
What attributes of 'TOP' are you talking about? ;-)
You should really read RFC 4512 more carefully and look at existing subschema. I give up now to explain.
May I humbly reading suggest http://www.zytrax.com/books/ldap/ch3/
Cheers, RalfD
On Apr 26, 2015, at 12:45 PM, Mattes rm@mh-freiburg.de wrote:
Am Sonntag, 26. April 2015 20:07 CEST, Michael Ströder michael@stroeder.com schrieb:
Also I don't understand what the term "significance of subordinate classes" means to you in this context.
Yes. Might it be possible that dE (miss)reads 'SUB' as 'subprdinate' when it actually means 'subclass'? When talking about LDAP the term 'subordinate' does have a well defined meaning (that is irrelevant to this discussion).
The possible attributes that any object can have is defined in the TOP object class;
No!
regardless of what object class the entry belongs to, any attribute listed in the TOP object class can be added to it.
Hmm - but while this might be true it's a tautology. Given:
objectclass ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
What attributes of 'TOP' are you talking about? ;-
objectClass, clearly.
You should really read RFC 4512 more carefully and look at existing subschema. I give up now to explain.
May I humbly reading suggest http://www.zytrax.com/books/ldap/ch3/
Zytrax should be avoided. Besides engaging in blatant illegal plagiarism, they often have completely erroneous information.
--Quanah
On 04/27/15 06:10, Quanah Gibson-Mount wrote:
On Apr 26, 2015, at 12:45 PM, Mattes rm@mh-freiburg.de wrote:
Am Sonntag, 26. April 2015 20:07 CEST, Michael Ströder michael@stroeder.com schrieb:
Also I don't understand what the term "significance of subordinate classes" means to you in this context.
Yes. Might it be possible that dE (miss)reads 'SUB' as 'subprdinate' when it actually means 'subclass'? When talking about LDAP the term 'subordinate' does have a well defined meaning (that is irrelevant to this discussion).
The possible attributes that any object can have is defined in the TOP object class;
No!
regardless of what object class the entry belongs to, any attribute listed in the TOP object class can be added to it.
Hmm - but while this might be true it's a tautology. Given:
objectclass ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
What attributes of 'TOP' are you talking about? ;-
objectClass, clearly.
No. Everything else.
You should really read RFC 4512 more carefully and look at existing subschema. I give up now to explain.
May I humbly reading suggest http://www.zytrax.com/books/ldap/ch3/
Zytrax should be avoided. Besides engaging in blatant illegal plagiarism, they often have completely erroneous information.
--Quanah
--On Tuesday, April 28, 2015 10:56 AM +0530 dE de.techno@gmail.com wrote:
objectclass ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
What attributes of 'TOP' are you talking about? ;-
objectClass, clearly.
No. Everything else.
You are clearly confused. There *is* no everything else for the "top" objectclass. It defines one and only one attribute that MUST be present.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 04/27/15 01:13, Mattes wrote:
Am Sonntag, 26. April 2015 20:07 CEST, Michael Ströder michael@stroeder.com schrieb:
Also I don't understand what the term "significance of subordinate classes" means to you in this context.
Yes. Might it be possible that dE (miss)reads 'SUB' as 'subprdinate' when it actually means 'subclass'? When talking about LDAP the term 'subordinate' does have a well defined meaning (that is irrelevant to this discussion).
Actually I meant subclass.
The possible attributes that any object can have is defined in the TOP object class;
No!
regardless of what object class the entry belongs to, any attribute listed in the TOP object class can be added to it.
Hmm - but while this might be true it's a tautology. Given:
objectclass ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
What attributes of 'TOP' are you talking about? ;-)
All MAY attributes. Of course the MUST must be there, but from what I understand all MAY attributes in top can also be added regardless of what subclass the entry belongs to.
You should really read RFC 4512 more carefully and look at existing subschema. I give up now to explain.
May I humbly reading suggest http://www.zytrax.com/books/ldap/ch3/
Cheers, RalfD
What that book says is different from what the RFC says. besides I'm interested in reading the latest RFC.
On 04/26/15 23:37, Michael Ströder wrote:
dE wrote:
On 04/26/15 17:13, Michael Ströder wrote:
dE wrote:
Super this is the superclass chain --
A->B
A is defined by MUST ObjectClass MAY ( cn abc xyz cxy ) B is defined by MUST ObjectClass MAY ( cn cxy )
Then an entry belonging to B (explicit) and A (implicit, automatically added) cannot have attributes abc and xyz.
No!
B would have MAY ( cn abc xyz cxy ).
Example for A:
objectclass ( <some-oid-for-A> NAME 'A' MAY ( cn $ abc $ xyz $ cxy ) )
These three variants have the same MAY attribute set ( cn $ abc $ xyz $ cxy ):
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ abc $ xyz $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A )
Ok.
So the significance of subordinate classes is to add a MUST attributes only.
No! Which text in RFC 4512 says that?
It's implied from
When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added
Also I don't understand what the term "significance of subordinate classes" means to you in this context.
I mean object classes subordinate to the TOP object class.
The possible attributes that any object can have is defined in the TOP object class;
No!
But that's what you said.
These three variants have the same MAY attribute set ( cn $ abc $ xyz $ cxy ):
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ abc $ xyz $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A )
So entries belonging to object class B can have all attributes of object class A, in a similar way the possible attributes that any object can have is defined by the TOP object class.
regardless of what object class the entry belongs to, any attribute listed in the TOP object class can be added to it.
You should really read RFC 4512 more carefully and look at existing subschema. I give up now to explain.
That's the source of all confusion.
There is no IETF mailing list to discuss these issues.
dE wrote:
On 04/26/15 23:37, Michael Ströder wrote:
You should really read RFC 4512 more carefully and look at existing subschema. I give up now to explain.
That's the source of all confusion.
There is no IETF mailing list to discuss these issues.
General LDAP discussion occurs on ldap@umich.edu
We generally expect you to already know LDAP before coming to the OpenLDAP mailing lists.
Am Sun, 26 Apr 2015 21:05:44 +0530 schrieb dE de.techno@gmail.com:
On 04/26/15 17:13, Michael Ströder wrote:
dE wrote:
Super this is the superclass chain --
A->B
A is defined by MUST ObjectClass MAY ( cn abc xyz cxy ) B is defined by MUST ObjectClass MAY ( cn cxy )
Then an entry belonging to B (explicit) and A (implicit, automatically added) cannot have attributes abc and xyz.
No!
B would have MAY ( cn abc xyz cxy ).
Example for A:
objectclass ( <some-oid-for-A> NAME 'A' MAY ( cn $ abc $ xyz $ cxy ) )
These three variants have the same MAY attribute set ( cn $ abc $ xyz $ cxy ):
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ abc $ xyz $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A )
Ciao, Michael.
Ok.
So the significance of subordinate classes is to add a MUST attributes only. The possible attributes that any object can have is defined in the TOP object class; regardless of what object class the entry belongs to, any attribute listed in the TOP object class can be added to it.
NO! The abstract objectClass 'top' only provides the attribute 'objectClass'. From schema_prep.c
( 2.5.6.0 NAME 'top' " "DESC 'top of the superclass chain' " "ABSTRACT MUST objectClass )",
-Dieter
On 04/27/15 02:07, Dieter Klünter wrote:
Am Sun, 26 Apr 2015 21:05:44 +0530 schrieb dE de.techno@gmail.com:
On 04/26/15 17:13, Michael Ströder wrote:
dE wrote:
Super this is the superclass chain --
A->B
A is defined by MUST ObjectClass MAY ( cn abc xyz cxy ) B is defined by MUST ObjectClass MAY ( cn cxy )
Then an entry belonging to B (explicit) and A (implicit, automatically added) cannot have attributes abc and xyz.
No!
B would have MAY ( cn abc xyz cxy ).
Example for A:
objectclass ( <some-oid-for-A> NAME 'A' MAY ( cn $ abc $ xyz $ cxy ) )
These three variants have the same MAY attribute set ( cn $ abc $ xyz $ cxy ):
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A MAY ( cn $ abc $ xyz $ cxy ) )
objectclass ( <some-oid-for-B> NAME 'B' SUP A )
Ciao, Michael.
Ok.
So the significance of subordinate classes is to add a MUST attributes only. The possible attributes that any object can have is defined in the TOP object class; regardless of what object class the entry belongs to, any attribute listed in the TOP object class can be added to it.
NO! The abstract objectClass 'top' only provides the attribute 'objectClass'. From schema_prep.c
( 2.5.6.0 NAME 'top' " "DESC 'top of the superclass chain' " "ABSTRACT MUST objectClass )",
-Dieter
That's the MUST, I'm talking about the MAY.
On Sat, Apr 25, 2015 at 05:58:43PM +0530, dE wrote:
Does adding of the top object class (implicitly) make it possible to add all attributes in the DIT to the entry? I'm talking about attributes which are out of the 'MAY' in the most subordinate object class the entry belong to.
If you really want to permit *any* attribute to be added to an entry, then you can add the ExtensibleObject objectclass. In general this is a *bad* thing to do. See RFC4512 section 4.3 for the definition.
Andrew
openldap-technical@openldap.org
-
Andrew Findlay -
dE -
Dieter Klünter -
Howard Chu -
Mattes -
Michael Ströder -
Quanah Gibson-Mount