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

From: "Ed Reed" <[email-masked]>
Date: Thu, 09 Mar 2000 14:48:53 -0700

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 09 Mar 2000 15:19:19 -0800

>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).

That's exactly what I had in mind all a long.  But Mark's suggestion
of a single STRUCTURAL class with MAY cn is works as well.  I really
don't understand the 'naming rule' issue with MUST vs. MAY.

One additional comment:

We need a STRUCTURAL object class for the Root DSE.  This object
class would have no naming attributes... and, in fact, doesn't
need to MAY/MUST any attributes.  Ie:
	( <oid> NAME 'LDAPentry' SUP 'top' STRUCTURAL )

My question is, does it make sense to define subentry oc's
in terms of LDAPentry?   I would guess "no" as a entry and
subentries are quite different.   Anyways, food for thought.

---

From: "Sukanta Ganguly" <[email-masked]>
Date: Thu, 09 Mar 2000 16:29:48 -0700

Kurt,
  What is the reason behind the need to have a structural Object class for RootDSE ? At the present the RootDSE is kinda defined. Newer attributes if any are added to it on a a case by case basis and does go through the IEFT WG check. 

SG
Novell Inc
work 801-861-5190

>>> "Kurt D. Zeilenga" <[email-masked]> 03/09/00 04:20PM >>>

One additional comment:

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 09 Mar 2000 15:38:27 -0800

At 04:29 PM 3/9/00 -0700, Sukanta Ganguly wrote: 
>What is the reason behind the need to have a structural
>Object class for RootDSE ? 

The RootDSE, like any other entry, needs structure (per
the X.500 model).  Per previous discussions (see archives),
a structural object class was going to be defined (by Mark
Wahl) for LDAPv3 revised specifications.

	Kurt