3.4 ATTRIBUTE TYPE

As previously stated, attributes consist of an attribute type and one or more values. In order to add a meaningful value to an attribute, it is necessary to have a clear definition of the type of the attribute (both the syntax and the semantics). The attribute's syntax and matching rules define the syntax of the attribute's value(s) and how they can be compared. The attribute type definition defines both the syntax and the semantics of an attribute's values.

Knowledge of an attribute's syntax will stop ludicrous values being added to an attribute. For example, it would not be sensible to be able to add the value 'MacPherson' to an attribute of type 'Age'. However, MacPherson may be a very sensible value for an attribute of type 'Front suspension'. Through knowledge of an attribute's ASN.1 syntax (in this case 'Age' would be defined to be of type integer, and 'Front suspension' of type Directory String), an implementation will be able to control this sort of ludicrous addition to the Directory database.

One further control that can be placed over values of an attribute, is the range, or size of the value. Thus it is possible to limit an 'Age' attribute to lie in the range 1 to 120, and 'Number of Children' to the range 0 to 10. A string attribute could be limited to 20 characters. Restricting the size of an attribute's value(s) is done at the time that the attribute type is defined (w/w 3.1). Through knowledge of the size restrictions applying to an attribute, an implementation can stop outrageous values being added to an attribute. Thus a value of 99 could be added to an 'Age' attribute, but not to a 'Number of Children' attribute.

Attribute type definitions also contain a description of the semantics of the attribute. Many attributes may share the same syntax, but apply different meanings to the values. For example, the attribute types 'common name' and 'description' share the same syntax ('Case Ignore String' syntax in the '88 Standard, and 'Directory String' in the '93 Standard), but have different semantics applied to them. Whereas 'The Information Technology Institute (ITI) was set up jointly by Government and Industry to teach information technology to undergraduates' could be a good description of the ITI's entry in the DIT, it would not be a good common name for the entry. Controlling the addition of values to an attribute, that meet the defined semantics, is therefore much more problematical, and hard to incorporate into an implementation. This must usually be left up to the user of the Directory. The implementation would only be able to control the length of a string, and not its meaning.

Besides knowing the type of the attribute, one needs to know whether single or multiple values can be added. An attribute of type 'Age' should be single valued (except perhaps for people born on February 29), whereas 'telephone number' could quite sensibly be multi-valued. When defining an attribute's type, it is also necessary to state whether it can be multiply valued or not. Perhaps surprisingly, the default is multi-valued, so that single valued attributes are the exception.

Additional components are needed in the '93 definition of an attribute type. We have already covered the fact that the matching rules need to be individually specified for each attribute type, whereas in the '88 Standard this was implicit in the attribute syntax definition. Also, since the information model is much richer in the '93 Standard, attributes now have to be classified more precisely. The '88 Standard did not differentiate between types of attribute. The '93 Standard does. So the '93 definition must now say whether the attribute is a user, user collective, Directory operational, DSA shared operational, or DSA specific operational attribute. The default is 'user', since this was the only type of attribute defined in the '88 Standard. If the attribute is an operational attribute, it is also necessary to state whether the DSA software, or the (administrative) user, keeps the attribute value(s) up to date. For example, the modify timestamp attribute is only updated by the software, but the EntryACI (access control) attribute is updated by the (administrative) user. The default is for the user to update the attribute. Finally, the '93 Standard has introduced the concept of attribute hierarchies. If an attribute is a sub-type of an already defined attribute type, its definition should make this clear (Fig. 3.8). Hence '93 attribute type definitions are often more complex than '88 ones, but due to the clever use of the defaults, '93 user attribute definitions are very similar to '88 definitions.

Finally, every attribute type has to have a good old object identifier associated with it. This is essential for attributes - both '88 and '93 ones - since the protocol messages passed between components of the Directory system use an attribute's object identifier to identify the accompanying attribute values. Attribute object identifiers are also used in the Directory system schema, for controlling the types of attribute that may be added in an AAA (§ 3.13). Each attribute type defined in the Standard is allocated an object identifier. When organisations define their own attribute types, they need the ability to attach an object identifier to it. Appendix A briefly describes how organisations can obtain their own object identifiers.

3.4.1 An Example of a '88 Attribute Type Definition - Country Name

As an example of an attribute type definition, Fig. 3.7 shows the definition of country name as it appears in the '88 Standard.


Fig. 3.7 The '88 definition of the Country Name attribute type, from Part 6 of the Standard.

The opening paragraph defines the semantics of this attribute type. From line one of the ASN.1 ATTRIBUTE Macro, one can see that the value reference for the attribute type is countryName. This reference will subsequently be used in an object class definition (§ 3.5). From lines two and three one can see that the attribute's syntax is a PrintableString, of size two characters, with the two characters being the ones defined in the standard ISO 3166 [7.2]. This standard assigns two character mnemonics to all countries in the world, for example, the United Kingdom is assigned the characters 'GB', and the United States of America the characters 'US'. Because PrintableString is not a pre-defined attribute syntax - it is an ASN.1 type - no matching rules exist for it. Therefore the matching rules have to be included in the attribute type definition (i.e. the attribute syntax is defined in situ). Only equality matching is defined for country names, and this is stated to be the same as for case ignore strings (it thus is not possible to match on countries, say beginning with the letter 'G', which requires substring matching to be supported).
Note. Implementations may always support extra matching rules such as substring match, and approximate match e.g. so that UK matches GB.

Line five of the macro states that the attribute can only be single valued, whilst line six assigns the object identifier 2 5 4 6 to the countryName attribute type (attributeType is assigned the object identifier 2 5 4 in Annex B of Part 2 of the Standard).

3.4.2 The Corresponding '93 Definition


Fig. 3.8 The '93 (draft) definition of the Country Name attribute type.

By way of contrast, Fig. 3.8 shows the '93 definition of the same attribute. This time the definition uses the ASN.1 Information Object Class notation, instead of the ASN.1 Macro notation.

As country name is now a subtype of the generic name attribute, that definition is also included in Fig 3.8. In fact, the '88 and '93 definitions are almost identical (even though the syntax of the definitions is considerably different, see w/w 3.4). The only changes are those due to the inheritance of the extra matching rule (SUBSTRINGS) which has come from the 'name' super-attribute type. This means that, for example, a '93 system will be able to match on country starts with 'c', which an '88 system could not do. One other small difference is that 'id-at-xxx' has replaced the value reference to the object identifier attributeType n. This is a useful substitution, as confusion was sometimes caused by the '88 Standard using the same term (attributeType) for two different concepts. The actual value for the object identifier, 2 5 4 6, has remained the same. The '93 definition tells us that the country name attribute is not a collective attribute, nor an operational attribute, since the default is user attribute.

3.4.3 The Common Name '88 Attribute Type Definition


Fig. 3.9 The '88 definition of the Common Name attribute type.

As a final example, Fig. 3.9 shows the definition of common name as it appears in the '88 Standard. The opening paragraph describes the semantics of this attribute type, whilst the second paragraph tries to constrain values that may be given to the string. One can see how difficult this is in an international standard! After the examples, the reader is told that alternative variants of the name should be added to the attribute as other values. So the values of the common name attribute in a Directory entry might be :

David Chadwick
Dr D W Chadwick
Dave Chadwick
Dr David Chadwick
etc.

One of these would be chosen as the distinguished value, to form the RDN. The other values would be useful for people searching through the Directory to find it.

On examining the ASN.1 macro, one can see that the value reference for this attribute is commonName (line 1), that the attribute has the case ignore string syntax (line 3), that the string size should be between 1 and ub-common-name (defined in Annex C of Part 6 to be 64) characters (w/w 3.1) and that the object identifier assigned to this attribute is 2 5 4 3. The attribute can be multi-valued, because the SINGLE VALUE constraint is not imposed.
Note. The Attribute Type Macro Definition states that instances of the macro should include SINGLE VALUE, MULTI VALUE or nothing. If nothing is present, MULTI VALUE is taken to be the default.

3.4.4 The Common Name '93 Attribute Type Definition

By way of comparison, Fig. 3.10 reproduces the '93 definition of the common name attribute type. Apart from the notation, these definitions are identical.


Fig. 3.10 The '93 definition of the Common Name attribute type.

3.4.5 Examples of Standardised User Attributes

In order to give you an idea of the sorts of user attribute that are defined in the Standard, a brief list is given in Table 3.2. (You should be able to consult the Standard now and understand all the definitions.) If the column titled 'Collective Variant' is marked yes, then the Standard has defined both a user, and a user collective, attribute of this type. Collective attributes have all been defined as subtypes of their non-collective counterpart. Their syntax and semantics are the same, except that the collective variant applies to a collection of entries, rather than a single entry. (Remember that collective attributes can only be stored in subentries, and apply to all the entries described by the subtree specification, whereas user attributes are stored in entries and only apply to that entry.) So for example, the 'collective facsimile telephone number' attribute type is defined as a subtype of the 'facsimile telephone number' attribute type.

Table 3.2 A selection of standard user attribute types

Attribute Type
Collective Variant
Description
Aliased Object Name
No
 Points to the entry that this is an alias of 
Description
No
 Describes the object whose entry this is
Facsimile Telephone Number
Yes
 The fax number on which you can contact the object (person) described by this entry 
Role Occupant
No
 The distinguished name of the person who occupies this role 
Search Guide
No
 Contains suggested criteria for building Search filters, to be used for searching the subtree below this node 
Member
No
 Lists the names of the entries that make up this group 
Owner
No
 The name of the 'owner' of this entry
Object Class
No
 The class of object this entry is
Post Office Box 
Yes
 The PO Box number through which you can contact the object (person) described by this entry 
Presentation Address
No
 The presentation address of the OSI application entity described by this entry 
User Certificate 
No
 The certified public key of this Directory object 
A few words of explanation about some of the attributes might be useful:

3.4.6 Defining Your Own Attribute Types

Administrators of the Directory are always free to define new attribute types to suit the specific needs of their organisation, subject only to the limitations of their implementation. Chapter 10 gives some examples of the huge range of attributes that have already been defined by communities of users. When defining new attribute types, administrators may use either a natural language description only, or a combination of this and a formal/private syntax defined by their implementations. The use of the ASN.1 macro or information object notation is a shorthand convenience invented by the Standards writers, but it is being used extensively by communities of Directory users. The essential thing one needs to ensure is that all the components of the definition are included. To summarise, these are:

3.5 OBJECT CLASSES

The next step, after controlling the types and values of attributes, is to control which attributes can be placed in which entries. This is achieved primarily via the concept of object classes. Every entry that is placed in the Directory is, in the '88 scheme, a member of precisely one class of objects. All objects in the same class share the same characteristics. When this concept is applied to the Directory, it means that all Directory objects that are in the same object class, are likely to have the same set of attribute types in their entries. Of course, different entries will have different values for their respective attribute types, but a user of the Directory can have confidence when accessing an entry of a particular object class, that a particular attribute type is likely to be present. I say likely to be present, and not definitely present, because in the definition of object classes, some attribute types must mandatorily be present in an entry, whilst others may be only optionally present. The optional choice is allowed, because some objects may clearly be of the same class as other objects, even though they do not all possess a certain attribute. As an example, some employees of an organisation may have a telephone, or computer, or fax machine in their office, whilst others may not have. An employee with access to a particular piece of equipment would have an attribute in their entry, giving their 'telephone number', 'Email address' or 'fax number', respectively. Employees without access to such facilities would not have the corresponding attributes in their entries. However, all employees would be of the same object class, and all would have a 'common name' attribute, a 'surname' attribute, and any other attributes that the organisation deemed as necessary in order to characterise their employees.

So, the formal definition of an object class involves specifying:

The '88 Standard also has one other minor difference and that is that the object identifier is optional. If an object identifier is not assigned to a new object class, then it is said to be an unregistered object class (§ 3.8).

3.5.1 Subclassing

A well known technique in the field of object oriented design, which simplifies the definition of objects, and allows complex objects to be built up from simpler ones, is the mechanism known as subclassing. When an object is said to be a subclass of another, more generic object - the superclass - then the subclass inherits all the properties of the more generic superclass, and in addition, has some further limiting criteria imposed on it. As an example, this can be applied to living creatures. Mammals are a subclass of living creatures (mammals are living creatures that in addition are warm blooded and suckle their young). Prototheria are a subclass of mammals (prototheria are mammals that in addition lay eggs). Prototheria we know are warm blooded and suckle their young, because they have inherited these properties from the fact that they are a subclass of mammals. When subclassing is applied to Directory object classes, it means that a subclass inherits all the mandatory and optional attributes of the superclass, and in addition has further mandatory and/or optional attributes defined for it.

Fig. 3.11 An example of the object class inheritance hierarchy.

The Standard has defined one object class that is the most generic of all, and this is called top. All other object classes are subclasses of top. (This restriction has been slightly relaxed in the '93 Standard, see § 3.5.3 and w/w 3.2.) Whatever attributes are defined for top, will be inherited by all other Directory object classes. Figure 3.11 shows part of the object class hierarchy defined in the Standard, with a particular emphasis on 'person' objects. The accompanying Venn diagram, shows that 'person' objects are a subset of top objects (these are really the set of all Directory objects), and that organisational person's are a subset of person's.

3.5.2 Kinds of Object Class

Formally, the definition of an object class has changed slightly between the '88 and '93 editions of the Standard. '93 has introduced different kinds of object classes. '88 only recognised one kind (sounds a bit like the attribute type enhancements again!). The '93 Standard notes three different kinds of object class.
  1. The structural object class describes aspects of the object, and dictates (via associated DIT structure rules and name forms) whereabouts in the DIT, entries of this class can be placed. For example, the organisational person object class, is used to define attributes of a person in their organisational capacity. This object class is also used, via DIT structure rules and name forms, to determine where people may be placed within the organisation's part of the DIT.
  2. The auxiliary object class is used to group together characteristics of an object, without affecting its position in the DIT. For example, the object class MHS-User (§ 10.2.1), defined in the X.400 standard, packages together the attributes needed to describe an X.400 user (such as the MHS-OR-Addresses attribute). This can be attached to all sorts of person entries (organisational and residential) irrespective of their position in the DIT.
  3. The abstract object class is only used for convenience when specifying the highest levels of the object class hierarchy, and will never be used to classify actual DIT entries. Top and alias are almost the only examples of abstract object classes.
Each object class must now be classified as one of the above kinds, when it is defined. Since most '88 object classes are structural, this is taken to be the default for kind in the '93 definition.

3.5.3 The Object Class 'Top'


Fig. 3.12 The definition of object class 'top'.

As an example, Fig. 3.12 shows the definition of the object class top, as it appears in the Standard. Note again the use of the ASN.1 Macro notation ('88 Standard) or Information Object Class notation ('93 Standard) as a compact way of recording part of the definition.
Note.  ASN.1 Information Object Classes are not related to Directory Object Classes. It is unfortunate that the term object class is so widely used.
The textual part of the definition records that all other object classes must be a subclass of top (in the '93 Standard this is relaxed to all structural object classes). The value reference for the definition is top. Line two of the Macro, line 3 of the Information Object, states that all objects of class top (and therefore all its subclasses) must contain the objectClass attribute (§ 3.5.4). Line 2 of the Information Object says that top is an abstract object class. The last line assigns top an object identifier of 2 5 6 0 (Annex B of Part 2 assigns an object identifier of 2 5 6 to objectClass.) Note that the value references to objectClass in lines 2 and 3 of the Macro are actually to two different object identifiers, but the context makes it clear that the first one is to an attribute called objectClass, and the second one is to the object identifier stub that is the common precursor to all object class object identifiers. This confusion has been removed in the '93 Standard by the definition of an alternate value reference, id-oc-top, for the object identifier of 'top'. (The OID still remains the same.)

Top has just one mandatory attribute type defined for it, and this is the objectClass attribute. (The objectClass attribute says what type of object a particular entry describes.) Since all (structural) object classes are subclasses of top, all (structural) object classes inherit the mandatory attribute objectClass. Thus all entries in the Directory must have an objectClass attribute (as well as any other attributes that are defined for their particular object class).


Fig. 3.13 The definition of the objectClass attribute.

3.5.4 The Object Class Attribute

The objectClass attribute as defined in the Standard, is shown in Fig. 3.13. From the definition we can see that the objectClass attribute indicates what the object class of an entry is. The attribute is multi-valued (the default for attributes). If the object class of an entry is a subclass of a more generic superclass, then the whole superclass chain should be present in the objectClass attribute. (In the case of multiple inheritance - see § 3.7 - all the superclass chains would be present.) From the second line of the Macro or Information Object notation, we can see that values of this attribute have the OBJECT IDENTIFIER ASN.1 syntax (a sequence of positive, including zero, integers). Take for example, an entry of object class organisationalPerson. As shown in Fig. 3.11, organisationalPerson object class is a subclass of person object class, and person object class is a subclass of top. Therefore an organisationalPerson entry in the Directory would contain an objectClass attribute with three object identifier values: 2 5 6 0 (top), 2 5 6 6 (person), and 2 5 6 7 (organisationalPerson) (Fig. 3.14). However, the Standard does note that it is not obligatory for entries to hold the value of top in their objectClass attribute, since all entries must have this value. The third line of the Information Object Class Notation identifies the equality matching rule to be used for values of this attribute. In the Macro notation this is bundled in with the attribute syntax definition.

3.5.5 Further Examples of Object Classes

Figure 3.14 shows the definitions for the person and organisational person object classes. Person object class is a subclass of top, and the only attributes it must contain are commonName, surname and objectClass. Entries of this object class are also optionally allowed to contain four additional attributes.
  1. A description attribute is text to describe the person.
  2. seeAlso contains the name(s) of one or more other entries in the Directory which contain further information about the same real world thing e.g. there could be an organisational person entry and a residential person entry in the Directory, with each entry containing different information about a person, and each entry having a seeAlso attribute to the other. (Note the difference between the seeAlso attribute and the aliasedObjectName attribute of an alias entry. The latter is the pointer to the real entry, and only one set of entry information exists in the DIT.)
  3. telephoneNumber contains the telephone number(s) through which the person can be contacted.
  4. userPassword contains one or more passwords for the person.
Person object class is assigned the object identifier 2 5 6 6.

An organisational person is a subclass of a person object class. No more mandatory attributes are necessary for these entries, although 18 further optional attributes may be added to them.

  1. localeAttributeSet comprises a set of three attributes which may be used to describe the geographical locality of the person. They are localityName, stateOrProvinceName and streetAddress.
  2. organisationalUnitName contains the name of the department, division or unit that the person works in. If the unit has alternative names, then multiple values would occur in the entry. This attribute would only need to be present in the entry, if the distinguished name of the person did not already contain an OU component.
  3. postalAttributeSet contains a set of five attributes which describe how the person may be contacted via the postal service. The individual attributes are physicalDeliveryOfficeName, postalAddress, postalCode, postOfficeBox, and streetAddress.
  4. telecommunicationsAttributeSet comprises facsimileTelephoneNumber, internationalISDNNumber, telephoneNumber, teletexTerminalIdentifier, telexNumber, preferredDeliveryMethod, destinationIndicator, registeredAddress and x121Address, most of which are self explanatory.
  5. title holds the person's title. If the person has more than one title, then the attribute may have multiple values.

6.7 Person                                                             6.5 Person

The Person object class is used to define entries representing people generically.
 
'88 Macro notation 

person OBJECT-CLASS 
SUBCLASS OF top 
MUST CONTAIN { 
commonName, 
surname} 
MAY CONTAIN { 
description, 
seeAlso, 
telephoneNumber, 
userPassword} 
::= {objectClass 6} 

 '93 Information Object notation 

person OBJECT-CLASS ::= { 
SUBCLASS OF top 
MUST CONTAIN { 
commonName| 
surname} 
MAY CONTAIN { 
description| 
seeAlso| 
telephoneNumber| 
userPassword} 
ID {id-oc-person} } 
 

6.8 Organizational Person                                 6.6 Organizational Person

The Organizational Person object class is used to define entries representing people employed by, or in some other important way associated with, an organisation.
'88 Macro notation 

organizationalPerson OBJECT - CLASS 
SUBCLASS OF person 
MAY CONTAIN { 
localeAttributeSet, 
organizationalUnitName, 
postalAttributeSet, 
telecommunicationAttributeSet, 
title} 
::= {objectClass 7} 

 '93 Information Object notation 

organizationalPerson OBJECT-CLASS ::= { 
SUBCLASS OF person 
MAY CONTAIN { 
localeAttributeSet| 
organizationalUnitName| 
postalAttributeSet| 
telecommunicationAttributeSet| 
title} 
ID {id-oc-organizationalPerson} } 


Fig. 3.14 The definitions of the Person and Organisational Person object classes.

Note that the use of attribute sets is purely a notation convenience, so that common sets of attributes may be grouped together. Then the same set of attribute types can be easily introduced into several different object class definitions by a single line of text, rather than having to repeat the whole set each time. Attribute sets are not visible in the Directory service or protocol.

Finally, the object identifier 2 5 6 7 is assigned to the organisational person object class.

3.5.6 The Standardised Object Classes

Table 3.3 lists all of the object classes that are defined in the '88 and '93 editions of the Standard. (The '93 Standard also defines some object classes for controlling subentries, see § 3.12). Note that this is meant to be a commonly usable subset of object classes, and organisations will be expected to create their own as the need arises.

Note that none of the object classes are allowed to contain collective attributes in their lists of mandatory and optional attribute types. Only normal user attributes can be placed there. Collective attributes are sanctioned for an entry via the DIT content rule for the entry (§ 3.8.1).

Table 3.3 The object classes defined in the Standard

Selected Object Classes
Standard Object Class Used to Characterise 
Top All DIT entries 
Alias Alias entries 
Country Country entries 
Locality Locality entries such as: State, Region, County or Department 
Organization  Organisation entries 
Organizational Unit   Organisational unit entries such as: Division, Unit or Department 
Person Generic properties of people's entries 
Organizational Person Entries for people within their organisation
Organizational Role   Role entries such as: Chairman, Managing Director, or Vice President 
Group of Names Entries which hold a list of names such as: mailing lists, team membership, or committee members 
Residential Person Entries for residential people
Application Process Entries for application processes
Application Entity Entries for application entities
DSA Entries for DSAs 
Device  Entries for physical devices such as: modems and line printers 
Strong Authentication User  Entries which can strongly authenticate each other such as: DSAs and organisational people 
Certification Authority  Entries for certification authorities