According to RFC 4512
An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with the structural object class of the entry.
From what I understand, this means auxiliary classes do not 'augment'; the no. of attributes which are possible in an entry must be a subset of the structural object class the entry belongs to.
dE wrote:
According to RFC 4512
An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with the structural object class of the entry.
From what I understand, this means auxiliary classes do not 'augment'; the no. of attributes which are possible in an entry must be a subset of the structural object class the entry belongs to.
You have completely ignored "DIT content rule" in the quoted sentence.
On 04/15/15 19:31, Howard Chu wrote:
dE wrote:
According to RFC 4512
An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with the structural object class of the entry.
From what I understand, this means auxiliary classes do not 'augment'; the no. of attributes which are possible in an entry must be a subset of the structural object class the entry belongs to.
You have completely ignored "DIT content rule" in the quoted sentence.
But it says "DIT content rule associated with the structural object class of the entry"
dE wrote:
On 04/15/15 19:31, Howard Chu wrote:
dE wrote:
According to RFC 4512
An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with the structural object class of the entry.
From what I understand, this means auxiliary classes do not 'augment'; the no. of attributes which are possible in an entry must be a subset of the structural object class the entry belongs to.
You have completely ignored "DIT content rule" in the quoted sentence.
But it says "DIT content rule associated with the structural object class of the entry"
A DIT content rule is always associated with exactly one structural object class (by having the same OID). This does not say anything about the use of auxiliary object classes within the same entry.
Could you please come up with a concrete example to better explain your question.
Ciao, Michael.
On 04/18/15 03:24, Michael Ströder wrote:
dE wrote:
On 04/15/15 19:31, Howard Chu wrote:
dE wrote:
According to RFC 4512
An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with the structural object class of the entry.
From what I understand, this means auxiliary classes do not 'augment'; the no. of attributes which are possible in an entry must be a subset of the structural object class the entry belongs to.
You have completely ignored "DIT content rule" in the quoted sentence.
But it says "DIT content rule associated with the structural object class of the entry"
A DIT content rule is always associated with exactly one structural object class (by having the same OID). This does not say anything about the use of auxiliary object classes within the same entry.
Could you please come up with a concrete example to better explain your question.
Ciao, Michael.
Ok, I'll assume that as the right thing. So an Auxiliary object class which an entry belongs to (apart from a structural one) can be a subset of any other structural object class. Thanks for clarifying.
What I understand from the RFC text is that for e.g. there's a structural object class B and an auxiliary object class A for an object O; then O can only belong to A only if A is a subset of B, that's why we have
"allowed by the DIT content rule *associated with* the structural object class *of the entry*"
dE wrote:
On 04/18/15 03:24, Michael Ströder wrote:
dE wrote:
On 04/15/15 19:31, Howard Chu wrote:
dE wrote:
According to RFC 4512
An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with the structural object class of the entry.
From what I understand, this means auxiliary classes do not 'augment'; the no. of attributes which are possible in an entry must be a subset of the structural object class the entry belongs to.
You have completely ignored "DIT content rule" in the quoted sentence.
But it says "DIT content rule associated with the structural object class of the entry"
A DIT content rule is always associated with exactly one structural object class (by having the same OID). This does not say anything about the use of auxiliary object classes within the same entry.
Could you please come up with a concrete example to better explain your question.
Ok, I'll assume that as the right thing. So an Auxiliary object class which an entry belongs to (apart from a structural one) can be a subset of any other structural object class. Thanks for clarifying.
What I understand from the RFC text is that for e.g. there's a structural object class B and an auxiliary object class A for an object O; then O can only belong to A only if A is a subset of B, that's why we have
"allowed by the DIT content rule *associated with* the structural object class *of the entry*"
Please define what you understand by "is a subset of"? Are you talking about sets of possible attributes?
See diagram of all schema elements: http://www.stroeder.com/img/LDAP_Schema_References.png
Ciao, Michael.
On 04/20/15 01:44, Michael Ströder wrote:
dE wrote:
On 04/18/15 03:24, Michael Ströder wrote:
dE wrote:
On 04/15/15 19:31, Howard Chu wrote:
dE wrote:
According to RFC 4512
An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with the structural object class of the entry.
From what I understand, this means auxiliary classes do not 'augment'; the no. of attributes which are possible in an entry must be a subset of the structural object class the entry belongs to.
You have completely ignored "DIT content rule" in the quoted sentence.
But it says "DIT content rule associated with the structural object class of the entry"
A DIT content rule is always associated with exactly one structural object class (by having the same OID). This does not say anything about the use of auxiliary object classes within the same entry.
Could you please come up with a concrete example to better explain your question.
Ok, I'll assume that as the right thing. So an Auxiliary object class which an entry belongs to (apart from a structural one) can be a subset of any other structural object class. Thanks for clarifying.
What I understand from the RFC text is that for e.g. there's a structural object class B and an auxiliary object class A for an object O; then O can only belong to A only if A is a subset of B, that's why we have
"allowed by the DIT content rule *associated with* the structural object class *of the entry*"
Please define what you understand by "is a subset of"? Are you talking about sets of possible attributes?
See diagram of all schema elements: http://www.stroeder.com/img/LDAP_Schema_References.png
Ciao, Michael.
Yes.
dE wrote:
According to RFC 4512
An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with the structural object class of the entry.
From what I understand, this means auxiliary classes do not 'augment'; the no. of attributes which are possible in an entry must be a subset of the structural object class the entry belongs to.
You're mixing two things here: - Auxiliary object classes - DIT content rules
Basically auxiliary object classes do augment the set of attributes usable in an entry. That's what they are for.
DIT content rules can limit the set of auxiliary object classes with AUX.
You might want to have a look at the diagram (slide 14) herein which shows the relations between the various subschema descriptions:
http://www.stroeder.com/publications.shtml#ldapcon2013
Bug: Unfortunately the SUP loop link for attribute types is missing...
Ciao, Michael.
--On Wednesday, April 15, 2015 10:02 AM +0530 dE de.techno@gmail.com wrote:
According to RFC 4512
AUX oC's are of invaluable use.
--Quanah
--
Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-technical@openldap.org
-
dE -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount