Subject: RE: LDAPsubentry

From: Erik Andersen <[email-masked]>
Date: Fri, 19 Nov 1999 11:06:29 +0100

The consequence of making it an abstract object class would be that the 
different types of subentries each should have a structural object class 
defined instead of an auxiliary object class (as we have it X.500). A naming 
attribute would have to be defined for each of those. This naming attribute 
could then be different for each type of subentry. What would the advantage be 
of that? The type of subentry is clearly indicated in the objectClass 
attribute.

As the same clients will access X.500 systems and LDAP servers, it must be an 
advantage for implementers not to have unnecessary differences.

Hope that helps.

Erik Andersen
CEN/ISSS/WS-DIR Chairman
Mobile: +45 20 97 14 90
E-mail;  [email-masked]
Internet: http://www.cenorm.be/isss/Workshop/DIR/Default.htm

-----Original Message-----
From:	Ed Reed [SMTP:[email-masked]]
Sent:	19. november 1999 05:13
To:	[email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject:	Re: LDAPsubentry

 << File: TEXT.htm >> 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.

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 785 0315
http://www.OnCallDBA.COM

>>> "Kurt D. Zeilenga" <[email-masked]> 11/18/99 10:42AM >>>
Forwarded to owning WG...

>To: [email-masked]
>From: "Kurt D. Zeilenga" <[email-masked]>
>Cc: [email-masked]
>
>I would like to see LDAP subentry be an abstract object class
>to which is then subclassed as necessary to provide structure
>(including naming attributes).
>
>As defined, LDAP subentry requires cn.  This may not be appropriate
>for LDAP subentries.   I suggest:
>
>( ldapSubEntryOID NAME 'ldapSubEntry'
>   DESC 'LDAP Subentry abstract class, version 1'
>     SUP top ABSTRACT )
>
>( cnSubEntryOID NAME 'cnSubEntry'
>   DESC 'CN LDAP Subentry class, version 1'
>     SUP ldapSubEntry STRUCTURAL
>     MUST ( cn ) )
>
>Your schema definition would then be split as appropriate between
>the abstract class and the structural class.
>
>Regards, Kurt
>
>
>

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 19 Nov 1999 07:31:24 -0800

At 11:06 AM 11/19/99 +0100, Erik Andersen wrote:
>defined instead of an auxiliary object class (as we have it X.500).

No.  They could share a structural class subclassed from the
abstract class to provide cn naming.

Note: the intention of the LDAP subentry was for other subentries
to subclass ldapSubentry.  Your statement implies that the author
may want to rework the draft to indicate that implementors should
mix in auxiliary object classes to extend ldapSubentry for
specific uses.

>A naming attribute would have to be defined for each of those.

Yes.  But they MAY also share one structural object class.  However,
they would be also allowed to separately subclass the abstract class
if more appropriate for their application.

>This naming attribute 
>of that?

Some subentries can consume a huge amount of namespace.  If they
are forced to share 'cn' naming with other subentries, name space
conflicts will arise.  Such subentry need to use a naming attribute
which is not used otherwise to ensure no conflicts arise.

The benefit of defining both an abstract AND a structural
object class is that it offers flexibility at no significant cost.

MUST 'cn' will force those who cannot provide a cn attribute
to define other objectclasses for subentries which are not
subclasses of LDAPsubentry.  This would be bad.

>advantage for implementers not to have unnecessary differences.

I think LDAPsubentry differs enough already that X.500 clients are
likely to be quite lost already.  Dividing the class into two
(an abstract and a structural) object class would likely not
cause additional heartburn.