Re: LDAP subentry, discussion on CN {MUST or MAY}

[Jim Sermersheim <JIMSE@novell.com>]

To satisfy X.500, I believe that the LDAPSubentry object class can be STRUCTURAL and not include any attributes. From my reading, the attributes specified in the name form don't need to be made up of the attributes specified in the object class definition.  The text I'm reading is in Section 12.6.2 of X.501: 
"The RDN attribute (or attributes) need not be chosen from the list of permitted attributes of the structural object class as specified in its structural or alias object class definition".

I may be mis-reading that, but I don't think so. There also may be directory implementations that require naming attributes to be listed in the object class's MUST or MAY list (I know of at least one).

Jim

>>> "Ed Reed" <eer@OnCallDBA.COM> 3/9/00 2:58:31 PM >>>
Back in November and at the IETF meeting in Washington, we discussed whether LDAPsubentry should be STRUCTURAL or ABSTRACT in definition.

Mark has pointed out that MAY would address Kurt's objection to MUST {cn}, but that leaves the many folks out there who define naming rules with a problem, when there are (possibly) no attributes defined on the class at all (cn is the only attribute declared for the ldapsubentry class definition).

Frankly, those folks who DO define naming attributes and naming rules will have to deal in some way with other systems who don't, but that's a different discussion I think.

I think the discussion in Washington concluded that we should

1) leave the class STRUCTURAL
2) leave MUST {cn} in the definition
3) encourage Kurt to derive a new subclass of LDAPsubentry for his special-purpose class, which defines the other attribute he will use to actually name his entries - meaning that yes, he will need to provide a (possibly useless, but not necessarily unique) value for the cn value

Erik's argument, that to make it Auxiliary would require a proliferation of new structural types, each with their own new naming rules, is what finally persuaded me to avoid that approach.  The consequences of blithly ignoring the operational experience of the X.500 community was also important.

It will be easier, by far, for most people to treat LDAPsubentry as STRUCTURAL, and then to decorate it with additional attributes for their particular needs, than to require each new use to define a new STRUCTURAL class with it's own naming rules.

As I think about it, though, there is one way to make both camps happy: 

1) create an ABSTRACT class, perhaps LDAPsubentryabs or some such, with no attributes defined at all.  
2) create a STRUCTURAL class, derived from LDAPsubentryabs, with MUST {cn} and normal naming rules for most foks to use they way I envision they'll use it (by decorating them with AUXILIARY classes).

Such an approach would violate the "fewer classes is better" rule.  But I think it would satisfy both Kurt and the X.500 folks.

This is the only issue standing in the way of a last call.

Any final words?

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.OnCallDBA.COM