Chapter 9

The distributed Directory in more detail


In Chapter 4 we were introduced to the basic workings of the distributed Directory. This chapter delves into greater depths. Fundamental to the functioning of the distributed Directory is the storage and use of distribution meta-information (the knowledge references), which are held by all the DSAs in the distributed system. The different types of knowledge reference specified in the Standard are explained in § 9.2. The protocol transportation of knowledge references between DSAs, as Access Points and Access Point Information, is described in § 9.3. The model for the holding of knowledge references by a DSA, as part of its DSA Information Tree, is introduced in § 9.4. The way that a DSA should map between this internal model and the protocol representation is briefly discussed in § 9.5. An example of the use of knowledge references in distributed name resolution is given in § 9.6.

The root of the DIT causes problems from a managerial and operational perspective. The Standard has stated that First Level DSAs should co-operate to manage the root of the DIT, but no guidelines are given as to how this might be achieved. Several sections, 9.7 to 9.9, look at what First Level DSAs are, what information they are obliged to hold, how they might function, and how administrators might co-operate to share knowledge about the root of the DIT. This discussion is then extended to the management of a country's entry and an organisation's naming context.

The modes of interaction between DSAs, termed chaining and referrals, were introduced in Chapter 4. The '93 Standard has introduced some new terminology in this area, and removed some old terminology i.e. multicasting. This will be explained fully in § 9.10 to § 9.12. How the DSAs co-operate to answer a user's query, by adding 'state' information to the request, was also introduced. The parameters that make up this 'state' information - the Chaining Arguments - are fully described in § 9.13.

The '93 Standard has introduced the new concept of Operational Bindings, as explained in Chapter 4. In § 9.15 to § 9.18 of this chapter, the generic parameters that make up the Directory Operational Binding Management Protocol are described, and in § 9.19 and § 9.22 the specific parameters of the Hierarchical Operational Binding are explained.


All knowledge references logically comprise the same information. This is: The '88 Standard defined four types of knowledge reference: superior reference, subordinate reference, non-specific subordinate reference and cross reference.

The '93 Standard added to these: immediate superior reference, supplier reference, consumer reference and master reference. The latter three arose from the work on replication (shadowing).

Each knowledge reference only points to one DSA (w/w 9.1). It can be seen that once subtrees/naming contexts are replicated, there may be several remote DSAs that hold copies of the same subtree. There could therefore be several Access Points/knowledge references associated with the same DIT name. However, one of these Access Points (or knowledge references) will be in a different category to the rest. This is the knowledge reference that points to the DSA holding the master copy of the naming context, and it is called the master reference. Shadow references, on the other hand, are knowledge references that point to DSAs holding shadow copies of (possibly part of) a naming context.

Within the DSA Information Model, both categories of knowledge reference are actually stored together in one complex attribute type e.g. the specific knowledge DSA shared operational attribute - see § 9.4. Within a particular knowledge attribute value, each Access Point has a flag to indicate whether it is the master or a shadow reference. In this way the DSA knows which knowledge reference is to the master copy of the naming context, and which are to shadow copies of the naming context.

Within the Directory protocols, both categories of Access Point are carried together in one construct (Access Point Information - see § 9.3). Again, these Access Points are flagged as being master or shadow Access Points. Therefore the DSA receiving this information is able to tell which access point points to the master DSA, and which point to shadow DSAs.

9.2.1 Superior Reference

A superior reference is a knowledge reference that points upwards in the DIT, towards the root. The Access Point can be that of any DSA that holds a naming context that is higher in the DIT than all the naming contexts held by the referencing DSA. The name of the DIT entry that is pointed to by a superior reference is the root of the DIT (from the perspective of the DSA holding the superior reference, the reference does in fact point to a DSA which is a proxy for the root of the DIT). Hence the name component of a superior reference is null, and so is omitted.

When configuring a superior reference into a DSA, an administrator might, subject to bilateral agreement, use one of its immediately superior references.

9.2.2 Subordinate Reference

A subordinate reference is a knowledge reference that points downwards in the DIT, to a naming context that starts immediately below an entry. The DIT name being pointed to, is therefore the RDN of the particular subordinate. (The RDN of a subordinate is sufficient to differentiate between it and all the other subordinates of an entry.) The Access Point of a subordinate reference points to a DSA holding a (master or shadow) copy of this particular subordinate naming context.

A DSA holding several subordinate references therefore knows which subordinates of an entry are held in which remote DSAs (assuming that an entry has two or more subordinates held in different remote DSAs). It also knows which subordinates do not exist, since it either holds all the subordinate entries itself, or it has subordinate references to the ones that it does not hold.

9.2.3 Non-specific Subordinate Reference (NSSR)

There is another type of subordinate reference, the non-specific subordinate reference, in which the RDN of the subordinate is not held by the referencing DSA (w/w 9.2). The referencing DSA therefore only knows that a remote DSA holds some of the subordinates of a particular entry, but not precisely which one(s). The referencing DSA therefore cannot tell which subordinates exist, and which do not. If the subordinates of a particular entry are shared between more than one remote DSA, then the referencing DSA does not know which remote DSA holds which subordinates. Non-specific subordinate references therefore significantly complicate the process of distributed name resolution, and have caused several extra parameters to be added to the Directory protocols (§ 9.11 and § 9.13.16).

For a non-specific subordinate reference, the Access Point is to a DSA which holds a copy of one or more subordinate naming contexts, and the name (RDN) of the DIT entry that is being pointed to, is unknown. You can think of the RDN being a wildcard, or 'any', i.e. the referenced DSA holds subordinates that may have any RDN.

9.2.4 Immediate Superior Reference

An immediate superior reference is a knowledge reference that points upwards in the DIT, to the naming context that is immediately superior to the referencing one. The Access Point is to a DSA holding a copy of the immediately superior naming context, and the DIT name that is being pointed to, is the context prefix of the immediately superior naming context. (Remember that the immediately superior naming context may start several levels higher in the DIT than the current one, and therefore one cannot assume that the DIT name is simply the current context prefix minus the last RDN.)

Immediate superior references are needed for hierarchical Operational Binding management. They are also useful during distributed name resolution.

9.2.5 Cross References

The next type of knowledge reference, which is entirely optional for any DSA to hold, is the cross reference. A cross reference points directly to any remote naming context. The DIT name being pointed to, is therefore the context prefix of the remote naming context, and the Access Point is that of the remote DSA which holds (possibly a copy of) the remote naming context.

Cross references enable the process of distributed name resolution to proceed far more quickly and efficiently than when they are absent. They allow a DSA to bypass the normal mechanism of distributed name resolution (§ 9.6), since the DSA can pass the operation directly across the DIT to a DSA nearer to the entry. Cross references point arbitrarily across the DIT, and usually will be held by DSAs that frequently access remote portions of the DIT.

9.2.6 Supplier Reference

A supplier reference is held by a shadow consumer DSA, and points to the DSA that is supplying the shadowed information. Since a shadow consumer DSA may hold information copied from many different suppliers, each supplier reference is associated with the DIT name i.e. context prefix, of the naming context that is being shadowed. It is also tagged with the shadowing agreement ID, so that each supplier reference is coupled to a particular shadowing agreement.

A supplier reference may be used by a DSA during name resolution, when the operation needs to be directed to the master copy of an entry, for example, if the operation is a modify operation or the user has set the 'do not use copy' service control. A supplier reference is held as part of the supplier knowledge attribute in the context prefix of the naming context which is being (possibly partially) shadowed.

9.2.7 Master Reference

A master reference may optionally be held by a shadow consumer DSA, as part of the supplier knowledge attribute. It points to the DSA which holds the master copy of the naming context which is being (possibly partially) shadowed. As we learnt in Chapter 6, because of secondary shadowing, the master DSA is not always the supplier DSA.

9.2.8 Consumer Reference

A consumer reference is held by a shadow supplier DSA. It points to a DSA that the supplier DSA is supplying with a (possibly partial) copy of a particular naming context. The DIT name that this reference is associated with, is the context prefix of the naming context that is being replicated. Consumer references are tagged with a shadowing agreement ID, so that it is apparent which consumer reference is associated with which shadowing agreement.

Consumer references are held in the consumer knowledge attribute. Consumer references are never used during name resolution, but are used for propagating updates to shadows.


In 1988, Access Points (of knowledge references) carried in the Directory protocols (as part of the Continuation Reference parameter) were relatively simple, consisting solely of the name and presentation address of a DSA. In 1993 they have been significantly extended, due to a number of reasons, but primarily due to replication. A Continuation Reference now holds a construct known as Access Point Information. It is important to note that this extension has been introduced in a (backwards and upwards) compatible manner, so that an '88 DSA can still effectively communicate with a '93 DSA and vice versa.

One reason for the extension of access points, is due to the choice of lower layer protocols that a remote DSA may support. Each Access Point may now optionally carry, in a Protocol Information parameter (Fig. 9.1), the protocols and profiles that are supported by the underlying transport and network layers of the remote DSA's presentation address. This allows a calling DSA to use the received access point information efficiently, without having to test, by trial and error, many different lower level protocol combinations. Of course, '88 DSAs will always ignore this parameter, due to the rules of extensibility (§ 5.19).

With the introduction of replication, each Access Point is now categorised as being either a master or shadow access point (Fig. 9.1). If the categorisation flag is missing, master is assumed (i.e. master is the default). Thus '88 DSAs are always assumed to pass in protocol the access points of master copies of naming contexts (since they will never append the categorisation flag). Only '93 DSAs may flag access points as being to shadow copies of naming contexts, and '88 DSAs will always ignore this flag, due to the rules of extensibility (§ 5.19).

Furthermore, access point information now consists of one specially selected access point, followed by a set of optional additional access points. The logic behind this is as follows. An '88 DSA will always generate, and expect to receive in the Directory protocols, just one access point, since this was all that was defined in the '88 Standard. A '93 DSA will treat an '88 generated access point as the specially selected access point. A '93 DSA, about to generate access point information, may have available to it a set of access points, which all reference different DSAs holding copies of the same naming context (due to replication). When generating the access point information it will choose the best access point from the set, sending this as the first component of access point information, and the remainder as the second component - see Fig. 9.1. (It might be sensible for '93 DSAs to always choose the master access point as the specially selected one.) An '88 DSA receiving access point information from a '93 DSA, will only use the specially selected access point. It will ignore all the additional access points, as it does not expect nor understand them. A '93 DSA receiving access point information may choose the specially selected access point, or may choose any access point from the additional set. Only one access point from access point information is initially chosen, since all the DSAs point to copies of the same naming context. If the DSA pointed at in the chosen access point cannot reply, for example, it is down, or it responds with a soft error (§ 9.12), then the '93 DSA is free to choose another access point from access point information.

One additional complication arises (as always) from NSSRs. In the '88 Standard the only time that a DSA would forward a set of access points to another DSA, would be when it encountered a set of NSSRs at an entry during name resolution. Each of these access points needs to be followed by

Fig. 9.1 Access Point Information.

the receiver, in order to contact all of the subordinates of the entry. In the '93 Standard, it is recognised that each DSA pointed to by a NSSR may have replicated its naming context(s), and therefore we may now have a set of access points arising from each NSSR. We thus may have a set of sets of access points! At least one DSA from each set of access points needs to be contacted, in order to contact the complete set of subordinate entries. Thus, in the case where NSSRs have been encountered, the set of access points is now replaced by a set of access point information (§ 9.11).


How are DSAs modelled as holding all this knowledge information? Clearly some knowledge references are received in protocol, either as Continuation References in Referrals and in Partial Search Results, or as parameters of Operational Bindings (both hierarchical and shadowing) or as returned cross references (§ 9.13.7). Other knowledge references will be configured in via the management interface. All this knowledge information needs to be stored somewhere. It will subsequently be retrieved during name resolution or operation evaluation, either for direct use when initiating a Bind operation, or for packaging as a Continuation Reference in an outgoing message.

Knowledge references are modelled as being held in DSA specific and DSA shared operational attributes. If the contents of a knowledge reference are specific to a single DSA, then they are held in a DSA specific operational attribute. If the contents of a knowledge reference may be shared by all the DSAs that hold it, then it is held as a DSA shared operational attribute. An example of the former would be the superior knowledge attribute, used for holding the superior reference. Whilst all non First Level DSAs hold a superior reference, most of them will point to different DSAs. The value is therefore not shared by all DSAs. An example of the latter is the specific knowledge attribute, used for holding subordinate and cross references. This points to all the DSAs that hold copies of a naming context. Clearly these values will be the same whichever DSA holds them. (Whilst some DSAs will hold this attribute as a subordinate reference, and others as a cross reference, this difference is flagged via the DSE type bit - see Table 2.1. The values of the attribute do not change. (In reality, because of security or other operational reasons, the access point values held by some DSAs may be different i.e. not all DSAs may know about the complete set of DSAs holding (possibly partial) copies of a particular naming context. All DSAs will hold a subset of the complete set of access points.) Table 9.1 lists the different types of knowledge attribute that have been defined, along with the knowledge references that they can be used to represent. The only thing left to determine, is in which DSEs they are held.

The obvious place in the DSA Information Tree to hold a knowledge reference attribute type, is in the DSE which equates to the name of the DIT entry that the knowledge reference points to. Thus a superior reference is held in the root DSE, since it logically points to the root of the DIT. Subordinate references are held in the appropriately named DSEs, that are subordinate to the entry at the edge of the naming context. Supplier, master and consumer references are held in the context prefix entry of the naming context that has been replicated. Immediate superior and cross references are held in the DSE which equates to the last RDN of the context prefix of the remote naming context. That just leaves NSSRs! Since the names of the entries that they point to are not known, in which DSE can they be held? One option was to create a DSE, with the name being a wildcard, that was subordinate to the entry at the border of the naming context, and to place the knowledge attribute in this. However, the solution that was finally agreed upon was to place the non-specific knowledge attribute actually in the entry at the border of the naming context.

Table 9.1 The knowledge operational attribute types
Knowledge Attribute Type  DSA Shared/Specific Knowledge Reference
My Access Point  DSA Specific Self
Superior Knowledge DSA Specific  Superior
Specific Knowledge  DSA Shared Cross 
Immediate Superior
Non-specific Knowledge DSA Shared  NSSR
Supplier Knowledge DSA Specific  Master 
Consumer Knowledge  DSA Specific  Consumer
Secondary Shadow Knowledge DSA Specific  see § 9.5

Fig. 9.2 Knowledge references in a DSA Information Tree.

Suppose XYZ Inc has a distributed Directory system. The corporate headquarters (distinguished name {C=US, L=Florida, O=XYZ Inc}) and each organisational unit have their own DSA. Fig. 9.2 shows (part of) the DSA Information Tree for the Marketing unit (distinguished name {C=US, L=Florida, O=XYZ Inc, OU=Marketing}) which is held in its non First Level DSA. The DSA Information Tree shows where many of the knowledge references are placed. The superior reference and self reference are held in the root entry. The immediate superior reference, held in the {C=US, L=Florida, O=XYZ Inc} DSE, points to the naming context held at the corporate headquarters. Each organisational unit subordinate to the Marketing unit also has its own DSA. The Marketing unit only knows the RDN of one of these units, and that is the Keys division. Consequently, the DSE {C=US, L=Florida, O=XYZ Inc, OU=Marketing, OU=Keys} holds the subordinate reference to the OU=Keys subordinate naming context. All the other subordinate naming contexts must be referenced by NSSRs held in the DSE superior to them all i.e. {C=US, L=Florida, O=XYZ Inc, OU=Marketing}. The Marketing DSA has shadowed the naming context of the Sales unit i.e. {C=US, L=Florida, O=XYZ Inc, OU=Sales} from their DSA, and it holds a supplier reference to this. The Marketing DSA also has a cross reference to its sister organisation XYZ Inc in Texas i.e. {C=US, L=Texas, O=XYZ Inc}, since it is often in contact with this organisation.


A DSA needs to be able to extract knowledge information from its knowledge attributes, in order to place them in the access point information of outgoing requests. In most cases this transformation is straightforward. The specific knowledge attribute is single valued and has a syntax of Master and Shadow Access Points (Fig. 9.1). The DSA simply has to choose one of the access points as the specially selected access point, before placing the remainder into the Additional Access Points protocol element. The non-specific knowledge attribute has the same syntax as the specific knowledge attribute, but it is a multi-valued attribute. The same transformation as for specific knowledge is followed for each of the attribute values, so that a set of 'access point information' protocol elements are created.

Superior knowledge only holds one access point, so this has to be the specially selected access point of access point information - but see w/w 9.3. Supplier knowledge holds one or two access points, depending upon whether or not the master is the supplier. The DSA will have to choose which one to use as the specially selected access point, but in most cases the master access point should be the preferred choice.

The most interesting mapping is performed by the DSA holding the master copy of a naming context. It is responsible for creating the specific knowledge attribute for a naming context, and for passing this, via Hierarchical Operational Bindings, to the DSAs holding the subordinate and immediately superior naming contexts. The information is drawn from three other knowledge attributes: my access point, consumer knowledge and secondary shadows. Consumer knowledge holds the access points of the DSAs that are receiving the shadow copies directly from this (the master) DSA. Secondary shadows holds the set of consumers who are receiving copies indirectly from this (the master) DSA. (The secondary shadows attribute is actually multi-valued, with each value holding the name of one supplier DSA, and the set of consumers that it is servicing. The set of secondary shadows is provided to the master DSA by its direct consumers, via the Shadowing Operational Binding - see § 6.4.2.) From these two attributes the master DSA is able to construct a list of all the shadow access points that have commonly usable copies of the naming context. Finally the master DSA uses its own 'my access point' attribute to create the master access point in the set of Master And Shadow Access Points. This construct is then stored in the specific knowledge attribute of the context prefix entry, and is carried to the subordinate and immediately superior DSAs via the Hierarchical Operational Binding.


In § 2.7 it was explained what name resolution is, and that every operation on the Directory requires firstly to have name resolution performed on the purported name, before the actual operation can be evaluated. Distributed name resolution is the process of performing name resolution in a distributed environment. Each DSA that participates in distributed name resolution will typically only perform a fraction of it, and will either get the operation, via chaining or referrals, nearer to the DSA which actually holds the entry named in the operation, or be able to say definitively that the entry does not exist. In the absence of cross references, distributed name resolution proceeds up the DIT, via superior references, until either the root, or a naming context with a context prefix that matches the initial part of the purported name, is encountered. At this point, distributed name resolution then proceeds down the DIT via subordinate or non-specific subordinate references, until the entry is encountered. Only after distributed name resolution starts to move down the DIT from the root, is it possible to know if a purported name is erroneous.

Once a DSA knows the names and addresses of (i) a DSA which is nearer to root of the DIT than it is, and (ii) all of the DSAs which hold all of the subordinates of the entries in the naming contexts it holds, then it is possible for it to indirectly locate every entry in the DIT (providing of course, that all other DSAs hold this minimum amount of information). The Standard mandates that all DSAs should hold this minimum amount of knowledge information. Of course, a special situation exists when we approach the root of the DIT, since the root entry is known not to exist. The Standard has this situation covered via the concept of First Level DSAs, and these will be described more fully in § 9.7.

Appendix B describes how distributed name resolution is performed in a DSA based on naming contexts. It is a slightly simpler version than that described in the '88 edition of the Standard. The appendix takes no account of alias entries. Interested readers should consult the '88 Standard for the full description.

The '93 edition of the Standard uses a different documentation technique for describing distributed name resolution, which is based on DSEs. With this technique, each DSA is modelled as holding a subtree of the DIT, which always starts at the root. Some of the DSEs in this DSA Information Tree may in fact be empty (apart from holding the DSE type attribute) meaning that only their name is known, and these are called glue DSEs. Never-the-less, a fully interconnected subtree of the DIT is held, and within this will be the naming contexts that the DSA masters. Copies of (parts of) other naming contexts, that the DSA has shadowed, will also be held in this same tree.

Distributed name resolution is now the simple process of matching a purported name against the DSEs in the DSA Information Tree, starting at the root. If the purported name matches a DSE exactly, then the name has been resolved. If the entry is held here, then the DSA evaluates the operation. If the DSE is empty (i.e. a glue DSE), then the DSE above this one that most nearly matches the purported name, and which contains a knowledge reference, is used in order to chain or refer the request to that remote DSA (providing of course, that distributed name resolution is being progressed further than that already performed by the preceding DSA). The same is true if an exact match is not found. If distributed name resolution cannot be progressed further by this DSA, then an error is returned to the caller.

By reference to Fig. 9.2, it can be seen how this DSA can perform distributed name resolution for the following purported names:

  1. {C=US, L=Florida, O=XYZ Inc, OU=Sales} - the (shadow) entry is found;
  2. {C=US, L=Florida, O=XYZ Inc} - pass to immediate superior reference;
  3. {C=US, L=Florida, O=XYZ Inc, OU=Marketing, CN=J Hooper} - either entry is found or pass to NSSR;
  4. {C=US, L=Florida, O=.....} - pass to superior reference;
  5. {C=DE, ......} - pass to superior reference;
  6. {C=US, L=Texas, O=XYZ Inc, OU=.....} - pass to cross reference.


So far in this chapter we have assumed that the root entry of the DIT exists, and is held in a DSA somewhere. As was stated previously, this is not actually the case. No single DSA could be responsible for managing the root of the global DIT for who would manage it and where would it be located? It is not even assured that all country entries will each have a single DSA in which they are located. It is also not always known who will manage them. The US (and to a lesser extent the UK) has a particular problem in this area, as a result of telecommunications services being deregulated, and many operators competing on a national basis. Who would be given responsibility to manage the {C=US} entry? (§ 10.6 for the NADF solution to this.) In a regulated country such as France, it is easy to postulate that the French PTT could be given licence to manage the {C=FR} entry.

Actual entries immediately subordinate to the root, are called First Level entries. Country and multinational organisation entries are of this type. Naming contexts with First Level entries at their root, are termed First Level naming contexts. DSAs which hold First Level naming contexts are termed First Level DSAs. First Level DSAs are defined in the Standard, but First Level entries and First Level naming contexts are not. However, for clarity, when referring to entries immediately subordinate to the root, it is convenient to use the term First Level entries. The Standard places extra responsibilities on First Level DSAs as follows.

If the root entry did exist as a naming context in a DSA, then this root naming context would consist of a single entry, the root of the DIT, plus a set of subordinate and non-specific subordinate references to all First Level entries in the world. Since the root entry does not actually exist, its contents are empty. Therefore the root naming context - abbreviated simply to root context in parts of the Standard - consists of the name (only) of the root entry, plus the complete set of subordinate and non-specific subordinate references of the root. The Standard mandates that, in order to be a conformant First Level DSA, a DSA must hold a copy of the root (naming) context i.e. have a complete set of subordinate (and non-specific subordinate) knowledge references to all First Level entries in the world that it does not hold. In this way, each First Level DSA is able to perform the function, in distributed name resolution, that the root DSA would have performed, had it existed. Fig. 9.3 shows an example of the knowledge references held by three First Level DSAs, when the root context comprises of just three subordinate references. In the example, one First Level DSA holds only the First Level entry (C=US); another First Level DSA holds the First Level entry (C=CA) and one of its subordinate organisational entries (O=E); and the third First Level DSA holds the First Level entry (C=GB) and all of the organisational entries subordinate to this.

The '88 Standard assumed that there would be one First Level DSA for each country entry, since replication was not supported. In comparison, the '93 Standard expects that there will be many First Level DSAs for each country entry. One of these will be the master DSA, the rest will hold shadow copies of the country entry. Of course, the specific knowledge attribute allows for this, by flagging which access point is to the master DSA, and which is to a shadow DSA. First Level DSAs therefore have redundancy built into their subordinate references of the root (w/w 9.3).

Fig. 9.3 Knowledge references held by First Level DSAs.

Functional standards groups are placing additional restrictions on the root naming context, by insisting that only subordinate references of the root, and not NSSRs, be allowed. This is a sensible restriction, given the overheads of chaining to a DSA referenced in a NSSR, when it may or may not hold a particular entry, compared with the cost of storing the RDN, which gives a definite indication that the entry exists.


The root naming context has to be co-operatively managed by the administrators of all master First Level DSAs. How this is to be achieved is not stated in the Standard. For it to work, the administrators of all master First Level DSAs will need to exchange with each other, their Access Points (DSA names and addresses) and the names of the First Level entries that they hold (assuming NSSRs are not condoned in the root context). This is all that is required from the Standard's perspective. However, for operational reasons, administrators will usually require additional information to be exchanged between themselves, covering such items as tariffs, security, availability etc., before they will allow interworking between their First Level DSAs. Thus bilateral agreements will usually need to be signed between organisations, before practical interworking is achieved. This aspect is not covered at all in the Standard, nor is it the concern of the functional standards groups, although it will be addressed by the North American Directory Forum. However, since it is essentially a private matter between the administrations concerned, and because there is very little information on the topic to date, little further can be said here about the nature of the these bilateral agreements.

There are two different cases of First Level DSAs to be considered. The first scenario concerns a community that has a single administration which has sole administrative responsibility for the master First Level DSA and the First Level entry. The second scenario concerns a community, such as a deregulated country, where many DSAs want to hold the First Level (country) entry, but in which no single administration has the authority to manage it.

9.8.1 Community with One First Level Administration

In this scenario, the First Level administration will be solely responsible for the management of the master First Level DSA and First Level entry. They alone will determine the contents of the root context held in their master First Level DSA. If the administration decides not to co-operate with any of the other (external) First Level DSA administrations, then the root context, from its perspective, will contain only one subordinate, that of its own First Level entry. From the perspective of users in this closed community, their community is the only one that currently supports X.500, and no other countries or international organisations in the world are accessible via their master First Level DSA (however, they could be made accessible if the subordinate DSAs had their own administrations and added their own cross references). From the perspective of the external world wide community of users, this closed community has not yet joined the rest of the co-operating world. We thus have two disjoint X.500 communities, that both support the international standard, and who use standard conformant products, but do not interwork with each other because their administrators have not yet configured in knowledge of the other, or exchanged operational information. This scenario is not that unrealistic, if we consider the closed community to be a body such as NATO, or the UK MoD, or the US DoD, each of whom is unlikely to be connected to the global public directory system.

If however the master First Level DSA administration decides to cooperate with another similar First Level DSA administration, then each will configure into their root naming context, a subordinate reference to the other. Users of both communities will then have an identical view of the global DIT, which now, from their perspectives, consists of two communities/First Level entries.

Administrations can continue to create these bilateral agreements with each other. The more bilateral agreements a First Level DSA administration has, the more First Level entries are seen to be connected to the global DIT, by users within that community. If this situation was allowed to develop with the national PTTs, we could have a situation whereby users in different countries would see a different number of other countries connected to the global DIT, this number of other countries being dependent upon the number of bilateral agreements that their own PTT had reached with other PTTs in the world. This clearly is an undesirable situation, and is not conformant to the Standard. One would expect the ITU-T, either to encourage (if not mandate) its members to co-operate multilaterally with each other, or at least to facilitate agreements by establishing an international register of First Level DSAs. (This First Level DSA register would hold the Access Point and the names of the First Level entries that each First Level DSA holds.) A variation of the former route has already been achieved for international telephone services, and so it is not unreasonable to expect a similar scheme to be set up for the Directory. A variation of the latter route is currently being adopted by the North American Directory Forum via its CAN (§ 10.6). However, it is highly likely that during the first few years of operation, different users of X.500, in different countries and in different communities, will initially (if not always) have different views of what the global DIT consists of.

The number of First Level DSAs in one community/country is independent of who administers the master First Level entry. Other DSAs, by arrangement with the master First Level DSA administration, may shadow the master First Level DSA's information, and thus become shadow First Level DSAs. Both the master and shadow First Level DSAs will have identical views of the root context. A shadow First Level DSA may have operational agreements with First Level DSAs in other countries, and may chain requests to and from them. If a shadow First Level DSA does not have an operational agreement with a First Level DSA in another country, then it can always pass the request to its Master First Level DSA for it to continue processing i.e. use the Master First Level DSA as a superior reference, since it knows that the Master First Level DSA does have bilateral agreements with all the other master First Level DSAs. This latter option is not open to shadow First Level DSAs in the following scenario.

9.8.2 Community with Multiple First Level DSAs and Administrations

Turning now to a deregulated country, in which no single organisation has responsibility for managing the entry of the country. Each national carrier will therefore want to hold a copy of the country entry, and thus be a (shadow) First Level DSA. However, who will manage the master First Level DSA? The North American Directory Forum are addressing this problem for the US and Canada [2.8], by allowing many organisations to hold copies of the US and Canada entries, as well as the root naming context (§ 9.8.3 and § 10.6.2). However each DSA is effectively a shadow First Level DSA for the country. The master First Level DSA will not actually exist. The administrative function of the master First Level DSA i.e. its knowledge distribution role, is being adopted by the Central Administration for the NADF. From the perspective of the outside world, there will be many (shadow) First Level DSAs that serve {C=US} and {C=CA}, and each of them should be equally capable of servicing a request for North America (although there may be operational differences in their tariffs, security, and availability etc.). From the perspective of one of the North American First Level DSAs, it is the First Level DSA for Canada and the US, and will co-operate with First Level DSAs in the rest of the world via bilateral or multilateral agreements as described in § 9.8.1 above. The problem that could foreseeably arise, would be for North American users who find that some of their First Level DSAs have bilateral agreements with lots of other countries' First Level DSAs, and thus have high connectivity to a large DIT, whilst others have only a few agreements, and therefore low connectivity to a much smaller DIT. There will be no master First Level DSA that is guaranteed to be fully inter-connected with all the other master First Level DSAs in the world, as is the case when there is only one First Level Administration.

It can be seen that there is a difference between holding knowledge references (e.g. the root context) and providing a good quality service to users. A shadow First Level DSA will have subordinate references to all the other First Level entries/DSAs in the world, as provided by its master DSA, but it may have bilateral agreements with none (or only a few) of them. In this case, it might simply return referrals to its customers, that point to those First Level DSAs with which it does not have any bilateral agreements, and let the customers contact the other First Level DSAs themselves. A First Level DSA with many bilateral agreements may offer a chaining service to lots of other countries (First Level DSAs), and thus provide a higher quality of service to its customers. Such is the nature of competition, and the free market.

9.8.3 Managing a Shared 'Country' Naming Context

In order to hold the root entry/naming context, a First Level DSA has to have knowledge about all the entries one level below the root. These will typically be country entries. For any given country entry, its master First Level DSA has to hold information about all the subordinates of the country entry, either as subordinate references (and NSSRs) or by holding the actual entries (Fig. 9.3). However, knowledge about the subordinates of the country entry is not passed to the other First Level DSAs. The only information that is passed to them, is the name of the country entry being held, plus its own Access Point. Similarly, the only information that is received from all the other First Level DSAs, is their Access Points and the country entries that they hold. In this way all First Level DSAs can hold a copy of the root entry/naming context.

The North American Directory Forum has taken this model of the procedure that should operate internationally for sharing the root entry/naming context, and applied it to sharing the US and Canada country entries within North America. Thus DSA administrations that wish to have a copy of these country entries, must first inform the NADF which entries (usually organisational entries) they hold below the country entries. (They do not need to tell the NADF what they hold below these organisational entries, although they themselves must know about all of the subordinates of these.) In return they receive details about all the other entries below the US and Canada country entries, as well as the Access Points of the DSAs that hold them.

After this information exchange, in which the Central Administration for the NADF (the CAN) acts as the registration bureau for the NADF, all North American First Level DSAs will hold copies of the US and Canada country entries. They will also have subordinate knowledge references to all the entries below the US and Canada country entries, that they do not hold.

This information exchange procedure could be applied recursively as one moves down the DIT, so allowing an organisation to share the organisational entry amongst a set of DSAs. Each DSA in the set would hold a copy of the organisation's entry, and just some of the subordinates of this entry. However, all the DSAs in the set would have knowledge of the whereabouts of all of the subordinates of the organisational entry.


Initially an organisation may want to employ X.500 conformant products internally, but may wish to be disconnected from the global DIT. In this case, the organisation should build a root context containing only the root and its own country's entry. Below the country should be the organisation's entry, placed at an appropriate level (for details of naming this entry see § 9.9.1). The global DIT, from its perspective, will thus contain one country, and within that country, one organisation. The DSA will not have a superior reference.

Should the organisation decide that it wants to communicate with another organisation, resident either in the same country, or in a different one, it merely needs to add a cross reference to that organisation, to its own DSA. The DIT, from its perspective, now consists of just two organisations, and one (or two) countries.

Should the organisation eventually decide that it wishes to join the public global DIT, it will have to contact the administrator of the First Level DSA mastering its country's entry, assuming of course that its name has been nationally registered - see § 9.9.1. A conformant master First Level DSA is required by the Standard to add a subordinate reference to the DSA holding the organisation's entry, and to propagate this knowledge to all shadow First Level DSAs in the country. The organisation's DSA should add an immediate superior reference to the master First Level DSA i.e. a Hierarchical Operational Binding has been created - see § 9.19. Note however that the master First Level DSA is not required to operationally inter-work with the organisation's DSA. This will be the subject of a bilateral agreement in which tariffs etc. are agreed upon. Assuming that such an agreement is reached, the organisation's DSA will add a superior reference pointing to the master First Level DSA, and will then be able to forward Directory requests for entries in the outside world to that First Level DSA. The master First Level DSA will also chain or refer external queries to the organisation's DSA.

If a bilateral agreement is not reached with the master First Level DSA for the country, then the organisation will need to reach an agreement with another First Level DSA operator, and use this as its superior reference, otherwise it will not be able to forward requests everywhere in the outside world. (In this respect any First Level DSA should be able to offer an equivalent service, but the quality of service may vary as outlined in § 9.8.2.) With respect to requests originating from the outside world, the master First Level DSA for the country may not now be prepared to chain requests to the organisation's DSA, but may instead return referrals to the outside callers. The callers will then have to contact the organisation's DSA themselves, perhaps setting up their own bilateral agreements, before adding cross references into their own DSAs. It will be interesting to see how all of this evolves.

9.9.1 Registering an Organisation's Name

It was suggested in § 9.9 that an organisation should follow the DIT structure recommended in the Standard, i.e. root, country, [optional localities], organisation. But what RDN should the organisation use for its entry? And at what depth in the DIT should it be placed? Clearly the relative distinguished name should be appropriate for the organisation, but looking to the longer term, the distinguished name should also be globally unambiguous. This will be essential if the organisation is eventually to connect to the global public directory service, or even if it is to join a large international body of commercial users.

In order to guarantee that the organisation's distinguished name is globally unambiguous, it needs to be registered. Most countries are now operating, or creating the framework for the operation of, a national OSI name registration authority. Each authority has the sole responsibility for allocating RDNs at the appropriate place under its DIT country node. The appropriate place will be determined by the regional standing of the organisation. An organisation of national standing will be registered under the country node, an organisation of local standing will be registered under a locality node below the country. Organisations should therefore contact their national name registration authority in order to determine how best to register their preferred RDN. Coupling the registered RDN with the stub provided by the registration authority (e.g. {C=US, ST=Florida}) gives the organisation its distinguished name. Failure to register its RDN may preclude an organisation from joining the public global DIT without first changing its distinguished name. This is because it may find that some other organisation has already chosen, registered and is using the same name. It would then need to choose and register a different name, and rename all of its local DIT entries before it could join the global DIT. Obviously the global DIT cannot accommodate two organisations with the same distinguished name.

Within the UK, a British Standard [8.1], defines how UK organisations are to be named. Two alternative methods are defined. For those companies who are nationally registered under the Companies Act 1985, the relative distinguished name of the organisation may be that of the registered company name. For example, XYZ Plc, can have a relative distinguished name of {O=XYZ Plc} and a distinguished name of {C=GB, O=XYZ Plc}. For charities, educational institutions, and any organisation that so wishes, BSI [8.2] offers a name registration scheme whereby, for the fee of £150 + VAT (1992 price), an organisation can choose any relative distinguished name that is reasonable. This may then be registered under either the country node, or one of more than a hundred locality nodes. Registered companies may use this route to register alias names and shortened versions of their official company name. A mechanism is defined to resolve contentions, but as with any scheme, such as the registration of trade marks, it is on a first come - first served basis. (An object identifier (Appendix A) can also be obtained at the same time for no extra charge, but an X.400 ADMD name will cost an additional £300 + VAT (1992 price).)

The US (ANSI) has adopted a similar scheme to the UK, but prefers that organisations register at the state level rather than at the national level. Organisations are encouraged to follow this route, since punitive charges are levied for national registration. Organisations should therefore register their preferred RDN in all of the States of the Union.

Therefore if a company has long term strategic plans to migrate to X.500, then they should register their organisation's name as soon as possible.