VALUE X500 OPERATIONAL INTERWORKING FORUM AND PLATFORM FINAL TECHNICAL REPORT INRIA 01-01-93 30-04-94 Version : 1.1 PLAN ==== 1. Introduction 2. General results 3. Main Issues / Recommendations 3.1 Distribution of entries and operations 3.1.1 Knowledge/Data model 3.1.2 Name resolution 3.1.3 DIT organization 3.1.4 Chaining / referral mode 3.1.4.1 Following the references : When ? Which directory agent ? 3.1.4.2 Relay DSA 3.2 Copies 3.2.1 The copy model / the replication protocol 3.2.2 Copies and name resolution 3.2.3 Practical considerations 3.3 Aliases 3.4 Loops 3.5 Client algorithms 4. Conclusion 5. Annex 1. INTRODUCTION =============== The Operational Interworking Forum and Platform (OIFP) is part of the VALUE PARADISE X500 Project which is an initiative of the European Commission to continue the provision of some essential X500 services. Initial experiences have demonstrated that different implementations, all conformant to the same standard may fail to provide acceptable operational interworking under specific data or knowledge distribution configurations. For this reason, it was decided to provide the DSA managers and the developers/suppliers of X500 Directory software with the OIFP service. The main goal is to identify and discuss interworking problems, not to give a label to implementations. Three different implementations have been connected. In order not to make any positive or negative publicity, the name of the implementations is not disclosed. Initially only interworking problems were to be addressed. Given that several conformance problems have been encountered so far, it has been decided to take them into account. Nevertheless the general approach has not been changed, we do not check each protocol data unit systematically but try to make interwork different implementations in various contexts. This final report presents general results and tries to outline the main issues dealt with during this project with a view to providing broad conclusions and recommendations. People interested in specific technical issues can read the 3 technical quarterly reports, in which the different problems that we encoutered are detailed. These reports are available on the PARADISE FTP server : ftp://ftp.paradise.ulcc.ac.uk/paradise/oifpreport1.txt ftp://ftp.paradise.ulcc.ac.uk/paradise/oifpreport2.txt ftp://ftp.paradise.ulcc.ac.uk/paradise/oifpreport3.txt You will find the plans of these reports in the annex. If you require any further information regarding these reports you can contact : Name : Paul-Andre Pays Bruno Koechlin Telephone: +33 1 39 63 54 58 +33 1 39 63 57 36 Email: oifp@pamir.inria.fr S=OIFP; OU=pamir; O=INRIA; P=INRIA; A=ATLAS; C=FR Address: INRIA Institut National de Recherche en Informatique et Automatique B.P. 105 / 78153 Le Chesnay Cedex / France Fax : +33 1 39 63 53 30 / Twx: 697033 F 2. GENERAL RESULTS ================== 53 reports addressing problems were issued during the project. We have tried to classify these reports in different categories in order to give a global idea of the results. These categories should not be taken too strictly, some reports could have belonged to several categories. Classification according to the cause : - 24 : bugs - 24 : interpretation of the standard / model - 5 : standard By bugs, we mean mistakes in the products which can be fixed easily. The consequences are mainly simple non-conformance problems. The second category represents problems due to the interpretation of of the standard, the model used by the designers of the products to implement the standard. The last category results from flaws or shortcomings in the standard. Classification according to the issue : - 27 : distribution of entries and operations - 4 : copies - 7 : loops - 4 : aliases - 11 : miscellaneous The problem of the distribution of entries and operations is a crucial issue. It represents more than half of the reports but in fact other issues are often connected to it. It consumed at least 80% of the resources for this project. The miscellaneous problems are mostly errors in the encoding of the protocol data units or in the value of parameters. We can consider that among these problems : - 31 are fixed - 3 are partially fixed - 19 are not fixed 19 problems have not been fixed because - they were due to the standard - they require too deep a modification of the product - they could not be solved during the project but should be fixed in the short term 3. MAIN ISSUES / RECOMMENDATIONS ================================ 3.1 DISTRIBUTION OF ENTRIES AND OPERATIONS ------------------------------------------ 3.1.1 Knowledge / Data model ---------------------------- The implementations which took part in this project have very different knowledge models. This has negative effects, specially on the name resolution which is a crucial aspect of the X.500 model. Compatibility between RFC-1276 and non RFC-1276 DSAs ---------------------------------------------------- RFC-1276 was written by S. Kille in order to define a replication mechanism which is not available in the X500-88 standard. This interim mechanism was intended to be simple in order to be easily implemented and deployed. To make it simple the X500 model was restricted and specially the knowledge model. These restrictions induce incompatibilities with other models, moreover the "spot shadowing" technique designed to interwork with non-RFC-1276 was not implemented. Incompatibilities arose whatever the respective position of the RFC-1276 and non-RFC-1276 DSAs (superior or subordinate). They were related to the entries distribution between the DSAs and the configuration of the knowledge information. Work has been done on both sides to tackle them. The non specific subordinate reference, which is optional in the standard, has been implemented on a non-RFC-1276 DSA to provide a solution when the non-RFC-1276 DSA is the superior DSA and the RFC-1276 DSA the subordinate one. This makes it possible to leave the superior entry in the non-RFC-1276 DSA and to put all the subordinate entries in the RFC-1276 DSA without having to register a subordinate reference for each subordinate entry which is too difficult to manage if you have many subordinate entries. New mechanisms have been implemented in a RFC-1276 DSA aimed at interworking with non-RFC-1276 DSAs. Briefly, they make it possible to cope with situations where all the subordinate entries are not in the Entry Data Block as defined in RFC-1276. Most of the problems have been solved but we did not have enough time to fully validate these mechanisms. Nevertheless there is still a basic problem with the semantic of what is called a subordinate reference and which is in fact a non specific subordinate reference. From the operational point of view this has a negative effect on standard implementations which interpret, in certain circomstances, the non existence of an object in a RFC-1276 DSA as a DIT inconsistency and may raise an alarm. Optional references ------------------- The standard defines two optional references : - the non specific subordinate reference - the cross reference The non specific subordinate reference is not very useful. It can enhance the compatibility between RFC-1276 and non-RFC-1276 DSAs, which is why it was implemented in one product. It could be used to share the same naming context between different DSAs operated by different service providers, but is it relevant ? Given the hierarchical structure of the DIT, DSAs which manage the top levels of the DIT are bottlenecks : if DSAs only use superior and subordinate references, all the operations regarding another subtree of the DIT must go up to the first level of the DIT and down to the target subtree. Bottlenecks can be avoided if cross references pointing to the target subtree are set up, the operation would go directly to the DSA responsible for the target tree. Using this mechanism requires that : - the cross reference is implemented in the product which is currently not the case in all of them - mechanisms aimed at distributing these references exist Knowledge distribution / Knowledge representation ------------------------------------------------- The previous paragraph raises the problem of the knowledge distribution. This is a key issue. Apart from the RFC-1276 model which allows DSAs to distribute knowledge with major restrictions (no genuine subordinate reference, no cross reference) using the replication mechanism and some discovery "tools" based on DAP, this issue has not been addressed. This is mainly due to the fact that the 88 standard has not defined the representation of the knowledge information preventing products from exchanging this type of information. In our opinion, work should be done on caching since it is likely to be the most efficient mechanism to handle cross references. 3.1.2 Name resolution --------------------- Because of the problems related to this issue, the interworking level between the implementations involved in this project was very low at the beginning of the project. This prevented any deployment of a heterogeneous operational infrastructure. We will not go into detail because this would require presenting very technical aspects of the standard. If you need further information you can read the quarterly technical reports or contact the authors of this report. The problems are mainly due to - the complexity of the standard which "encourages" bugs - the difference between the knowledge and data models of the implementations - the fact that implementations had not been assessed soon enough in a heterogeneous environment where product designers would have been faced with different interpretetions and implementations of the standard. Most of these problems were difficult to identify at the user level in a homogeneous infrastructure but immediate in a heterogeneous one. Very significant progress was made by the implementations coming from a strong involvement of the product suppliers and we can consider that the interworking level between the implementations involved in this project is high enough to provide an operational service. Given that this issue is very technical we cannot give operational recommendations, name resolution must be considered as the core of the X.500 directory system, the implementations must be conformant, there is no way of getting around this kind of problem. Our recommendations will be mainly adressed to users : - be very careful when you integrate a new implementation in an X.500 infrastructure with respect to this issue - be sure that this implementation has been truly involved in a heterogeneous infrastructure 3.1.3 DIT organization ---------------------- The main problem related to the DIT organization is that of distributing the immediate subordinate entries of an entry and the consequences this has on the performance of the one-level search operation. If we take the example of the current PARADISE DIT, below each country entry (C=GB, C=DE, ...) we have mainly organization entries. When one wants to search for an organization, the only operation which can be used at this level of the DIT is a one-level search based on the country entry. If these organization entries are held by the DSAs of each organization, the one-level search must be distributed to each DSA which holds an immediate subordinate of the country entry. The performance of this search is very low. This problem does not exist with RFC-1276 implementations since all the immediate subordinate entries of an entry must be held in the same DSA in a unit called EDB. The drawback is that all the organization entries under a country must be held by the same DSA which means that an organization cannot hold its own entry in its DSA. If an organization wants to keep its own entry in its DSA, the performance problem of the one-level search can be solved by copying the organization entry on the superior DSA, here the national DSA. In our opinion, this is a mandatory requirement for an operational infrastructure. This requires that the implementations are able to handle what we have called "one-level" copies. Given the state of the 88 standard as regards copies (see section 3.2), it is not always straightforward depending on the knowledge model of the implementation. One product could not handle this type of copy at the beginning of the project, it is now able to do so. 3.1.4 Chaining / referral mode ------------------------------ 3.1.4.1 Following the references : when ? Which directory agent ? ----------------------------------------------------------------- The standard defines two basic modes of DSA interaction to process the distributed operations, the "chaining" and the "referral" modes. The principle of the "referral" mode is the following : When a DSA considers that it cannot process a request and must forward it to another DSA (which we will call the target DSA) according to a knowledge reference, it does not forward the query to this target DSA (as it would have done in the chaining mode) but returns, to the originator of the request, the address of the target DSA with the status of the query in a continuation reference. We configured our DSAs so that they use the referral mode and the result was that referrals were seldom followed, consequently the user did not get the result. Yet, in our opinion the referral mode should be the mode used by the DSAs holding the top of the DIT because it would be impossible in a wide scale infrastructure to chain all the operations through the top level DSAs. What are the main reasons (apart from bugs) ? - continuation references can be returned in two different protocol data units (dsaReferral, partial result) and it is not always clear in the standard which one should be returned. The implementations have different behaviours. - implementations consider that continuation references must be followed irrespective of the type of the protocol data unit which contains the reference. Others don't and for instance only follow references contained in dsaReferrals. - when a partial result is returned a component called limitProblem can indicate why a partial result was only returned. The standard does not specify what the response of a directory agent should be depending on the values of this parameter. The implementations have different interpretations of this parameter, for instance one considers that if this parameter is set up the reference must not be followed, on the other hand another implementation considers this parameter as informational and follows the references. From this, we can draw two requirements : - guidelines regarding this issue must be defined in an X.500 infrastructure. We think that references must but followed or not irrespective of the protocol data unit which contains them. Further investigation should be carried out regarding the limitProblem. For the moment we consider that if the limitProblem is set up, following references is not advisable, if not, references must be followed by a directory agent. Which directory agent must follow the references, the DUA or the DSA ? In our opinion, a DSA which is not bound to the DUA which sent the operation must not follow references. So it is up to the DUA or the DSA bound to the DUA to follow the reference. The key point here is that a directory agent which follows references must have a complete network connectivity and it may be difficult to provide DUAs with a complete connectivity if you have plenty of them distributed in personal computers or work stations. We propose two different architectures : * if the users' P.C. or W.S. have the complete DUA functions, unless strong authentication is required, it would be easier, from the management point of view, to use the DSA which is bound to the DUAs as an access point to the X.500 infrastucture and to make it follow the references. * the access point to the X.500 infrastructure is a DUA server which follows the references. The DUA server can be used with display functions or a lightweight protocol by the users' P.C. or W.S.. - directory agents (DSAs and DUAs) must be configurable so that they follow or not references depending on : * the type of the protocol data unit which contains the reference * the values of the limit problem component in order to be usable in any X.500 infrastructure whatever the guidelines. Most products have only a default behaviour regarding these points. We advise users to check the configuration capabilities of the products they use or wish to buy. 3.1.4.2 Relay DSA ----------------- A relay DSA is a DSA which acts as a relay to/from a domain. This means that all the directory operations towards a domain go through this relay DSA and that all the operations going out of this domain go through this relay DSA. Customers may need "relay" servers for at least 3 main reasons : 1. All the different DSAs may not be fully connected to all the networks. For instance, in our community we have DSAs connected only through IP and others only through X25. 2. For access control reasons DSAs (or the network equipment they are connected to) may accept calls coming only from a specific list of network addresses. 3. For X500 interworking reasons DSA managers may wish to dialog only with one specific DSA and not to have to be faced with several different implementations spread throughout the world. The following configuration is required : - the references set in the X.500 infrastructure related to the naming context of the domain must not point towards the internal DSAs of this domain, which really hold the entries, but towards the relay DSA which does not hold the entries. - the relay DSA must have references pointing to the internal DSAs of the domain (these internal DSAs are not directly connected to the whole X500 infrastructure). - the relay DSA must have enough references pointing towards the whole X500 infrastructure to provide the internal DSAs with the external connectivy they require. A relay DSA can contain only these references and no data. Unfortunately providing the relay function is not allowed by the X.500 standard because the standard specifies that as soon as the name resolution has started, it must progress in all the DSAs crossed by the operation. A relay-DSA cannot make the name resolution progress since it does not hold entries and only acts as a relay. In order to provide the relay service, the name resolution algorithm of a DSA must be modified so that it does not require that the name resolution progresses. There is also a requirement regarding the processing of the trace information which must be applied by all the DSAs, they must not check that the name resolution did not progress between two DSAs. The best solution would be to have the possibility of configuring a DSA so as to act as a relay or not. When a DSA is not a relay-DSA don't configure it as a relay-DSA, as it would be less efficient in detecting loops and DIT inconsistencies. 3.2 COPIES ---------- 3.2.1 The copy model / the replication protocol ----------------------------------------------- None of the 3 implementations involved in the project has implemented all the mechanisms required to be able to register and manage a complete copy of an entry in any context : - one has implemented RFC-1276 - another provides only * one-level local copies * whole subtree copy - the last one * local copies By local, we mean that these copies are only seen by the DSA which holds them, they cannot be referenced by remote DSAs. This situation is not surprising since the 88 X.500 standard does not provide the necessary features : - there is no replication protocol - and even more important, there is no standardized representation of pieces of information which must be considered as being part of an entry. These are the subordinate knowledge and the access control information. Each implementation has its own specific representation and they are not compatible. In a heterogeneous environment, this makes it almost impossible to handle real copies, and prevents any replication mechanism from being used. The 88 standard has other shortcomings which also hinder the use of copies. It does not make it possible : * to specify in a reference whether it points to an original or copied entry * to return a reference pointing to the original entry and one or more references pointing to copies. This reduces the scope of copies. We must conclude that, given the 88 X.500 standard, it is not possible to : - represent copies - reference copies - replicate copies This is why X.500 product suppliers have either tried to specify these features in a proprietary and restricted environment or have just implemented a few basic features in order to make copies available in a few crucial contexts (see section 3.1.3 for "one-level copies") 3.2.2 Copies and name resolution -------------------------------- The 88 standard does not specify clearly whether copies can be used for the name resolution. We have found 3 different behaviours among the 3 different implementations : - one never uses copies - one uses copies if the "dontUseCopy" option is not set up - one uses copies irrespective of the value of the "dontUseCopy" option The experience gained so far in directory services has shown that copies are mandatory to provide a reliable and efficient service. Consequently, we think that the first behaviour must be abandonned. We think that the second behaviour is the right one. The third has one minor inconvenience if we consider that the subordinate knowledge related to an entry is part of this entry. If the subordinate knowledge of an original entry has been modified and that of a copy has not yet been modified. The result of an operation could be different depending on whether the original or the copy was used for name resolution. One can expect that, if the "dontUseCopy" option was set up, the original and uptodate entry would have been used. We consider that it would be useless to modify a product for this reason if this requires deep modifications given that the inconvenience is more theoretical than operational. 3.2.3 Practical considerations ------------------------------ 3.2.3.1 Copies in the X.500 framework -------------------------------------- What can and should be done from the practical point of view in a heterogeneous environment, given that we consider the 88 X.500 too weak as regards copies to invest too many resources in this issue. The main requirement is to be able to register the copies of the subordinate entries of an entry if these subordinate entries are distributed in different DSAs in order to make the one-level search efficient (see section 3.1.3). There is a cheap way to implement this functionality : Since these copies are mainly aimed at being used during the evaluation phase of the one-level search, they can only be partial copies in the sense that they only contain the data and not the subordinate knowledge associated with the entries. They are not used for the name resolution. It is also realistic to ask an implementation to replicate a whole-subtree. This could be used for instance in an organization which runs several DSAs, each DSA being responsible for one part of the DIT of this organization. Replicating these parts of the DIT improves the response time and the reliability of the directory service. These functions are now provided by the three implementations involved in this project. As regards the replication protocol, apart from defining a proprietary protocol, two strategies can be used : - an out-of-band mechanism using an external representation of the directory information - tools based on DAP Given all the specificities of each product as regards copies, users must be careful and ask for accurate explanations from their (potential) product supplier. As regards the products we have studied, there is no interworking problem provided that the DSA managers take into account all the limitations of their product and those of DSAs they cooperate with and are aware of their consequences on the organization of the DIT. 3.2.3.2 "Fake" copies --------------------- We have seen above that one major problem regarding copies is related to the knowledge : - difficulty in managing the entries with their subordinate knowledge. - the 88 standard does not handle references pointing to copies One solution to get around this problem is to set up two identical DSAs differing only in their network addresses. Both DSAs would be referenced by only one presentation address containing the network addresses of both DSAs. From the X.500 infrastructure, they are seen as one DSA without replication. From the operational point of view the servers are truly duplicated. 3.3 ALIASES ----------- Aliases have negative effects : - From the model point of view, they greatly increase the complexity of the name resolution algorithm : * According to one of the product suppliers, taking aliases into account in the name resolution and evaluation algorithms doubles the processing time when aliases are not used. If aliases are used it is much more than doubled ... * This complexity makes algorithms difficult and very expensive to implement, specially as regards the search operations : bugs were frequent. - From the operational point of view, setting up aliases greatly reduces the efficiency of the search algorithms. When aliases point to entries which are in other DSAs this becomes prohibitively expensive. Aliases are specially inappropriate with a directory application which often uses the search operation. This is unfortunatily the case for the White Pages Service which mainly uses the one-level and whole-subtree search operations. What could be done : - From the model point of view, we consider that basing the aliases dereferenciation on a real time resolution is a mistake, it should have been based on replication. One can object that entries would be duplicated, increasing the volume of data. This is true but it is much less expensive to have entries duplicated than to restart or chain a query for each alias concerned, each time a search operation is performed. Unfortunatily replicating an entry is easy when it is a leaf entry (it could already be implemented),it is not possible with the current state of the standard when it is a node (the subordinate knowledge associated with this entry must also be replicated, see section 3.2.1). - Unfortunatily the only advice we can give is : * don't base any scheme on aliases * never use aliases pointing to another DSA * try not to use aliases pointing to the same DSA 3.4 LOOPS --------- Preventing loops is a main concern for directory services. We have identified the following reasons : - a loop can break down a part of an X.500 infrastructure because an operation loops very quickly (much more quickly than an electronic mail) : much more CPU is consumed, log files grow rapidly and reach the quotas. - unlike an electronic mail which has no state, an X.500 operation goes through different states according to the name resolution and aliases dereferenciation. This makes the loops more difficult to identify. Nevertheless, reliable loop detection algorithms can be implemented provided that all the directory agents set up the parameters related to the state of an operation properly, if not it is much more difficult. This emphasises again the importance of the quality of the name resolution. - DUAs, and more widely, directory clients play an active part in an X.500 infrastructure : * they can relay an operation according to a reference returned by a DSA. * they can start a new operation according to the result of a previous one. If they don't keep enough memory of the history of an operation, and don't analyse the progression of an operation each time they relay it or start a new one they can induce loops very easily. This will be specially important, if DUAs are bound to DSAs which use the referral mode or deal with references received from the X.500 infrastructure. The shortcomings that we identified in the DSAs loop detection algorithm were fixed easily. On the other hand, as regards directory clients, progress must be made. The configuration of the X.500 infrastructure with respect to the chaining/referral mode can also reduce the risk of loops : Directory clients : ------------------- To provide an efficient service directory clients have to use different DAP basic operations to select an entry or a set of entries which meet the user requirements. A directory client assesses the result of each basic operation to perform a new one, using complex algorithms. We have identified loops at two levels : - at the DAP level when the DUA receives one or several continuation references and relays the query according to the reference. - outside the DAP level when a client produces a new query according to the result of the previous one. The first case is easy to solve, it requires setting the the chaining arguments properly. Most clients do not do this, the chaining information received in the reference is ignored, encouraging loops. Just using the standard facilities of the protocol would almost suppress this risk of loops. The second case is more difficult to tackle because we are outside the X.500 protocol and it is up to each software developer to design the necessary mechanism to avoid loops. This requires memorizing the history of a request and being able to compare the current state with the previous ones. To achieve this, the DAP layer of the client software must return the necessary chaining information to the upper layer which interprets the DAP operation result in order to perform a new one (or return a result to the user). Configuration of the X.500 infrastructure ----------------------------------------- From our experience in managing distributed applications, we have drawn the conclusion that clients are less reliable that servers : - server are managed by technical people, clients are often managed by users - clients are more distributed and more difficult to control - clients are not always upgraded in phase with the rest of the infrastructure - there are often many more types of clients than types of servers so it is difficult to assess all of them - clients software is more easily available than servers, users may introduce clients irrespective of guidelines or rules defined by the managers of the infrastructure. Different solutions can be proposed to reduce the risk of loops : - one can limit the number of cross references. This would be an efficient solution as regards loops but this would reduce the efficiency of the infrastructure by causing more chaining and bottlenecks at the top of the DIT. - in an environment where many of DUAs are distributed,since loops are much more likely to happen in the referral mode, the infrastructure could be configured so that the DSAs, where DUAs bind, always follow the continuation references irrespective of the protocol data unit which contains the reference (dsaReferral / partial result see section 3.1.4.1) - another solution would be to reduce the number of clients directly connected to the infrastructure and to have what we have called a DUA server, which is an access point to the X.500 infrastructure, using DAP and evolved algorithms to search in the DIT. Lightweight directory user interfaces can use this server through a lightweight protocol or just a display function. More effort can be put into the quality and reliability of this server than into many of distributed DUAs. In our opinion, the last solution is the best one provided that users do not need a strong authentication. 3.5 CLIENT ALGORITHMS --------------------- This section is only dedicated to White Pages Service clients. We can separate clients into two main categories : - real DUAs which are just able to perform the basic DAP operations. These can be useful for DSA managers but are useless for end users. - clients which can perform the basic DAP operations and which are able to interpret the results of these operations in order to produce another operation. The latter category can also be divided into two sub-categories : - browsers : the user can navigate in the DIT, following the nodes of the DIT. In our opinion this type of client can be used in a pilot phase but cannot be used in a wide-scale infrastructure for at least three main reasons : * when you browse, you need to list the subordinate entries of an entry, if you have too many subordinate entries it will not be acceptable from the user point of view. This will happen for instance below the national level where you will have hundreds or thousands of organizations registered under a country. * the work done on the legal issues has shown that listings were often forbidden * service providers will not accept that users navigate among the data that they manage. - clients that try to find an entry or a set of entries with an approximate value of the name(s) provided by the user. They search in the DIT without disclosing the structure and content of the DIT to the user. PARADISE has demonstrated that as regards the White Pages Service, this type of client is the most appropriate. This is why we will only focus on this type of client. There is general agreement on the basic strategy of this type of client : - using the read and the one-level search operations at the top of the DIT where a whole-subtree search is not possible in order to find the first RDNs of the target object. - as soon as a whole-subtree search is possible, use it. This raises at least two problems : - when can one move from the one-level search to the whole subtree search ? On the one hand, a client may perform a whole-subtree too early which would lead to exploring too large a part of the DIT and having bad performances. On the other hand, a client may perform a sequence of one-level searches when a whole-subtree search performed earlier would have returned the result more quickly. For instance, this will be the case if the whole subtree is in the same DSA where the attributes used as filters are indexed. - is it still relevant to perform another search, in other words, has a leaf object been reached ? It would be useless to perform a one-level or a whole-subtree search on a leaf object. Two main strategies are possible : The first one is to assume a particular type of search will be relevant or not, depending on the classes an entry belongs to. For instance, - assuming a person entry to be a leaf object, further processing must not be carried out below this class of entry - assuming an organization not to be a leaf object, further processing must be carried out below this class of entry - below a country a whole-subtree search is not possible - below an organization a whole-subtree search is possible - below an organizational unit a whole-subtree search is advisable This requires a homogeneous schema which is a difficult assumption in an open environment. If we look at the last example, it is unlikely to be possible to apply the same search policy to all the organizations given their differences in size and structure. The second strategy is to add the appropriate information in the DIT. For instance one implementation has defined a nonLeafObject class which is used to determine whether an entry is a leaf object or not. Appropriate information could also be associated with an entry in order to indicate whether a whole-subtree search based on this entry is advisable or not in order to move from the one-level search to the whole-subtree search at the most appropriate level of the DIT. Nevertheless we cannot hope to have generic client algorithms which would be efficient whatever the schema. The fact that X.500 is specified as a generic directory technology is a bit misleading. We often met people who thought that it was possible to organize their part of the DIT as they wanted, to connect it to PARADISE and that this would not have any impact on the service. Although it is true that, from the model point of view, X.500 is able to handle different types of objects, is very flexible as regards the organization of the DIT, from the operational point of view it is not. Clients must be adapted to the application and to the schema. The concept of "Generic or standard search algorithms" only makes sense in a common schema. 4. CONCLUSION ============= To conclude we have selected a set of straightforward recommendations that we consider to be crucial : - check the "distribution" capacity of an implementation before introducing it in an X.500 infrastructure and specially the signification of the knowledge references it uses - conformance centers must check the name resolution algorithm very carefully, it is an expensive task, given all the possible cases but this must be carried out. - don't use aliases (except local aliases) - assess the copy facility of a product before introducing it in an X.500 infrastructure - if the subordinate entries of an entry are distributed among different DSAs the superior DSA must hold a copy of these subordinate entries in order to make the one-level search efficient - guidelines regarding the clients algorithm must be enforced - use cross references in order to avoid the bottleneck of the tree structure, further studies should be carried out on the references distribution - replication is mandatory to provide an efficient service. Given the state of the 88 standard, the most efficient and easiest way to achieve replication is to duplicate the DSAs and to put in the presentation address several network addresses pointing to the master DSA and its copies. Given the state of the products at the beginning of the project, it would have been impossible to provide an operational service in a heterogeneous environment mixing these implementations. Significant progress has been made and we can consider today that the provision of such a ervice is possible. Our final recommendation is : - choose products which have actually been involved in a heterogeneous X.500 infrastructure. 5. ANNEX ======== Technical quarterly report 1 ---------------------------- 1. Introduction 2. DIT distribution and knowledge model 2.1 Distribution of the immediate subordinate entries of an entry 2.2 Setting references pointing to many immediately subordinate entries 2.3 Efficiency of the one-level search 2.4 Cross Referencing 3. Chained operations 3.1 Defect regarding the search type modification 3.2 DSA behaviour - Evaluation phase - Multiple object evaluation 4. Client algorithms 5. Aliases 5.1 Alias dereferencing and search type modification 5.2 Option : searchAlias 5.3 Alias at a non-leaf level 6. Miscellaneous problems 6.1 Bind / Session connect 6.2 ASN1 Error 6.3 Syntax error 6.4 Virtual entry 7. Conclusion - Further investigations Technical quarterly report 2 ---------------------------- 1. Introduction 2. Name Resolution 2.1 State of the OperationProgress component issue 2.2 Control of the Name Resolution / Relay-DSA 3. Subordinate Reference / Non specific subordinate Reference 4. DSA referral / Result with Continuation References 4.1 A specific case 4.2 General considerations 5. Partial result / Limit Problem 6. Encoding Error 6.1 Unbind 6.2 NameError 6.3 DSAReferral 6.4 PSAP RFC-1277 7. Conclusion Technical quarterly report 3 ---------------------------- 1. Introduction 2. Name Resolution / Distribution of operations 2.1 The targetObject and operationProgress components 2.2 The nextRDNToBeResolved component : an optional component ? 2.3 Distribution of subordinate entries in different DSAs 2.4 Operation resolution / optimization 3. Loops / Continuation references 4. Semantic of the limitProblem component / consequences 5. Copies 5.1 Copies and distribution of an operation 5.2 Copies and name resolution 5.3 Copy of a complete subtree / one-level search 5.4 Copies, general considerations 6. Search / indexed attributes 7. Just one comment on legal issues 8. Miscellaneous bugs 8.1 BaseObject / alias 8.2 The optional targetObject component 8.3 DUA / Stack of references 8.4 The dontusecopy option 8.5 Wrong DN 8.6 Incorrect Trace 8.7 Merging Results 8.8 Reference pointing to itself 8.9 Filters 9. Conclusion