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

[Steven Legg <steven.legg@adacel.com.au>]

Jim,

I agree with your interpretation, with the added qualification that the
naming attribute(s) must still be a permitted attribute of the entry,
if not by the structural object class then by an auxiliary object class
or DIT content rule. That is, being referenced in a relevant name form
does not alone make an attribute a permitted attribute of an entry.

For the record, I'm not much fussed whether we make the cn attribute
mandatory or not, but if the definition of LDAPsubentry ends up being the
same as X.500's subentry definition I would rather that we just copy
the X.500 definition and OID.

Steven

-----Original Message-----
From: owner-ietf-ldup@mail.imc.org
[mailto:owner-ietf-ldup@mail.imc.org]On Behalf Of Jim Sermersheim
Sent: Friday, 10 March 2000 16:22
To: jayhawk@att.com; kurt@boolean.net; eskovgaard@geotrain.com;
era.als@get2net.dk; mcs@netscape.com; eer@OnCallDBA.COM
Cc: ietf-ldup@imc.org; ietf-ldapext@netscape.com; Mark Hinckley
Subject: Re: LDAP subentry, discussion on CN {MUST or MAY}


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