Re: ActiveDirectory schema

[rweltman@netscape.com (Rob Weltman)]

Erik Skovgaard wrote:

Rob,

Since you are getting into specifics, note that inetOrgPerson is *not* on
an IETF standards track.  In fact, the author has indicated an
unwillingness to fix problems (e.g. proprietary OIDs).  In other words, it
is a document describing a *proprietary* approach.

An informational RFC doth not a standard make.

  Point taken. Many standards do start off as common practices, though...

Rob
 

 

Cheers,               ....Erik.

---------------------------------
Erik Skovgaard
GeoTrain Corp.
Enterprise Directory Engineering
http://www.geotrain.com
Telephone: +1 604 244-9131

At 09:29 1999-06-13 -0700, Rob Weltman wrote:
>  David Boreham wrote: 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
>  All extensions to the standard schema should be Aux.
>  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 ?
>  RFC 2252 (Lightweight Directory Access Protocol (v3): Attribute Syntax
>Definitions) says: 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
>    Whether an object class is abstract,
>   structural or auxiliary is defined when the object class identifier
>    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
>  All extensions to the standard schema should be Aux.
>  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
>