Re: SUBCLASSING, again

[John McMeeking <jmcmeek@us.ibm.com>]

I don't know where this restriction came from.  I haven't found it (yet?)
in the original V3 RFCs.

X.501 has one restriction on subclassing: only an abstract class can be a
superclass of another abstract class.  An auxiliary class subclassing a
structural class could introduce problems -- entries would likely have more
than one most subordinate structural class.  But structural classes
subclassing auxiliary classes seems like it should be okay.  If someone
were to try to remove the auxiliary class from an entry, the server would
have to verify that the auxiliary class wasn't subclassed by any of the
remaining objectclasses.  That doesn't seem too hard.


John  McMeeking


owner-ietf-ldapbis@OpenLDAP.org wrote on 02/10/2004 05:41:48 PM:

> Hi All!
>
> Here is an example of a structural object class that subclasses both one
> structural object class and one auxiliary object class.  I believe this
> is an important capability, so that a new structural object class can be
> defined by augmenting another.  Using a content rule to add the
> auxiliary to the original class is not always possible because of
> needing two distinct types of entries.  In the example, there may be
> entries with applicationEntity as the structural class and other entries
> with mLAgent as the structural class.
>
>     ( 2.16.840.1.101.2.2.3.64 NAME 'mLAgent'
>           SUP ( 2.5.6.12 $
>                     2.5.6.21  )
>       MAY 2.5.4.52 )
>             ; 2.5.6.12 = applicationEntity
>             ; 2.5.6.21 = pkiUser, an auxiliary object class
>             ; 2.5.4.52 = supportedAlgorithms
>
> My problem is that this important case appears to be precluded by the
> statement in Models-09, 2.4.2:
>         "Structural object classes cannot subclass auxiliary object
> classes."
> What am I missing?
>
> Thanks,
> Kathy Dally
>
>