Re: LDAPsubentry

["Kurt D. Zeilenga" <Kurt@OpenLDAP.Org>]

At 10:31 AM 11/19/99 -0500, Mark Smith wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> At 09:13 PM 11/18/99 -0700, Ed Reed wrote:
>> >Hmmm...I made it structural, because that's how the X.500 subentry
>> >is defined...I can see doing it either way.
>> >
>> >Any reaction from the X.500 community?  Does it matter to you,
>> >one way or the other?  To be clear, the draft specifies ldapSubEntry
>> >to be STRUCTURAL, and Kurt's proposal is to make it ABSTRACT,
>> >instead.

Kurt's proposal is to make it abstract AND provide a structural
objectclass with CN naming.

This allows addition of new structural subentry objectclasses which
don't require CN naming to share semantics of the abstract subentry
class YET continues to allow mixin of auxiliary subentry
objectclasses with defined structural subentry objectclasses. 

>> 
>> I should note that my primary reason for desiring this change
>> is reuse.  I need such a beast but don't want to get stuck with
>> MUST cn.
>
>A simpler alternative would be to make cn a MAY (which allows for
>subclasses that use a different naming attribute).

MAY 'cn' would work for me.

>Kurt, can you provide an example where cn won't meet your needs?

Yes.

I am creating subentries associated with each authorization identity
which has access to a particular naming context (or Root DSE).  The
entries have one single value attribute which contains an octetString
representation of the authorization identity.  As this is the ONLY
value, it must be used for naming purposes.  As it's arbirtary, it
consumes the complete name space under the naming attribute within
that RDN.  If I am required to use CN naming, the name space consumed
by these subentries will colide with the namespace of other subentries.

I could use an auxiliary object class that mixed in a new naming
attribute to resolve name space issues, but MUST cn would require
I stuff something into CN.  I hestate stuff the authorization
identities as the matching rules associated with CN are not
appropripriate.  I could stuff an empty string into CN, but this
seems rather pointless.

Right now, I've defined my own structural objectclass for these
subentries which use a different naming attribute than cn.  I'd
like to have a common abstract object class which provides subentry
semantics to which multiple subentry structural objectclasses
can share.  For most implementations, there would likely only
be one such structural objectclasses (with cn naming), but others
could be defines as needed.

Kurt