Re: Question

[Steve Fisher <s.a.fisher@btinternet.com>]

The descriptions that are given below have a couple of misconceptions.

All entries within a Directory are instances of structural object classes.
Structural object classes represent real world objects,such as people,
buildings (and any other thing that you would care to represent in a
directory). An auxiliary object class is not a more general purpose
structural object class it is a way of augmenting instances of object
classes - i.e. entries within the directory.

For example, there are two entries within the directory one representing
"Joe Bloggs" and the other representing "Ken Barlow". They are both of type
organizationalPerson (i.e. they are instances (members of) of the
organizationalPerson object class). If at some point Ken Barlow has a
certificate generated for him, in order to have this certificate stored in
his directory entry, then his entry must, because the organizationalPerson
object class definition does not include a certificate attribute, be
extended so that the directory will accept the certificate attribute be
added to Ken's entry. This is what the auxiliary object class allows you to
do - extend the object class definition for specific entries.

A content rule is a way of doing something similar to the above, but for all
instances of the structural object class.

The way on which a DIT is structured is defined using DIT structure rules.
These simply describe which object classes can appear at which points within
the DIT and which attributes are used to name (i.e used to construct the
RDN) at each of those points. There are no built in rules and a person entry
can, if the designer of the DIT wishes, appear 'above' an organization
entry.

regards

Steve Fisher

Steve Fisher
BT Syncordia Solutions T&I
0771 310 7125
0118 975 0560
s.a.fisher@btinternet.com

> Comments between brackets below.
>
> bill
>
[snip]
>
> [
> Are you talking here inheritance, i.e. derived and base classes? Can't
> imagine a user would be derived from a book but....
>
> There is the concept in directories of structural and auxiliary object
> classes. Structural object classes are very restrictive. They generally
are
> used to describe a single type of entry and their location in the DIT are
> constrained by structural rules (e.g. an entry based on person class could
> not be above one based on an organization class in the DIT).
>
> Auxiliary object classes are generally more general purpose. Their
location
> in the DIT is not constrained by DIT structure rules. For instance you
might
> create an auxiliary object class with an attribute to hold a PKI
> certificate. PKI certificates can be associated to people, routers,
servers,
> etc. Auxiliary object classes can extend structural object classes through
> the use of content rules. Content Rules allow object classes to be grouped
> (additional attributes can also be added or prohibited as well). So I
might
> create a content rule named PKI-Person which would combine the Person
> structural object class and the PKI auxiliary object class. Entries based
on
> the PKI-Person would then include the attributes associated with the
Person
> class as well as the PKI attribute associated with the PKI auxiliary
object
> class.
>
> If your problem is based on entry inheritance then the earlier comments
are
> correct. An entry inherits from entries above it in the DIT hierarchy. Its
> Distinguished Name (DN)is made up of its Relative Distinguished Name (RDN)
> and all of the RDN in the DIT hierarchy above the entry.
> ]
>
>
>
> I have some ideas, but none that make an awful lot of sense, so help would
> be appreciated.
>
> thanks -
> Steven
>
> Author and Reviewer,
> Professional XML, ASP XML, Beginners XML,
> Pro Site Server, Pro Site Server Commerce
> Wrox Press, http://www.wrox.com
>
> Steven Livingstone
> Glasgow, Scotland.
> 07771 957 280 or +447771957280
> mailto:ceo@deltabis.com
>