9.10 MODES OF INTERACTION

The '88 Standard described three modes of interaction between components of the Directory, termed referrals, chaining and multicasting. The first two modes have been described in § 4.2 and § 4.1.2. The third mode was required as a consequence of encountering NSSRs during name resolution, and is the process of sending several identical requests to a series of DSAs. However, the mode of multicasting seems to have caused some misunderstanding, particularly since it was not clear what the similarities or differences were between multicasting and multiple chaining during Search evaluation. As a result, the term 'multicasting' has been removed from the '93 Standard, and has been replaced by NSSR decomposition, followed by multi-chaining. This is now more in alignment with request decomposition during Search evaluation, followed by multi-chaining. NSSR decomposition and request decomposition are described in the following sections.

Fig. 9.4 Parallel multi-chaining.

Fig. 9.5 Sequential multi-chaining.

Multi-chaining is the process of chaining several requests to multiple DSAs, either sequentially or in parallel (Figs 9.4 and 9.5). With sequential multi-chaining, the results of the first chained request are received before the second one is transmitted. With parallel multi-chaining, all the outgoing requests are sent simultaneously. (The Paradise Directory service, developed at UCL, has implemented parallel multi-chaining for searching below a country entry. Requests to search all the organisations within the country are sent simultaneously by the DUA. The performance is quite impressive, since we have hundreds of organisational DSAs parallel processing the user's request.) The outgoing requests may be identical or different, but they will all have been derived from one incoming request. The choice between performing parallel or sequential multi-chaining is purely a local decision of the DUA or DSA (or its administrator), and may depend to some extent upon the processing capacity of the implementation. The outcome of the operation should not be unduly influenced other than by the time (and cost) it takes to complete it. Parallel multi-chaining will usually be quicker than sequential multi-chaining, but may consume more resources. However, in the presence of shadowing, parallel multi-chaining may cause duplicate results to be received (§ 9.13.14).

9.11 NSSR DECOMPOSITION

NSSR decomposition is a process which may be undertaken during name resolution, when a set of non-specific subordinate references are encountered. It is the process of producing several identical requests to the different DSAs pointed to in the non-specific knowledge attribute. Only one DSA from each attribute value is chosen, since all the DSAs grouped together in one attribute value (Master and Shadow Access Points) point to copies of the same naming context(s) - see Fig. 9.6. Obviously in the absence of replication, each attribute value will only contain one DSA access point.

In Fig. 9.6, DSA1 holds multiple NSSRs (4 in total) at the {O=XYZ} entry. The non-specific knowledge attribute holds two attribute values, each value holding a master and a shadow access point.

Fig. 9.6 Multiple NSSRs, to masters and shadows.

A DSA which encounters multiple NSSRs during name resolution, must either:

If one or more of the DSAs contacted during the multi-chaining hold a copy of the subordinate entry being referenced, then they should be able to answer the query. Sequential multi-chaining will potentially consume the least resources, since other DSAs will not need to be contacted once the result has been received. For example, in Fig. 9.6, a request to DSA1 to read entry {..O=XYZ,OU=A...}, which it is planned, after NSSR decomposition, to sequentially chain to DSA2 followed by DSA3, will receive an answer after DSA2 has been contacted. DSA3 will not need to be contacted.

If none of the DSAs referenced in the NSSRs is able to continue processing the query, because none of them holds the subordinate being referenced, then it is assumed that the entry does not actually exist. A DSA that is contacted via a NSSR, and that is unable to locate the required entry, must return the special Service Error (Unable to Proceed). This error tells the calling DSA not to return an error to the user, but to wait for the replies from the other DSAs referenced in the NSSRs. Only if all DSAs reply Unable to Proceed will the calling DSA assume that the entry does not exist. For example, in Fig. 9.6, if as a result of NSSR decomposition and multi-chaining, both DSA2 and DSA3 are contacted to read entry {..O=XYZ,OU=C..}, both will return Unable to Proceed. DSA1 will then know to return Name Error (No such object) to the caller.

9.12 REQUEST DECOMPOSITION

Request decomposition may take place during Search or List evaluation. It is the process of producing further Search or List requests, from one incoming request. Request decomposition may occur when a subordinate reference or a NSSR is encountered within the scope of the operation evaluation (for List, this means immediately subordinate to the target entry). The outgoing requests are then multi-chained to the referenced DSAs. The outgoing requests are always different to the incoming request (as a minimum Operation Progress is always set to Completed, unless an alias is encountered), and often they are different to each other. All the knowledge references below one parent entry will produce identical outgoing requests, but those below different parent entries will produce different requests, since the target object (§ 9.13.3) of the outgoing request is set to the name of the parent entry. For example, in Fig. 9.7, request decomposition by DSA1 of a request to search {..O=XYZ}, will produce outgoing requests to search {..O=XYZ, OU=A} and {..O=XYZ, OU=B}.

Only one DSA from each knowledge reference attribute value is chosen, since all the DSAs grouped together in one attribute value (Master and Shadow Access Points) point to copies of the same naming context(s). If that particular DSA cannot reply, for example, it is down, or it responds with a soft error (The Standard lists the soft errors as Service Errors with diagnostic codes of 'busy', 'unavailable', 'unwilling to perform', 'invalid reference', or 'administrative limit exceeded'), then the DSA is free to choose another access point from the same set of Master and Shadow Access Points. However, at least one DSA from each attribute value must be contacted, otherwise an incomplete result will be collected. For example, in Fig. 9.7, requests to search {..O=XYZ, OU=A} must be sent to DSA2 and to either DSA3 or DSA5, and requests to search {..O=XYZ, OU=B} must be sent to DSA4 and to either DSA3 or DSA5. Remember that a DSA does not have to undertake request decomposition and multi-chaining, it can always return a partial result. Partial results contain Continuation References to the sets of knowledge references (attribute values) that have not been contacted via multi-chaining.

Fig. 9.7 Subordinate references to masters and shadows.

9.13 THE CHAINING ARGUMENTS

The Chaining Arguments are added to an outgoing request by a DSA, before chaining it to another DSA, in order to record the state of processing of the operation. A DSA receiving an incoming request from another DSA uses this state information, in order to correctly continue processing the request. It removes the Chaining Arguments, and then adds updated Chaining Arguments to its outgoing request(s). These updated Chaining Arguments record the new state of processing, so that the next DSA knows precisely how to continue. At no time are the initial arguments of the DAP request, input by the user, altered by a DSA. Thus each DSA in a chain always has available to it, the unaltered contents of the DAP request. As was described in Chapter 7, this is essential if digital signatures are used by the request originator. The Chaining Arguments, along with the initial DAP arguments, contain all the information needed by a DSA, in order for it to determine what to do with an incoming request. The components of Chaining Arguments are shown in Table 9.2.

9.13.1 Referrals

If a DSA decides to return a referral to the requestor, instead of chaining the request to another DSA, then the referral contains all the essential state information that the DSA would have placed in the Chaining Arguments. The DSA places the same values for the equivalent parameters into the referral, that it would have placed into the Chaining Arguments. If the requestor is a DSA, then upon receiving the referral, it is able to recreate the chained request that the DSA returning the referral would have sent. This is achieved by combining the information returned in the referral with that in the original request that it received. If the requestor is a DUA, it is able to copy the information from the referral into the Common Arguments field of the original request, and then send the request to the DSA referred to. In this way the distributed processing of the request can continue independently of whether any DSA chooses to either return a referral or chain the request. The components of a Referral (Continuation Reference) are shown in Table 9.3, and the components of a DSA Referral are shown in Table 9.4. Referrals are sent in the DAP to DUAs, and DSA Referrals are sent in the DSP to DSAs. The difference between the two, is that the DSP Referral may optionally contain additional information from which the DSA may construct a cross reference (§ 9.13.7).

9.13.2 Originator

The originator component of Chaining Arguments contains the distinguished name of the DUA (user) originating the request. Normally the user will not include their name in a DAP request, since they passed their name to the (home) DSA when they first bound to it. Every request that subsequently passes down the DAP connection to this DSA must come from the same user. However, when DSAs chain requests to one another, the requests passing down the DSP connection may all originate from different users (Fig. 7.4). The home DSA is thus responsible for passing the name of each user of each request to the subsequent DSA in the chain, via the originator field. Subsequent DSAs must pass on this field unchanged.

Table 9.2 The parameters of Chaining Arguments
Parameter ASN.1 Parameter Encoding Described in
Originator Distinguished Name OPTIONAL 9.13.2
Target Object  Distinguished Name OPTIONAL 9.13.3
Operation Progress 

Name Resolution Phase 
     Not Started 
     Proceeding 
     Completed 

Next RDN to be Resolved

 SET { 

ENUMERATED INTEGER: 
     (1) 
     (2) 
     (3) 

INTEGER }

  9.13.4
Trace Information 
Trace Item 
     DSA Name 
     Target Object 
     Operation Progress		 SEQUENCE of Trace Items 
SET { 
     Distinguished Name, 
     Target Object, 
     Operation Progress }		 9.13.5
Alias Dereferenced BOOLEAN 9.13.6
Aliased RDNs  INTEGER OPTIONAL 9.13.6
Return Cross References BOOLEAN 9.13.7
Reference Type 
     Superior 
     Subordinate 
     Cross 
     NSSR 
     *Supplier 
     *Master 
     *Immediate Superior 
     *Self 		 ENUMERATED INTEGER: 
(1) 
(2) 
(3) 
(4) 
(5) 
(6) 
(7) 
(8)		 9.13.8
Domain Information Any OPTIONAL 9.13.9
Time Limit UTC Time OPTIONAL 9.13.10
Security Parameters  See Table 5.5  5.4.2
Entry Only BOOLEAN  9.13.11
*Unique Identifier BITSTRING OPTIONAL  9.13.12
*Authentication Level 
Basic Level 
     None 
     Simple 
     Strong 
Local Qualifier 
Other		 OPTIONAL, either SET { 
ENUMERATED INTEGER: 
     (0) 
     (1) 
     (2) 
INTEGER } or 
Any		 9.13.13
*Exclusions SET of RDN Sequences OPTIONAL 9.13.14
*Exclude Shadows BOOLEAN 9.13.15
*Name Resolve On Master BOOLEAN  9.13.16
* signifies parameters added in the '93 edition of the Standard

However, when a DUA request is signed, the requestor field of Common Arguments contains the distinguished name of the user. In this case, the originator field is missing from Chaining Arguments, since there is no necessity to duplicate the name.

9.13.3 Target Object

Target object of Chaining Arguments contains the distinguished name of the object of the operation, but only if it is different from the purported name originally specified by the DUA. There are two reasons why the purported name originally specified by the DUA may have changed. Firstly, the user may have specified an alias name. When the alias entry is encountered, and dereferenced, the DSA performing the dereferencing, puts the new object name into target object. Secondly, and this is only the case for the Search Whole Subtree operation, as the subtree is descended, the base object name is extended by the RDN of each node traversed.

Target object in a referral has exactly the same semantics as in the Chaining Arguments. However, it is always present in the referral, even if it has the same value as the object name provided by the user.

9.13.4 Operation Progress

This is the key argument used in the distributed processing of an operation, as it indicates how far distributed name resolution has progressed. Operation progress is actually set by the sending DSA to indicate what the receiving DSA is to do next, and is not, as the name implies, a record of what has actually been achieved. Although in most cases the former can be implied by the latter, this is not always the case. For example, a DSA may have performed no name resolution at all (as might be the case in a request to read an entry in the US which emanates from a British DSA), but may have a cross reference to the DSA holding the entry. In this case Name Resolution Phase would not be set to Not Started as one might assume, but would be set to 'proceeding', with Next RDN To Be Resolved set to the number of RDNs in the (context prefix of the) cross reference.

Table 9.3 The parameters of a Referral (Continuation Reference)
Parameter ASN.1 Parameter Encoding Described in
Target Object  Distinguished Name  9.13.3
Operation Progress 
Name Resolution Phase 
     Not Started 
     Proceeding 
     Completed 
Next RDN to be Resolved		 SET { 
ENUMERATED INTEGER: 
     (1) 
     (2) 
     (3) 
INTEGER }		 9.13.4 
Aliased RDNs  INTEGER OPTIONAL 9.13.6
RDNs Resolved INTEGER OPTIONAL 9.13.17
Reference Type 
Superior 
Subordinate 
Cross 
NSSR 
*Supplier 
*Master 
*Immediate Superior 
*Self 		 ENUMERATED INTEGER 
(1) 
(2) 
(3) 
(4) 
(5) 
(6) 
(7) 
(8)		 9.13.8 
Access Points Access Point Information 9.3
Entry Only  BOOLEAN  9.13.11
*Exclusions  SET of RDN Sequences OPTIONAL  9.13.14
*Return to DUA BOOLEAN  9.13.18
*Name Resolve On Master BOOLEAN 9.13.16
* signifies parameters added in the '93 edition of the Standard

Table 9.4 The parameters of a DSA Referral
Parameter ASN.1 Parameter Encoding Described in
Continuation Reference see Table 9.3 Table 9.3
Context Prefix  Distinguished Name OPTIONAL 9.13.7
 

Name Resolution Phase is set to Not Started, when the sending DSA has performed no distributed name resolution at all, and the request is being chained (or referred) to the DSA pointed to in its superior reference. (In the '93 version of the Standard an immediate superior reference may also be used.) In other words, the request is being passed up the DIT towards the root. Not Started cannot thus be used to chain (or refer) to DSAs pointed to in subordinate, non-specific subordinate, or cross references, since name resolution will have already started in these cases (i.e. we are now moving down the DIT from the root). Not Started obviously may not be used by First Level DSAs which chain (or refer) a request, since these, by definition, are always able to perform a minimum of distributed name resolution i.e. they know that the root exists and they are now locating the First Level entry that matches the first RDN of the purported name. The semantics attached to Not Started is that the receiving DSA is free to continue processing the request in whatever way it best sees fit, and no restrictions are placed upon it by the sending DSA.

Name Resolution Phase is set to Proceeding when at least one RDN of the purported name has been matched by the sending DSA, in either one of its entries or knowledge references. Next RDN To Be Resolved is set to the minimum number of RDNs in the purported name that the sending DSA requires the receiving DSA to resolve. If the receiving DSA is unable to resolve at least this number of RDNs it must return an error to the calling DSA. This is one of the mechanisms that can be used by a sending DSA to check that its knowledge references are correct (subordinate, immediate superior, non-specific subordinate, and cross references in particular). On receiving a request with Name Resolution Phase set to Proceeding, a DSA which subsequently chains on the request must, in the case of an '88 conformant DSA, either increase the value of Next RDN To Be Resolved, or set Name Resolution Phase to Completed. A '93 conformant DSA may chain the request to its master or supplier DSA with the value unaltered. A DSA must not chain on a request with either Name Resolution Phase or Next RDN To Be Resolved having a lower value than that on arrival as this implies that less name resolution has taken place than previously! Note however, that when an alias is encountered, name resolution effectively starts all over again, and any value of Name Resolution Phase may be used (§ 2.7).

Next RDN To Be Resolved can only have a value when Name Resolution Phase is set to Proceeding.

Name Resolution Phase is set to Completed when the sending DSA has located the entry referred to in the request. (Name resolution locates the target object for all operations in the '93 version of the Standard except AddEntry, in which case the parent of the target object is located (the entry to be added does not yet exist!). In the '88 version of the Standard AddEntry, RemoveEntry and ModifyRDN all name resolve to the parent of the object.) For most operations, chained requests will never be issued with a value of Completed. This is because when the entry is located, the DSA can either completely evaluate the operation itself e.g. Read, and ModifyEntry operations, or it uses other means to complete the processing of the operation e.g. AddEntry in another DSA uses Establish Operational Binding (§ 9.20). The only time that a DSA may need help in evaluating an operation is for list and search operations. A DSA receiving a List or Search operation with Name Resolution Phase set to Completed, is expected to participate in the evaluation of the operation. Consequently, if the receiving DSA does not hold children of the target entry, then it must return an error to the requestor.

Operation Progress is also set by the DUA, as one of the parameters of Common Arguments (§ 5.4). In this case the value will always be set to Not Started (the default value) unless the DUA is acting upon a received referral. If a DUA receives a referral, it may simply copy the parameters from the referral into Common Arguments, and continue the processing of the operation where the last DSA left off.

9.13.5 Trace Information

Trace information keeps a record of which DSAs have been involved in the processing of a request, and also of what their involvement was. The purpose of this is to avoid looping. (Looping occurs when a request is continuously circulated between two or more DSAs, without the operation being progressed.) It would not be sufficient to simply keep a record of the names of the DSAs that have previously been passed a request, since it is quite legitimate for a DSA to be involved more than once in the processing of a request. For example, a DSA could be passed a request from a DUA, which is search a subtree, whose base entry is in a DSA superior to this one. The DSA would initially pass the request to its superior, with operation progress set to Not Started, and later on it would be passed the request from its superior, with operation progress set to Completed. Alternatively, a DSA could be passed a request during the name resolution phase, which unbeknown to it contains an alias name in the purported name. The DSA could progress the name resolution and pass the request on to the next DSA with operation progress set to Proceeding. After the alias has been dereferenced, the request could then legitimately be passed back to the DSA, with operation progress still set to Proceeding but with less RDNs resolved than the previous time! For these reasons, trace information consists of a sequence of trace items, with each trace item consisting of the following: Each DSA participating in the distributed processing of an operation, adds a trace item to trace information before it chains on the request to the next DSA. It will be noted that trace information does not occur in referrals. This is because it was originally assumed that looping could not occur if a referral was returned to a requestor. As was pointed out in a subsequent Australian defect report, looping can occur with referrals, which will not occur with chaining, as the following example illustrates. Suppose that one DSA has an alias that points to another alias held in another DSA, and the latter alias points back to the original one. If the original DSA, upon receiving a request, de-references the alias and chains the request to the other DSA, which de-references the alias and chains the request back again, the loop will be detected by the original DSA, since there will be two identical trace items in trace information. Now suppose that the original DSA returns a referral to its caller. The caller will contact the other DSA, and suppose that the latter also returns a referral (which will point to the original DSA). Because there is no trace information, the caller could continue acting on these referrals for ever, with the request ping ponging between the caller and the two DSAs. There is thus a requirement for DSAs to keep a record, for each operation, of the referrals that they have acted upon. The arrival of a referral which is exactly the same as one that has previously been acted upon for this operation, indicates that a loop exists.

9.13.6 Alias Dereferenced and Aliased RDNs

Alias Dereferenced is a logical flag which states if an alias has been dereferenced or not. It is initially set to False in Chaining Arguments, but is switched to True by a DSA when it dereferences an alias. The DSA that finally evaluates an operation, needs this information, because several of the operations return additional information (i.e. the distinguished name of the entry - see for example § 5.8.1) if an alias has been dereferenced. Furthermore, there are several error messages that are peculiar to aliases, so all subsequent DSAs in a chain need to know if an alias has been dereferenced.

Alias Dereferenced would have been the only Chaining Argument needed specifically for aliases, if the '88 version of the Standard had not had the restriction that aliases cannot point to other aliases (this restriction has now been removed in the '93 version of the Standard). Due to this '88 restriction, each DSA participating in distributed name resolution needed to know how many of the RDNs in the target object name came from the alias dereferencing (the aliased object name attribute) and how many were originally input by the user. Then, if another alias was encountered before this many RDNs had been resolved, one would have had an alias that pointed to another alias, and an appropriate error (Alias Dereferencing problem) could be returned to the user. Aliased RDNs is the count of how many RDNs in the target object name came from dereferencing the alias. This parameter is present in referrals, and has exactly the same semantics as in Chaining Arguments. In a referral, the value of the Alias Dereferenced flag is inferred from Aliased RDNs (w/w 9.4).

Once the '93 Standard removed the aliases pointing to aliases restriction, a mechanism had to be found to ensure interworking between '88 and '93 implementations. The mechanism that is prescribed, is for '93 DSAs to always set the Aliased RDNs value to 1 in outgoing requests, and to ignore the parameter on incoming requests. In this way '93 aliases can point to all other aliases except First Level aliases in '88 DSAs.

9.13.7 Return Cross References

The Return Cross References boolean parameter may be set to True by the first DSA in a chain, to request that subsequent DSAs in the chain return cross references in the chained result. The DSA initially chaining the user's request determines the value of this flag, and subsequent DSAs in the chain should copy the original value. DSAs receiving a chained request with this boolean parameter set to True, are not mandated to actually return cross references in the result, and whether or not they do so will probably be determined by their administrators (assuming of course that the feature has been implemented in their DSAs). Some implementations may not support the return of cross references, however, the use of this flag by co-operating DSAs will aid the DSAs in building up their knowledge references, and so will ultimately lead to increased performance by the Directory. It is interesting to see that the NADF is encouraging the use of cross references. It should be noted however, that the returned cross references will not provide administrators with the operational information, such as tariffs and security requirements, that they may need before the cross references can be effectively used by their recipient DSAs. For this reason, the returned cross references might only be provided by other DSAs in the same management domain as the requesting DSA.

Each returned cross reference contains the context prefix of a naming context that is pertinent to the user's request. It also contains the access points of the set of DSAs that hold copies of this naming context. The cross references are either returned in Chaining Results (Table 9.5), or as part of a DSA Referral (Table 9.4). In the former case, each DSA in the chain may return a set of cross references in the result. For example, by reference to Fig. 9.7, a chained request to read the entry {...O=XYZ, OU=B, OU=W, CN=...}, may be chained through DSA1 and DSA2. If return cross references was set to True, then the chained result could contain the following cross references:

In the case of the DSA Referral, only one set of cross references is returned to the requestor, and this is generated from the knowledge reference attribute held by the DSA generating the referral. For example, by reference to Fig. 9.7, a chained request to DSA1, to read the entry {..O=XYZ, OU=B, OU=W, CN=...}, could return a DSA Referral to the requestor, containing: Similarly, a '93 chained request to DSA1 to read the entry {..O=XYZ, OU=B, OU=Z, CN=...} could return a DSA Referral to: Note that an '88 implementation will only return one access point/cross reference, since replication was not supported in that version of the Standard. A '93 implementation, on the other hand, may return a set of access points that point to DSAs that hold copies of the same naming context. (This is a consequence of replication, and of replacing access point ('88 Standard) by access point information ('93 Standard).)

9.13.8 Reference Type

Reference type is set by a DSA to indicate what type of knowledge reference was used in formulating the chained request or referral. During chaining, the field is used by the receiving DSA as a knowledge consistency check. Used along with the value of operation progress, the receiving DSA can tell if the caller's knowledge reference is accurate or not. If it is not, the DSA can reply with a Service Error (Invalid Reference). An additional use of this parameter is in the generation of the error code when a purported name cannot be found. If the reference type is NSSR, then Service Error (Unable to Proceed) is returned, otherwise a Name Error (No Such Object) is returned (§ 9.11).

During referrals, reference type is copied from the referral into the Chaining Arguments, by the DSA that acts upon the received referral. The request is then chained to the DSA pointed to in the referral. If a Service Error (Invalid Reference) is returned, this does not mean that the DSA acting upon the referral has an invalid reference, but rather that the DSA generating the referral has some erroneous knowledge. How this information is relayed to the DSA which generated the faulty referral, is outside the scope of the Standard. A friendly phone call from one DSA administrator to another would not go amiss!

'88 Referrals are not allowed to transmit the reference type parameter to the DUA. It has to be removed by the home DSA. This was a suspect decision that was made in 1988, in order to protect DSA knowledge information. However, it was overturned by the '93 Standard, due to the technical error that it produces when the referral is based on NSSRs. Therefore '93 referrals and DSA referrals are identical, so that '93 DUAs can behave in the same manner as DSAs.

9.13.9 Domain Information

This chaining parameter is essentially a bucket into which two co-operating DSAs can place any information that they like. The field is optional, and its syntax and semantics are undefined in the Standard. Clearly such a field cannot be used in a public directory service without the functional standards groups defining its contents. No such definitions have been made to date. However, one could envisage that two DSAs with a bilateral agreement might use this field to carry tariffs and other local information.

9.13.10 Time Limit

The time limit, optionally provided by the user, as part of the service controls, is expressed as an elapsed time in seconds. If chaining is required, the initial DSA has to convert this elapsed time into the absolute value of time by which the operation must be completed. This absolute value must be globally understandable across multiple time zones. Such a value for time has been defined, and is known as co-ordinated universal time. The ASN.1 standard defines a syntax (with the type reference UTCTime) for coordinated universal time. UTCTime can be either represented as the co-ordinated universal time, or as the local time along with the difference between this and co-ordinated universal time. It is the responsibility of the first DSA in the chain to convert the user's elapsed time into UTCTime. The time limit parameter may be missing, if the user did not specify one.

There is obviously no requirement to have time limit in referrals, since the recipient of the referral already has the time limit from the incoming request.

9.13.11 Entry Only

This parameter was added by a defect report to the '88 Standard. It is needed for the special case of a Search operation which specifies one level, when a subordinate of the base entry is an alias entry. After alias dereferencing, the newly generated Search operation will need to search only the base entry, i.e. the aliased object. However, because the original parameters input by the user cannot be changed (otherwise the digital signature, if present, would be invalidated - see Chapter 7), a new parameter, EntryOnly, had to be introduced to the Chaining Arguments and continuation reference. EntryOnly will normally be set to False. The chained request or the referral will only set EntryOnly to True after an alias, which is a subordinate of the base entry in a Search One Level operation, has been dereferenced, and the aliased object resides in a different DSA to the alias. Any DSA receiving a Search One Level request, with Entry Only set to True, should only search the target object.

9.13.12 Unique Identifier

This parameter was added to Chaining Arguments in the '93 Standard, due to the re-use of distinguished names (§ 8.4.2). It is the unique identifier of the originator of the operation, i.e. the user, and it is optionally added to the Chaining Arguments by the home DSA after it authenticates the user. It should be used by the DSA evaluating the operation, when checking the access rights of the user. It ensures that the access permissions are really intended for this user. Unique identifier is an input parameter to the Access Control Decision Function (Fig. 8.15).

9.13.13 Authentication Level

This parameter was added to Chaining Arguments in the '93 Standard, in order to inform the DSA evaluating the operation, which mechanism was used to authenticate the user (i.e. nothing, a password or a digital signature - § 8.4). It is optionally added to the Chaining Arguments by the home DSA after it authenticates the user. It should be used by the DSA evaluating the operation, when checking the access rights of the user, to ensure that the user has been sufficiently authenticated (§ 8.1.3). Authentication Level is an input parameter to the Access Control Decision Function (Fig. 8.15).

9.13.14 Exclusions

Exclusions is a new optional parameter that may be added to chained Search requests in the '93 version of the Standard. It has arisen as a result of replication. During request decomposition in the evaluation of a Search Whole Subtree operation, many sub-requests can be generated to many subordinate DSAs. In the '88 version of the Standard, when replication was not supported, a superior DSA could be reasonably sure that only one subordinate DSA would hold each entry. Therefore, the transmitting (superior) DSA could assume that each receiving (subordinate) DSA would return a different subset of the complete Search result. Once replication is supported, this assumption is no longer true. Each of the receiving (subordinate) DSAs is potentially capable of providing the complete Search result (w/w 9.5). In order to avoid receiving many duplicate results, the transmitting DSA may perform either a master only strategy (§ 9.13.15) or sequential multi-chaining coupled with the exclusions parameter.

When performing sequential multi-chaining, the result received from the first subordinate DSA will have the Already Searched parameter (Table 9.5) filled in to indicate which subtrees below the target object have been searched. The superior DSA will copy these names into the exclusions field of the chained request that it sends to the second subordinate DSA. (The exclusions parameter actually contains the relative distinguished names of these subtrees.) When the second subordinate DSA receives the request, it will not search the subtrees identified by the exclusions field. It too will identify, via the Already Searched parameter of its Search result, the RDNs of the subtrees that it has searched. These will be added to the exclusions parameter by the superior DSA, prior to passing the request to the third subordinate DSA. The 'exclusions' field is therefore a cumulative record of the subtrees that have already been searched. DSAs receiving Search requests with this field present, should not search these subtrees again. Hence duplicate results are avoided.

The exclusions field is not needed when the 'don't use copy' service control is set to True, since only master entries will be returned by each DSA.

DSAs that do not wish to make use of the exclusions field, may still perform multi-chaining (either parallel or sequential), but need to be aware that duplicate results may be received, with the consequent waste of resources that this implies. Furthermore, DSAs are mandated to remove all duplicate results that they receive. However, if the results have been digitally signed, it is not possible to remove duplicate results without invalidating the signatures. Therefore, when using digital signatures in a chained Search operation, a DSA should either use sequential multi-chaining and the exclusions parameter, or sequential or parallel multi-chaining and the exclude shadows parameter.

9.13.15 Exclude Shadows

If DSAs wish to use parallel multi-chaining, then the exclusions field cannot be used to prevent duplicate results. Hence the need for the exclude shadows parameter. Exclude shadows, when set to True, forbids a DSA from including shadow copies in a List or Search result. It is therefore similar to the 'don't use copy' service control that can be set by the user. Exclude shadows guarantees that duplicate results will not be received by the superior DSA, no matter which type of multi-chaining is used, simply because there is only one master copy of each entry. Exclude shadows may not be the most efficient way of evaluating a Search operation, but it allows a '93 DSA to follow a master only strategy, and therefore behave like '88 conformant DSAs that do not support replication.

Since an '88 DSA cannot set this new '93 parameter, a '93 DSA receiving a request from an '88 DSA must assume that the default value has been set. The '93 Standard states that the default is False. However, a defect report has been submitted, suggesting that the default should be True, so that an '88 DSA does not receive a mixture of signed masters and replicas that it cannot dispose of.

Fig. 9.8 Duplicate results caused by multiple NSSRs and replication.

9.13.16 Name Resolve On Master

This parameter is again present due to replication. The parameter is present to allow a master only strategy to be adopted when NSSRs are encountered during distributed name resolution. Because a superior DSA which holds NSSRs does not know which children are present in which subordinate DSAs, it is possible for an operation to be performed more than once when there are replicas present. For example, in Fig. 9.8, the subordinates of {..O=XYZ} are mastered in either DSA2 or DSA3, and are replicated in the other DSA. Parallel multi-chaining by DSA1 to both of its subordinate DSAs would cause the operation to be performed twice. The 'name resolve on master' flag allows the superior DSA to mandate that only the subordinate DSA holding the master copy of the entry should continue with name resolution. The Standard dictates that 'name resolve on master' shall be set to True by the modification operations when they encounter NSSRs during name resolution.

Again there is a problem for '88 DSAs, since they cannot set this '93 parameter. The default value should be True, so that duplicate processing is not performed on behalf of an '88 DSA. The default value is currently False.

9.13.17 RDNs Resolved

RDNs Resolved is an optional parameter of referrals. It is used to signal exactly how many of the RDNs in the target object name have actually been resolved by the DSA generating the referral. Normally this number will be one less than the 'next RDN to be resolved' field of Operation Progress. In this case the RDNs Resolved parameter can be missing. If, however, the referral was generated from a cross reference, there could be a significant difference between the above two parameters e.g. RDNs Resolved might actually be zero, whilst 'next RDN to be resolved' might be three or four. RDNs Resolved therefore allows the receiver of the referral to more closely track the actual progress of distributed name resolution, which 'next RDN to be resolved' does not always allow.

9.13.18 Return To DUA

Return to DUA is a '93 parameter that arose out of the access control security work. If a DSA does not wish to return entry information via a chained result, because it does not trust some of the intermediate DSAs in the chain, then it would like the DUA to contact it directly via the DAP. The DSA therefore returns a referral to the DUA, setting the Return to DUA parameter to True, so that intermediate DSAs know not to act on the referral themselves. When Return to DUA is set to True, reference type is set to self, indicating that the DSA used its 'my access point' knowledge attribute to generate the referral.

9.14 CHAINING RESULTS

When a DSA has finished evaluating a Directory operation, assuming that the operation is successful, it formulates a result that is to be returned to the DUA. If the incoming operation came via another DSA, through chaining, then some extra parameters are added to the result. These extra parameters, called the Chaining Results (Table 9.5), are intended for the sole consumption of the DSA that transmitted the chained operation. If that DSA also received the operation from another DSA, then it will extract the Chaining Results, modify them, and then attach the updated Chaining Results to the operation result. When the result arrives at the initial DSA in the chain (this is usually the home DSA) it will extract the Chaining Results and pass the original operation result to the DUA. At no time will the original operation result be modified by the intervening DSAs, except in the case of unsigned List and Search results. In this case a superior DSA in the chain will merge together the unsigned results from all the subordinate DSAs, removing any duplicate results during the process.

Table 9.5 The parameters of Chaining Results
Parameter ASN.1 Parameter Encoding Described in
Domain Information Any 9.13.9
Cross References 
Cross Reference 
     Context Prefix 
     Access Points 		 SEQUENCE of Cross Reference 
SET { 
     Distinguished Name, 
     Access Point Information }		 9.13.7 
Security Parameters See Table 5.5  5.4.2
*Already Searched Exclusions 9.13.14
* signifies a parameter added in the '93 edition of the Standard