| Deliverables | Table of Contents | Next |

5. Example Directory Tree

This section describes a useful DIT serving an organization with the following requirements:

• A comprehensive White Pages database, i.e. a directory entry for all computer users.

• A functional or task mapping.

• A list of public contacts.

So, in effect, three different views of the organization are available in one directory tree, with public availability possibly being limited by access control.

The structure depicted in Figure 1 is suggested. Any given DIT has its pros and cons, though the following issues should be considered when designing the tree structure:

Data Management In large or distributed organizations local manageability of data can be an important issue, for example a department may be in a better position to maintain data relating to its own people. This is closely related to the access control management issue described below.

Access Control The access control model is flexible enough to cater for most situations. However the shape of a local DIT can go a long way to simplifying the complexity, and therefore manageability, of an access control scheme. This is particularly true of the model suggested in the 1993 version of the X.500 standard.

Searchability In the Quipu implementation used by EuroView subtree searches are demonstrably faster in DITs with fewer levels of hierarchy.

Browsability This is of importance to organizations that wish to reflect an internal hierarchy that is easily navigable by external data users.

Database Size The amount of data will, usually for management and efficiency reasons, reflect on the data hierarchy used. In cases where there a large number of people exist in an organization, a departmental layer may be deemed necessary.

Figure 1. Example Directory Information Tree

5.1 Some Concrete Examples

This section outlines a few example entries that illustrate the above scheme.

5.1.1 Organizational Role

This is an internal entry (i.e. not publicly visible). The example in Figure 2 depicts a role entry that points to the role occupant's personal entry using the roleOccupant attribute. The personal entry points back to the role entry via the seeAlso attribute.

In this example the role entry is held under a placeholder entry, cn=Roles. This has the advantage of simplifying access control for the complete set of role entries, though has the disadvantage of reducing 'searchability', as users may search for the cn=Head of Networking role in its 'logical' position below the ou=Computing and Media Services entry.

Figure 2. Example of an Organizational Role Entry

5.1.2 Public Contact

This entry is intended for the consumption of external directory users. In this example the contact entry has a roleOccupant attribute that points to a personal entry within the organization. Access control may, of course, limit external access to the personal entry, according to local policy.

Figure 3. Example of a Public Contact Entry

6. Appendix A - EuroView Object Identifier Branch

New attributes and object classes defined by the EuroView project will be defined as a sub-branch of the Brunel University Computer Centre object identifier branch. The numeric representation of the EuroView branch is then:

euroView 1.2.826.0.1051.0.2

Attributes and object classes will be placed under sub-branches:

euroViewAttribut euroView.1

euroViewObjectClass euroView.2

| Deliverables | Table of Contents | Next |

Title: Euroview Schema
Issue: 1.1
Date: 08