Erik Skovgaard wrote:RFC 2252 (Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions) says:> For whatever it is worth, nor is OK to create funny non-standard Structural
> Object Classes (i.e. inetOrgPerson) that people get tempted to use instead
> of the basic ones. All extensions to the standard schema should be Aux.
> Object Classes, IMHO. Or else there's only pain to gain.For the X.500 challenged among us, could you tell us
the difference between "structural" and "aux" object classes
please ?
4.4. Object Classes
The format for representation of object classes is defined
in X.501
[3]. In general every entry will contain an abstract class
("top" or
"alias"), at least one structural object class, and zero
or more
auxiliary object classes. Whether an object class
is abstract,
structural or auxiliary is defined when the object class
identifier
is assigned. An object class definition should not
be changed
without having a new identifier assigned to it.
Erik Skovgaard wrote:
> For whatever it is worth, nor is OK to create funny non-standard Structural
> Object Classes (i.e. inetOrgPerson) that people get tempted to use
instead
> of the basic ones. All extensions to the standard schema should
be Aux.
> Object Classes, IMHO. Or else there's only pain to gain.
I think there is a place for both inheritance and aggregation in schema extensions. For inetOrgPerson, the inheritance chain is:
top
person
organizationalPerson
inetOrgPerson
I don't see anything worse in the final inheritance step than in the previous one. inetOrgPerson has been described in I-Ds for a while, it has demonstrated its usefulness in widespread use, and it is approaching informational RFC status (see draft-smith-ldap-inetorgperson-03.txt).
Rob