[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
LDAP subentry, discussion on CN {MUST or MAY}
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