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

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.

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 03/09/00 04:20PM >>>
At 02:48 PM 3/9/00 -0700, Ed Reed wrote:
>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).

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.