Subject: SUBCLASSING, again

From: Kathleen Dally <[email-masked]>
Date: Tue, 10 Feb 2004 18:41:48 -0500

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

---

From: John McMeeking <[email-masked]>
Date: Wed, 11 Feb 2004 10:35:48 -0600

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 10 Feb 2004 20:41:13 -0800

I note that this topic was discussed early last year in this
thread:
  http://www.openldap.org/lists/ietf-ldapbis/200301/msg00057.html

which was summarized (post WG Last Call) in item 5 of this post:
  http://www.openldap.org/lists/ietf-ldapbis/200302/msg00017.html

as follows:
  It was noted that Section 2.4.2 and 2.4.3 includes restrictions
  up subclassing not explicitly stated in X.501.  The author
  considers the lack of such statements in X.501 as a technical
  omission as such subclassing makes little sense.  No action.

It's my opinion (as Editor, not chair) that, in absence of a new
significant issue, we should consider this item closed.

However, to try to answer your "What am I missing?" question,
here is a little more detail.

While X.501 did not explicitly stated these restrictions, it
did imply them.  For instance, by the text:
  An object class (a subclass) may be derived from an object
  class (its direct superclass) which is itself derived from
  an even more generic object class.

(consider what "more generic" implies here).  However,
more directly implied because, without them, the specification
object class model and DIT content rules would make little sense.

For instance, it is quite clear in X.501 that which auxiliary
classes an entry can belongs to is controlled solely by the
DIT Content Rule.  However, the entry's structural object
class has a auxiliary super class, then the entry belong to
that auxiliary class even when the DIT content rule disallows
it from belong to that auxiliary class.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 11 Feb 2004 22:54:09 +0100

> it from belong to that auxiliary class.

I guess that would mean that an entry of that structural object class
cannot be created unless a DIT content rule allows the auxiliary class.

-- 
Hallvard

---

From: Kathleen Dally <[email-masked]>
Date: Wed, 11 Feb 2004 18:37:21 -0500

Hi All!

I think Entries and Object Classes are being confused in this discussion.
Nowhere does X.501 say that the superclasses of a Structural Object Class
cannot be Auxiliary.  In fact, there is no explicit statement that any of
the superclasses must be Structural.

For ENTRIES however, it is clear that there is exactly one Structural
Object Class.  Any additions or deletions of attributes or additions of
(Auxiliary) Object Classes to an ENTRY must be handled by a Content Rule.
There is nothing in the specification of a Content Rule that prohibits the
use of an Auxiliary Object Class.

For many years, I have been told by implementors that the products do not
support Content Rules!  Given this fact, if Auxiliary Object Classes could
not be superclasses, no Auxiliary Object Classes could never be used.
X.509 clearly intends that Auxiliary Object Classes be used, as it defines
several.

I think this sentence in the Models draft must be removed from section
2.4.2:
      "Structural object classes cannot subclass auxiliary object classes."

I think section 2.4.2 should be clarified to indicate that multiple
inheritance is possible, as is clearly stated in X.501, clause 8.3:
        "An object class may be derived from two or more direct
superclasses (superclasses not part of the same
         superclass chain). This feature of subclassing is termed multiple
inheritance."

 Perhaps this paragraph could be added to the end of section 2.4.2:
        "A Structural Object Class that is formed by multiple inheritance
has one direct superclass which is a
         structural object class and other direct superclasses which are
abstract or auxiliary object classes."

Regards,
Kathy Dally

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 11 Feb 2004 16:37:19 -0800

>cannot be created unless a DIT content rule allows the auxiliary class.

Or one could argue that's not necessary because its controlled
through the structural object class of the entry.  That is,
it can be argued that a DIT content rules only controls the
optional set of auxiliary classes an entry may belong to.
As any entry of this structural class must belong to this
auxiliary class, it not subject to the DIT content rule.

My point here is that someone would need to engineer how such
subclassing should work.  That's a tall order when you
consider that not only did X.501 not explicitly disallow
Structurals from subclassing Auxiliaries, it did not
explicitly disallow Auxiliaries from subclassing Structurals.
Even if we were to only allow the former category, sections
8, 12, and 14 of X.501 would need to be significantly revised.

That is, the alternative to stating these restrictions is
not simple removal of the restrictions.  The alternative
is to revise the technical specification such that the model
make sense in the face of such subclassing and that it is
clear how implementations are to behave.

The WG considered this alternative during the WG Last Call
and rejected it.

Hence, at this point, if there are those who believe strongly
that this alternative should have been taken, that they
(on an individual basis) write an I-D making sense of such
subclassing.  That is, I don't think the WG should revisit
this issue in absence of a specific alternative text.  That
text should attempt to address the underlying problems with
X.501 which caused the restrictions to be added in the first
place.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 11 Feb 2004 16:53:51 -0800

X.501 doesn't explicitly say that auxiliary classes cannot
not subclass structural classes.  By your argument, these
must be allowed as well.  Why aren't you making this argument?

Kurt

---

From: Kathleen Dally <[email-masked]>
Date: Wed, 11 Feb 2004 21:56:31 -0500

Hi Kurt!

I would have no trouble deleting the sentence from Models, section
2.4.3:
        " Auxiliary object classes cannot subclass structural object
classes."

However, I do not believe that the intent to permit Auxiliary object
classes to subclass Structural object classes is as clear in X.501.

To fix the original problem, Models, section 2.4.3, third paragraph,
second sentence needs to be deleted, too.  It begins:
        "If no DIT content rule ..."

Regards,
Kathy

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 11 Feb 2004 19:04:06 -0800

>        " Auxiliary object classes cannot subclass structural object

Even though the model makes no sense in face of such
constructions?

>classes to subclass Structural object classes is as clear in X.501.

Why?  Since X.501 didn't explicitly disallow this, why do
you think it clear that the intent was to disallow this?

Kurt

---

From: Kathleen Dally <[email-masked]>
Date: Wed, 11 Feb 2004 22:30:47 -0500

Hi Kurt!

Responses in-line.

Thanks,
Kathy

> Even though the model makes no sense in face of such

kd:  I agree that this seems nonsensical.  I haven't seen any use made of
such a subclassing.

> you think it clear that the intent was to disallow this?

kd:  The intent that I am speaking about is the nature of Auxiliary
Object Classes being a means of augmenting other classes and entries with
groups of attributes.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 11 Feb 2004 23:06:07 -0800

>kd:  I agree that this seems nonsensical.  I haven't seen any use made of

So, it's okay to disallow this, even though X.501 didn't
explicitly do so, because they are nonsensical.

One can, and the WG did, apply the same argument to Structural
Classes which subclass Auxiliaries.  That is, that this is
nonsensical and hence should be disallowed, as implied by the
"more generic" statement as well as other aspects of the
specification.

As I noted then (and recently), the alternative is to try to
make sense of it.  However, that's a tall order (see below).

>Object Classes being a means of augmenting other classes and entries with

Where in X.501 does it describe Auxiliary object classes as a
mechanism for extending other classes, in particular, any
structural class?  In reading 8.3.3, it seems clear the nature
of Auxiliary object classes is to allow optional augmentation
of entries.

Do you see any language anywhere which specifically mentions
that those constructs are allowed, and, more importantly, any
text which addresses the special cases which would naturally
arise from allowance of such constructs?

My concern is that there are many statements which, when taken
together, make little sense if structural classes are allowed
to subclass auxiliary classes.  Below I elaborate on a few
instances.

8.3.3 says:
  Therefore, besides being a member of the structural object class,
  an entry may be optionally a member of one or more auxiliary object
  classes.
This would have to reworded:
  Therefore, besides being a member of the structural object class
  and any auxiliary classes which are superclasses of this
  structural object class, an entry may be optionally a member of
  one or more auxiliary object classes.
to clarify that membership in structural class's superclass
auxiliary class is not always optional as implied by current text.

8.3.3 continues:
  An entry’s auxiliary object classes may change over time.
This would have to reworded:
  An entry's auxiliary object classes, except those which are
  superclasses of the entry's structural object class, may
  change over time.
as not all the entry's object classes may change over time as
implied by the current text.

Before I go on, I note that it's starting to sounding like an
auxiliary class which is a superclass of the structural object
class of an entry is to be treated as if it were structural
in this situation.  But, I note that is counter to 8.3:
  Each object class is of precisely one of these kinds,
  and remains of this kind in whatever situation it is
  encountered within the Directory.
This section, I think, was intended that special cases were
not intended.  But we'd have to treat auxiliary classes in this
situation quite differently from those not in this situation.

12.3 says,
   There shall be one value of the objectClass attribute for
   the entry’s structural object class and a value for each
   of its superclasses.
So, in this situation, the auxiliary superclasses of the
structural class of the entry are required to be listed as
objectClass values. 12.3 then says:
      Where auxiliary object classes are used, an entry may
   contain values of the objectClass attribute for the
   auxiliary object classes and their superclasses allowed
   by a DIT content rule.
which means that in this situation, these auxiliary
superclasses of the structural class of the entry must in
listed in the controlling DIT content rule.  And, unsaid,
this requires there to be a controlling DIT content rule
in this situation.

12.7 says:
  A DIT content rule specifies the permissible content of
  entries of a particular structural object class via the
  identification of an optional set of auxiliary object
  classes, mandatory, optional and precluded attributes.
That is, only those auxiliary classes in this optional set are
permissible.  12.7 continues:
  A DIT content rule definition includes:
      optionally, an indication of the auxiliary object
      classes allowed for entries governed by the rule
That is, if they are listed, the class is "allowed", not
"required". But from 12.3 we get that auxiliary superclasses
of the structural class of the entry are actually required
to be listed and this set is not optional in this situation.

12.7 says:
  An entry governed by a DIT content rule may, in addition
  to the structural object class of the DIT structure rule,
  be associated with a subset of the auxiliary object
  classes identified by the DIT content rule. This
  association is reflected in the entry’s objectClass
  attribute.
If we consider a DIT content rule which lists as allowed
only the auxiliary superclasses of the structural class of
the entry, then the only subset which an entry can be
associated with is the complete set, not any subset.

There are likely other areas where that would need to
be revised if such constructs were to be allowed.

In response to your comment:

>For many years, I have been told by implementors that
>the products do not support Content Rules!

Some do, some don't.  In LDAP, it's viewed as optional.

>Given this fact, if Auxiliary Object Classes could not be
>superclasses, no Auxiliary Object Classes could never
>be used.

In absence of some extension, as previously discussed
during WG Last Call, yes.

Many LDAP implementations have extensions in this area.
However, I'm now aware of any formal specification which
details how the set of permissible auxiliary classes is
controlled in absence of DIT content rules.  However, I
am aware of implementations which, while supporting
such extensions, do not allow such subclassing constructs.
This because the constructs are nonsensical even when
one uses other mechanisms to control which auxiliaries
may be present (for instance, section 8 concerns above).

The question for us is whether implementations which
claim to support DIT content rules in a manner consistent
with the existing specification and, if so, how to address
interoperability and other known technical issues.  It is
clear that that there are multiple independently developed
implementations of DIT content rules as described in this
X.500 and that the clarifications in [Models] go a long way
towards addressing the known technical issues.

Kurt

---

From: Kathleen Dally <[email-masked]>
Date: Thu, 12 Feb 2004 16:04:06 -0500

Hi Kurt!

Responses in-line.

Regards,
Kathy

> kd:  By definition of multiple inheritance, a (new) object class can have
> more than one direct superclass.  Nothing is said in the multiple
> inheritance definition about the type of  the superclasses.  In the
> definition of structural, it indicates that only one of the superclasses is
> a structural object class.  Therefore, the other direct superclasses must be
> auxiliary or abstract.  An ENTRY has exactly one structural object class,
> which is in the case of the new object class derived from one structural
> object class and, possibly, auxiliary object classes.

> arise from allowance of such constructs?

kd:  Could you please give an example of one of the special cases?

> auxiliary class is not always optional as implied by current text.

kd:  No, the rewording would have to be:
        "Therefore, besides being a member of the structural object class and
any structural, auxiliary, and abstract
         classes which are superclasses of this structural object class, and
entry maybe optional a member of one or
         more auxiliary object classes."
I don't think we need to elaborate the definition of subclassing here.

> implied by the current text.

kd:  No, because the statement is about the nature of ENTRIES, not OBJECT
CLASSES.

> situation quite differently from those not in this situation.

kd:  No, the nature of the auxiliary class is not changed by being a
superclass.  However, the attributes included in the auxiliary class are
inherited in the new class in the same way as those from any other
superclasses.  (For example, top does not become structural.)

> objectClass values.

kd:  Yes.

> 12.3 then says:

kd:  No.  The statement is about ENTRY.  Any auxiliary superclasses of the
structural object classes are not required to be cited in a Content Rule,
because they are already part of the entry under the definition of the
structural object class.

> permissible.

kd:  No.  This statement is discussing the significance of the Content Rule,
which controls auxiliary object classes and attributes beyond the
specification of the structural object class.

> 12.7 continues:

kd:  This is a discussion of the Content Rule, not the requirements on the
entry specified by the structural object class.

> associated with is the complete set, not any subset.

kd:  Same as above.

> kd:  But, the use of auxiliary object classes as superclasses is not
> precluded in X.500.  LDAP is being overly restrictive.

> may be present (for instance, section 8 concerns above).

kd:  I disagree that structural object classes derived from another structural
class and one or more auxiliary or abstract classes is nonsense.  A perfectly
good, useful, structural object class is one, such as, "namedPerson" which
would be defined as:

( x.x.x.x NAME 'namedPerson'
   SUP person, individualName)

( x.x.x.x NAME 'individualName'
   SUP top
   AUXILIARY
   MUST ( givenName $ initials $ generationQualifier ) )

The advantage of using the auxiliary object class in namedPerson (instead of a
MUST list of attributes), is that the individualName object class can be
searched for in the objectClass attribute.

> towards addressing the known technical issues.

kd:  I am NOT disagreeing with the definition of CONTENT RULES or ENTRIES,
only the Models restriction on OBJECT CLASSES.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 13 Feb 2004 09:41:15 -0800

>kd:  Could you please give an example of one of the special cases?

An auxiliary class which would be mandatory for the entry to belong
to (because it was a supertype of the entry's structural class) is
a special case.  Section 8 describes auxiliary classes as supporting
optional augmentation of a entry, and section 12 is relies heavily
upon this.

To make clear in the specification that some auxiliary classes in
some situations are mandatory would require significant rewriting of
these, and possible other (14?), sections.  That was the alternative
I offered to the WG during WG Last Call.  That alternative was rejected.

Kurt