[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ActiveDirectory schema
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.
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
>