There are two types of hierarchy in the Directory specs (see esp. X.501).
The first is the subclass hierarchy (rooted at "top"), which can be used
to define subclasses, using the normal object-oriented inheritance kinds
of mechanism. This allows, eg., an organization to extend the org-person
object class with attributes particular to that organization.
The other hierarchy, of concern here, is the naming hierarchy, in which
entries are subordinate to each other. An entry is just a collection
of attributes, with one or more attribute values forming the RDN for the
entry (with the constraint that a given attribute *type* appears at most
once in an RDN). Most attributes can have multiple values, so I might
have a number of CNs, with only one being distinguished.
The specification of what attributes are in what object class, therefore,
gives no indication of which entries may subordinate to one another (eg.
OUs are subordinate to organizations). This was handled informally in
1988, but two new constructs (NAME-BINDING and structure rule) allow formal
specification of these relationships in the 1993 drafts. Eg. I can say
that OU may be subordinate to organization and in such a case the RDN
will be the OU name. (The limit on 4 OUs is from the X.400 ORName, not
the X.500 specs, although that might be a constraint on X.500 names from
the OIW agreements.)
The real problem we are having is that we want to make use of some of the
attributes which aren't normally used for naming (hence don't look nice
in a DN and probably wouldn't be suitable for naming in a real X.500
directory), and we don't have the X.500 directory underneath. This does
all work nicely with a real (somewhat trusted) X.500 directory.
Regards,
Rich