X500Standard.com

As discussed in the section on object classes, an entry is created based on one and only one structural object class and possibly one or more auxiliary object classes. The structural object class gives the basic definition of what attribute types shall and what attribute types may be represented in the entry.

If more attributes are required than those specified by the structural object class, additional attributes can be included by use of auxiliary object classes as also explained in the section on object classes. However, before this can be done, a content rule has to be associated with the structural object class.

The content rule includes the following specifications:

1. The identity in form of an object identifier of the structural object class for which the content rule is defined. Note that there can only be one content rule for a given structural object class within a closed area controlled by a given set of schema definitions (subschema specific administrative area).
2. The identity in form of object identifiers of those auxiliary object classes that may be combined with the structural object class for creation of an entry. If this specification is not included, no auxiliary object classes can be applied. The standard does not require that all auxiliary object classes listed actually be applied for a particular entry. However, it will be up to the actual implementation to what level the administrator has the ability to specify the auxiliary object classes to be applied for specific entries.
3. Listings of additional mandatory and/or optional attribute types for the entries beyond those specified by the underlying object class(es). This alternative or rather a supplement to defining auxiliary object classes to include additional attributes. This specification is only supplied if there are such additional attribute types.
4. Attribute types that are optional according to the underlying object class(es) can be prohibited.
5. Some additional information.
6. Obsolete: don't use it - just delete the definition.

Content rules for different structural object classes are stored in a multi-valued operational attribute called dITContentRules. This attribute is stored in the subentry for the subschema specific administrative area. This is illustrated in the figure, where each row in the figure is an attribute value that holds the specification of a content rule. Such a value is a sequence of data items each specifying an aspect of the content rule.

An entry may have an operational attribute (subschemaSubentry) that point to the subentry that holds the content rules. From the entry is therefore possible to access the content rule for that entry. An implementation may provide other means for locating subentries made available to the local administrator.

All the above are mechanisms that to some degree are handled automatically by the implementation. However, the administrator has in some way to define the content rules to the system.

According to the X.500 specifications, auxiliary object classes included in a structure rule do not necessarily have to be reflected when entries are created according to that structure rule. However, administrators should be aware that when adding entries using local administrative tools, the implementation might take object class information from the applicable structure rule instead of requiring the administrator to supply that information for each individual entry. If that is the case, auxiliary object classes may specify some mandatory attribute types not relevant for all entries. When loading such entries, the load will fail. For the same reason it advisable that auxiliary object class should not specify any mandatory attribute types, but to define all attribute types as optional.

When an administrator is to include attribute types, e.g. locally defined attribute types that are not reflected by existing object classes, then there are two choices:

1. add the attribute types directly into the structure rule; and
2. generate a new auxiliary object class including these attribute types and then add this auxiliary object class to the structure rule.

It is recommended to define a new auxiliary object class.

It may be considered cumbersome to define new auxiliary object classes just to include a few new special attributes required in special situation, and it may therefore be tempting to tamper with existing specifications to avoid this. Typically, a directory implementation has not hard-coded the object class and attribute type definitions, but has provided them in a definition file. Such a definition file could in principle be changed without having the system objecting.

Such tampering should not be done!

Such tampering will impede interworking with other DMDs and may cause much reworking later to accomplish such an interworking. More details on this are given in the following:

• Schema publication is a tool for DUAs and administrators in other DMDs used to retrieve information about what schema definitions are used within a particular subschema specific administrative area. There is no way that a recipient of such information can detect that the underlying schema definitions have been changed.
• If a syntax of a defined attribute is changed, it will
  • confuse the DUA unless the DUA is changed to understand the new syntax;
  • results in an undocumented system;
  • the old syntax may be wanted at some later time;
  • matching may fall apart as the default matching rules are associated with attribute types.
• If an attribute type is deleted from an object class definition, a user may try to add this attribute type to an entry believing this is a valid operation. However, the operation will be rejected. The user will see the system as a faulty system.