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. 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.
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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature