Suppose a name form is attached to a structural object class. Then, when referring to entries belonging to that object class (which has no DIT Structure Rules associated to it), is using the MUST attributes as defined in the name form to construct AVA still necessary?
No DIT Structure Rules refer to this name form.
dE wrote:
Suppose a name form is attached to a structural object class. Then, when referring to entries belonging to that object class (which has no DIT Structure Rules associated to it), is using the MUST attributes as defined in the name form to construct AVA still necessary?
No DIT Structure Rules refer to this name form.
No. Name forms are only used when a DIT Structure Rule references them.
On 2015-04-30 13:37, Howard Chu wrote:
No. Name forms are only used when a DIT Structure Rule references them.
Are you sure? If yes, then please point out what's missing herein:
http://www.stroeder.com/img/LDAP_Schema_References.png
IMO it's the other way round: You cannot use DIT Structure Rules without associated Name Forms.
The governing structure rule might limit the set of possible structural object classes in a part of a DIT but if absent or not applicable you can still limit to possible name form(s) for a chosen structural object class.
Also note that my web2ldap has full support for DIT Structure Rules and Name Forms. I've checked my code: Applicable name forms are determined by the structural object class, nothing else. I'm eager to correct any possible issue in my schema handling.
Ciao, Michael.
Michael Ströder wrote:
On 2015-04-30 13:37, Howard Chu wrote:
No. Name forms are only used when a DIT Structure Rule references them.
Are you sure? If yes, then please point out what's missing herein:
http://www.stroeder.com/img/LDAP_Schema_References.png
IMO it's the other way round: You cannot use DIT Structure Rules without associated Name Forms.
The governing structure rule might limit the set of possible structural object classes in a part of a DIT but if absent or not applicable you can still limit to possible name form(s) for a chosen structural object class.
Also note that my web2ldap has full support for DIT Structure Rules and Name Forms. I've checked my code: Applicable name forms are determined by the structural object class, nothing else. I'm eager to correct any possible issue in my schema handling.
Note that you can define an arbitrary number of name forms for any particular structural objectclass. In the absence of a governing DIT Structure Rule you have no way to select which one is relevant. In reality, none of them are, name forms are only active when a DIT Structure Rule uses them.
Michael Ströder wrote:
On 2015-04-30 13:37, Howard Chu wrote:
No. Name forms are only used when a DIT Structure Rule references them.
Are you sure? If yes, then please point out what's missing herein:
PS: you should read X.501(1993) for the exact text, since LDAP must conform to that spec. Section 12.6.
http://www.itu.int/rec/T-REC-X.501/en
http://www.stroeder.com/img/LDAP_Schema_References.png
IMO it's the other way round:
Your opinion is wrong.
You cannot use DIT Structure Rules without associated Name Forms.
The governing structure rule might limit the set of possible structural object classes in a part of a DIT but if absent or not applicable you can still limit to possible name form(s) for a chosen structural object class.
No, if there are no DIT structure rules then there are no constraints whatsoever on the naming or placement of entries.
Also note that my web2ldap has full support for DIT Structure Rules and Name Forms. I've checked my code: Applicable name forms are determined by the structural object class, nothing else. I'm eager to correct any possible issue in my schema handling.
Ciao, Michael.
Howard Chu wrote:
Michael Ströder wrote:
On 2015-04-30 13:37, Howard Chu wrote:
No. Name forms are only used when a DIT Structure Rule references them.
Are you sure? If yes, then please point out what's missing herein:
PS: you should read X.501(1993) for the exact text, since LDAP must conform to that spec. Section 12.6.
Hmm...
In X.501(1993) and X.501(2010) it is simply assumed that there are *always* DIT structure rules.
From X.501(1993) section 12.6.5 and X.501(2010) section 13.7.5: "Each object and alias entry is governed by a single DIT structure rule"
But there's no text dealing with the LDAP implementation without governing structure rule of an entry.
Also after re-reading X.501 it seems the diagram is correct.
This statement in my former posting is obviously corrent:
"You cannot use DIT Structure Rules without associated Name Forms."
Because connecting the governing with the superior structural rule cannot be done without name forms.
The governing structure rule might limit the set of possible structural object classes in a part of a DIT but if absent or not applicable you can still limit to possible name form(s) for a chosen structural object class.
No, if there are no DIT structure rules then there are no constraints whatsoever on the naming or placement of entries.
I did not find any text in X.501 or RFC 4512 which clearly says that. Especially RFC 4512 makes DIT structure rules optional. Maybe I'm missing something though.
I also vaguely remember having seen RFCs or I-Ds specifying name forms without DIT structure rules. Which of course also is not a sufficient proof that name forms apply without DIT structure rules though.
Please don't get me wrong. I just want to clarify this. Because the truly optional use of DIT structure rules and name forms is a difficult and maybe under-defined topic.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
On 2015-04-30 13:37, Howard Chu wrote:
No. Name forms are only used when a DIT Structure Rule references them.
Are you sure? If yes, then please point out what's missing herein:
PS: you should read X.501(1993) for the exact text, since LDAP must conform to that spec. Section 12.6.
Hmm...
In X.501(1993) and X.501(2010) it is simply assumed that there are *always* DIT structure rules.
From X.501(1993) section 12.6.5 and X.501(2010) section 13.7.5: "Each object and alias entry is governed by a single DIT structure rule"
But there's no text dealing with the LDAP implementation without governing structure rule of an entry.
Name Forms are a component of DIT Structure Rules. If you don't use DIT Structure Rules, then you don't have name forms either.
Also after re-reading X.501 it seems the diagram is correct.
This statement in my former posting is obviously corrent:
"You cannot use DIT Structure Rules without associated Name Forms."
Because connecting the governing with the superior structural rule cannot be done without name forms.
The governing structure rule might limit the set of possible structural object classes in a part of a DIT but if absent or not applicable you can still limit to possible name form(s) for a chosen structural object class.
No, if there are no DIT structure rules then there are no constraints whatsoever on the naming or placement of entries.
I did not find any text in X.501 or RFC 4512 which clearly says that. Especially RFC 4512 makes DIT structure rules optional. Maybe I'm missing something though.
12.6.2
A name form is only a primitive element of the full specification required to constrain the form of the DIT to that required by the administrative and naming authorities that determine the naming policies of a given region of the DIT. The remaining aspects of the specification of DIT structure are discussed in 12.6.5.
12.6.5 defines DIT Structure Rules.
I also vaguely remember having seen RFCs or I-Ds specifying name forms without DIT structure rules. Which of course also is not a sufficient proof that name forms apply without DIT structure rules though.
Please don't get me wrong. I just want to clarify this. Because the truly optional use of DIT structure rules and name forms is a difficult and maybe under-defined topic.
It is completely defined. Name Forms have no meaning on their own. They only have any significance when used in a DIT Structure Rule.
Howard Chu wrote:
Michael Ströder wrote:
I did not find any text in X.501 or RFC 4512 which clearly says that. Especially RFC 4512 makes DIT structure rules optional. Maybe I'm missing something though.
12.6.2
A name form is only a primitive element of the full specification required to constrain the form of the DIT to that required by the administrative and naming authorities that determine the naming policies of a given region of the DIT. The remaining aspects of the specification of DIT structure are discussed in 12.6.5.
12.6.5 defines DIT Structure Rules.
I already read this text carefully and I do see that there is some justification for your interpretation. But still I'm not 100% convinced because the X.501 text is written under the assumption that there is always a governing structure rule (besides one corner-case clarified in X.501(2010)).
And it seems I'm not the only one who interpreted it differently:
https://lists.forgerock.org/pipermail/opendj/2015-April/004508.html
I don't claim to know *the* right interpretation. I'd vote to ask other vendors. I'd happily correct this in web2ldap if needed.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
I did not find any text in X.501 or RFC 4512 which clearly says that. Especially RFC 4512 makes DIT structure rules optional. Maybe I'm missing something though.
12.6.2
A name form is only a primitive element of the full specification required to constrain the form of the DIT to that required by the administrative and naming authorities that determine the naming policies of a given region of the DIT. The remaining aspects of the specification of DIT structure are discussed in 12.6.5.
12.6.5 defines DIT Structure Rules.
I already read this text carefully and I do see that there is some justification for your interpretation. But still I'm not 100% convinced because the X.501 text is written under the assumption that there is always a governing structure rule (besides one corner-case clarified in X.501(2010)).
And it seems I'm not the only one who interpreted it differently:
https://lists.forgerock.org/pipermail/opendj/2015-April/004508.html
I don't claim to know *the* right interpretation. I'd vote to ask other vendors. I'd happily correct this in web2ldap if needed.
Any other interpretation is nonsense.
1) an entry may have multiple object classes but there is only one structuralObjectClass that governs the entry.
2) a schema may have many nameForms defined, and many DIT Structure Rules defined, but there is only one that governs a given entry.
Both of those facts are indisputable.
Now - nameForms only specify a structuralObjectClass that they control. It's up to the DIT Structure Rule to define where in the DIT they take effect.
If you have a schema with multiple nameForms defined, and you take your interpretation that nameForms take effect in the absence of DIT Structure Rules, then you get the nonsensical case of multiple nameForms applying to a single entry. That is already explicitly prohibited in the spec.
The spec is not under-defined. This is not an "interpretation" - these are facts.
Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
I did not find any text in X.501 or RFC 4512 which clearly says that. Especially RFC 4512 makes DIT structure rules optional. Maybe I'm missing something though.
12.6.2
A name form is only a primitive element of the full specification required to constrain the form of the DIT to that required by the administrative and naming authorities that determine the naming policies of a given region of the DIT. The remaining aspects of the specification of DIT structure are discussed in 12.6.5.
12.6.5 defines DIT Structure Rules.
I already read this text carefully and I do see that there is some justification for your interpretation. But still I'm not 100% convinced because the X.501 text is written under the assumption that there is always a governing structure rule (besides one corner-case clarified in X.501(2010)).
And it seems I'm not the only one who interpreted it differently:
https://lists.forgerock.org/pipermail/opendj/2015-April/004508.html
I don't claim to know *the* right interpretation. I'd vote to ask other vendors. I'd happily correct this in web2ldap if needed.
Any other interpretation is nonsense.
- an entry may have multiple object classes but there is only one
structuralObjectClass that governs the entry.
- a schema may have many nameForms defined, and many DIT Structure Rules
defined, but there is only one that governs a given entry.
Both of those facts are indisputable.
Full ack.
Now - nameForms only specify a structuralObjectClass that they control. It's up to the DIT Structure Rule to define where in the DIT they take effect.
But there is no reference from a DIT structure rule to the structural object class. They are only associated via the name forms:
http://www.stroeder.com/img/LDAP_Schema_References.png
If you have a schema with multiple nameForms defined, and you take your interpretation that nameForms take effect in the absence of DIT Structure Rules, then you get the nonsensical case of multiple nameForms applying to a single entry.
Even if there is a governing structural rule for an entry there can be more than one possible name form.
From X.501(1993) section 12.6.2:
If different sets of naming attributes are required for entries of a given structural object class, then a name form must be specified for each distinct set of attributes to be used for naming.
Almost the same in X.501(2012) section 13.7.2.
And you (and others) agreed on that back in 2008:
http://www.openldap.org/lists/ietf-ldapbis/200807/msg00000.html
That is already explicitly prohibited in the spec.
Any implementation not supporting more than one possible name form is broken.
=> Your argument is not sufficient.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
Now - nameForms only specify a structuralObjectClass that they control. It's up to the DIT Structure Rule to define where in the DIT they take effect.
But there is no reference from a DIT structure rule to the structural object class. They are only associated via the name forms:
Correct.
If you have a schema with multiple nameForms defined, and you take your interpretation that nameForms take effect in the absence of DIT Structure Rules, then you get the nonsensical case of multiple nameForms applying to a single entry.
Even if there is a governing structural rule for an entry there can be more than one possible name form.
Irrelevant. There can only be one DIT Structure Rule for an entry, and a DIT Structure Rule can only reference one nameForm. For any given entry, only one nameForm may be in effect.
From X.501(1993) section 12.6.2:
If different sets of naming attributes are required for entries of a given structural object class, then a name form must be specified for each distinct set of attributes to be used for naming.
Almost the same in X.501(2012) section 13.7.2.
And you (and others) agreed on that back in 2008:
Irrelevant. This references entries of a given structuralObjectClass that exist in different parts of the DIT and thus governed by different DIT Structure Rules.
http://www.openldap.org/lists/ietf-ldapbis/200807/msg00000.html
That is already explicitly prohibited in the spec.
Any implementation not supporting more than one possible name form is broken.
=> Your argument is not sufficient.
Nonsense.
Howard Chu wrote:
There can only be one DIT Structure Rule for an entry, and a DIT Structure Rule can only reference one nameForm. For any given entry, only one nameForm may be in effect.
I've forgotten that the DIT structure rule can only reference a single name form (although I've implemented it that way).
Hmm...still don't get it...reviewing my code...
Are you saying that different DIT structure rules each referencing another name form which reference the same structural object class cannot have the same SUP id? SUP is also multi-valued.
Would this be possible?
sr2 --SUP--> sr1 sr3 --SUP--> sr1
sr1 --FORM--> nf1 sr2 --FORM--> nf2 sr3 --FORM--> nf3
nf1 --OC--> oc1 nf2 --OC--> oc23 nf3 --OC--> oc23
(with nf2 and nf3 having different RDN attrs sets)
The examples in X.521(1993) are pretty simple. But I remember having seen more flexible declarations when doing interop testing with some X.500 servers.
Ciao, Michael.
Michael Ströder wrote:
Howard Chu wrote:
There can only be one DIT Structure Rule for an entry, and a DIT Structure Rule can only reference one nameForm. For any given entry, only one nameForm may be in effect.
I've forgotten that the DIT structure rule can only reference a single name form (although I've implemented it that way).
Hmm...still don't get it...reviewing my code...
Are you saying that different DIT structure rules each referencing another name form which reference the same structural object class cannot have the same SUP id? SUP is also multi-valued.
Correct.
Would this be possible?
sr2 --SUP--> sr1 sr3 --SUP--> sr1
sr1 --FORM--> nf1 sr2 --FORM--> nf2 sr3 --FORM--> nf3
nf1 --OC--> oc1 nf2 --OC--> oc23 nf3 --OC--> oc23
(with nf2 and nf3 having different RDN attrs sets)
Nope, not allowed.
The examples in X.521(1993) are pretty simple. But I remember having seen more flexible declarations when doing interop testing with some X.500 servers.
There is still flexibility here, since an X.500 server can define a distinct subschema per subtree. But within a single subtree, or within the scope of a single subschema, no.
In OpenLDAP we have stubs for supporting per-DB subschema, but would need to do a bit more work to support arbitrary per-subtree subschema.
On 04/30/15 22:02, Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Michael Ströder wrote:
On 2015-04-30 13:37, Howard Chu wrote:
No. Name forms are only used when a DIT Structure Rule references them.
Are you sure? If yes, then please point out what's missing herein:
PS: you should read X.501(1993) for the exact text, since LDAP must conform to that spec. Section 12.6.
Hmm...
In X.501(1993) and X.501(2010) it is simply assumed that there are *always* DIT structure rules.
From X.501(1993) section 12.6.5 and X.501(2010) section 13.7.5: "Each object and alias entry is governed by a single DIT structure rule"
But there's no text dealing with the LDAP implementation without governing structure rule of an entry.
Name Forms are a component of DIT Structure Rules. If you don't use DIT Structure Rules, then you don't have name forms either.
Also after re-reading X.501 it seems the diagram is correct.
This statement in my former posting is obviously corrent:
"You cannot use DIT Structure Rules without associated Name Forms."
Because connecting the governing with the superior structural rule cannot be done without name forms.
The governing structure rule might limit the set of possible structural object classes in a part of a DIT but if absent or not applicable you can still limit to possible name form(s) for a chosen structural object class.
No, if there are no DIT structure rules then there are no constraints whatsoever on the naming or placement of entries.
I did not find any text in X.501 or RFC 4512 which clearly says that. Especially RFC 4512 makes DIT structure rules optional. Maybe I'm missing something though.
12.6.2
A name form is only a primitive element of the full specification required to constrain the form of the DIT to that required by the administrative and naming authorities that determine the naming policies of a given region of the DIT. The remaining aspects of the specification of DIT structure are discussed in 12.6.5.
RFC 4512 quotes
Name forms are primitive pieces of specification used in the definition of DIT structure rules
So it explicitly specifics no other use apart from DIT structure rules. However it does not say that "these rules do not apply without an associated DIT structure rule" neither it says it does.
On 05/01/15 00:08, Howard Chu wrote:
Michael Ströder wrote:
Howard Chu wrote:
Now - nameForms only specify a structuralObjectClass that they control. It's up to the DIT Structure Rule to define where in the DIT they take effect.
But there is no reference from a DIT structure rule to the structural object class. They are only associated via the name forms:
Correct.
If you have a schema with multiple nameForms defined, and you take your interpretation that nameForms take effect in the absence of DIT Structure Rules, then you get the nonsensical case of multiple nameForms applying to a single entry.
Even if there is a governing structural rule for an entry there can be more than one possible name form.
Irrelevant. There can only be one DIT Structure Rule for an entry, and a DIT Structure Rule can only reference one nameForm. For any given entry, only one nameForm may be in effect.
From X.501(1993) section 12.6.2:
If different sets of naming attributes are required for entries of a given structural object class, then a name form must be specified for each distinct set of attributes to be used for naming.
Almost the same in X.501(2012) section 13.7.2.
And you (and others) agreed on that back in 2008:
Irrelevant. This references entries of a given structuralObjectClass that exist in different parts of the DIT and thus governed by different DIT Structure Rules.
http://www.openldap.org/lists/ietf-ldapbis/200807/msg00000.html
That is already explicitly prohibited in the spec.
Any implementation not supporting more than one possible name form is broken.
=> Your argument is not sufficient.
Nonsense.
Well in that case, it'll mean that that the DIT content rules will apply only when referring to an entry which compiles with the name form; if the same entry is referred to without compliance with the name form (situation Z), the DIT structural rule will not apply. This means inconsistency in the DIT. The DIT will be all about 'perspectives'. In situation Z, an entry may not be subordinate to one entry, but in the other, it will appear as subordinate.
openldap-technical@openldap.org
-
dE -
Howard Chu -
Michael Ströder