Missing ITU-T Rec. X.501 built-in definition

[JesseCoretta]

Describe the bug

Per my comments on #435 just a few minutes ago, the subentryNameForm is missing from our schema library. It is present within our test cases, but this produces a false negative, as it occludes the issues a user -- such as myself -- will see when attempting to introduce the hypothetical DIT structure rule suggested in our Administrator's Guide (see page 243).

I don't know how you want to name this file, so let's just assume we create a new file called 00-x501.ldif. Note that this definition requires both cn and subtreeSpecification, both of which are defined in 00-core.ldif. Thus, by virtue of alphabetical ordering, this file will be listed after its dependency 00-core.ldif.

## /opt/opendj/config/schema/00-x501.ldif
dn: cn=schema                                                           
objectClass: top                                                        
objectClass: ldapSubentry                                               
objectClass: subschema
nameForms: ( 2.5.15.16
   NAME 'subentryNameForm'
   DESC 'X.501, cl. 14.2.2: the Subentry name form'
   OC subentry
   MUST cn )

Of course, any file name/number would do, assuming it results in a file order that places 00-core.ldif before the new file.

UPDATE: PR submitted, see #440. failed.

[maximthomas]

Hi @JesseCoretta,
I don't think it is a good idea to place 00-x501.ldif schema into default distribution because it coudl break existing installations.

I suggest to put it into documentation and reference as an attachement.
See attachements dir and chap-privileges-acis.adoc as an example.

[JesseCoretta]

Hi @JesseCoretta, I don't think it is a good idea to place 00-x501.ldif schema into default distribution because it coudl break existing installations.

I suggest to put it into documentation and reference as an attachement. See attachements dir and chap-privileges-acis.adoc as an example.

OK @maximthomas. I think we should close this issue and remain in non-compliance with RFC 3672 and X.501.

It seems we keep going in circles on this issue, and I've tried every way I know to explain it to the team. At this point, I am declaring failure on that piece.

In fact, Section 3 of my paper covers this very comment, and was blessed by the co-author of RFC 3672 in terms of factual validity.

[vharseko]

By default, any form of name for a subentry is allowed.

OpenDJ/opendj-server-legacy/src/test/java/org/opends/server/extensions/Issue425TestCase.java

Lines 91 to 100 in df9b759

	//add OC subentry without DSR (warning level)
	TestCaseUtils.addEntry(
	"dn: o=test-subentry2,ou=Accounts,dc=example,dc=com",
	"objectClass: top",
	"objectClass: extensibleObject",
	"objectClass: subentry",
	"objectClass: collectiveAttributeSubentry",
	"subtreeSpecification: {}",
	"cn: test-subentry2"
	);

You can optionally add a rule

OpenDJ/opendj-server-legacy/src/test/java/org/opends/server/extensions/Issue425TestCase.java

Lines 102 to 118 in df9b759

	int resultCode = TestCaseUtils.applyModifications(true,
	"dn: cn=schema",
	"changetype: modify",
	"add: nameForms",
	"nameForms: ( 2.5.15.16\n"+
	" NAME 'subentryNameForm'\n"+
	" DESC 'X.501, cl. 14.2.2: the Subentry name form'\n"+
	" OC subentry\n"+
	" MUST cn )",
	"-",
	"add: ditStructureRules",
	"dITStructureRules: ( 177\n"+
	" NAME 'subentryStructure'\n"+
	" FORM subentryNameForm\n"+
	" SUP ( 20 21 ) )"
	);
	assertEquals(resultCode, 0);

and force name control for cn

OpenDJ/opendj-server-legacy/src/test/java/org/opends/server/extensions/Issue425TestCase.java

Lines 120 to 147 in df9b759

	//add OC subentry with DSR: RDN OC subentry MUST cn
	TestCaseUtils.addEntry(
	"dn: cn=test-subentry-ok,ou=Accounts,dc=example,dc=com",
	"objectClass: top",
	"objectClass: extensibleObject",
	"objectClass: subentry",
	"objectClass: collectiveAttributeSubentry",
	"subtreeSpecification: {}",
	"cn: test-subentry-ok"
	);
	//add OC subentry with DSR violation: RDN OC subentry MUST cn
	assertThrows(new ThrowingRunnable() {
	@Override
	public void run() throws Throwable {
	TestCaseUtils.addEntry(
	"dn: o=test-subentry-error,ou=Accounts,dc=example,dc=com",
	"objectClass: top",
	"objectClass: extensibleObject",
	"objectClass: subentry",
	"objectClass: collectiveAttributeSubentry",
	"subtreeSpecification: {}",
	"cn: test-subentry-error"
	);
	}
	}
	);
	}

[JesseCoretta]

@JesseCoretta I think implementing the "essense" of the name form without the need for a DIT structure rule and enforcing the private rules are not the best approaches, because they look like a hidden magic and could break existing OpenDJ instances.

I think a DIT structure rule should be set by users themselves, and this approach should be included in the OpenDJ documentation.

... and days later ....

@JesseCoretta, I don't think it is a good idea to place 00-x501.ldif schema into default distribution because it coudl break existing installations.

I suggest to put it into documentation and reference as an attachement. See attachements dir and chap-privileges-acis.adoc as an example.

---

These two statements contradict one another. Which is it, @maximthomas?

You seem to want neither the name form nor the structure rule. As a result, you've quite effectively neutered any means for resolving this issue and with no good reason. Thus, OpenDJ remains in violation of RFC 3672 and X.501.

If we follow both of these suggestions, we end up EXACTLY where we began -- in violation. All of that effort was wasted.

In fact, we were already in agreement on this issue ... or so I thought. You guys approved my document update which proves this. In other words, why approve a document update that CONTRADICTS our previous agreement? Would you like proof? See the schema chapter regarding Structure Rules and Collective Attribute Subentries which I updated. If you read it, you will see what I am talking about. We agreed to INCLUDE the X.501 name form, but let users supply THEIR OWN structure rule.

Honestly, did you guys even read the document update, or did you just approve it without reading it? Based on this situation, I'm going to assume no one read it.

---

Overall, this highlights a long-standing issue I have observed since joining the team -- communications issues. It is this issue that has put my intended contributions in jeopardy.

To try and help, I have exercised every means for communicating effectively with the active team members. I even thought of translating this stuff to Russian to try and be accommodating (!!), but decided against this because I don't speak or write the language. I tried shorter responses, longer responses, repeating myself using different words. Nothing seems to have worked. At first i thought it was a simple language barrier ... now I am not so sure.

Either way, due to these consecutive issues, I have been forced to give up and leave the team.

I tried. I really did try. I already gave this project many hours, and was happy to give you many more. I had some great ideas that would have elevated OpenDJ to a new level. But I can't invest any more time in the face of these kinds of problems.

I am sorry it couldn't work out. I really am ... in truth, I'm actually heartbroken 😞

Regardless, I wish you guys well. You've really got a great product here -- take good care of it.