џWPCL ћџ2BJ|xа АH аа АА X агга ХА6p&А6p&Х аеЂ† а Hh аааУ Уб cмˆ4 PŽТ б Fascicle VIII.8 Љ Rec. X.518 PAGE1 Ђее~† а HH аааУ Уб cмˆ4 PŽТ бPAGE12 Fascicle VIII.8 Љ Rec. X.518 ~еа Hh ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаа X  аб cмˆ4 PŽТ бУ УУУThe drawings contained in this Recommendation have been done in AUTOCADФ ФФФ ‚У УRecommendation X.518 Ср(;Сб cмˆ4 PŽТ бTHE DIRECTORY Љ PROCEDURES FOR DISTRIBUTED OPERATION Ф ФУУжЯ а HH ааа)Recommendation X.518 and ISO 9594Љ4, Information Processing Systems Љ Open Systems Interconnection Љ The Directory Љ Procedures for Distributed Operation, were developed in close collaboration and are technically aligned.ФФ ж)У УФФб cмˆ4 PŽТ б Та ТС€ HССр(NСб cмˆ4 PŽТ бФ ФУУ(Melbourne, 1988)ЦЦ Ср(RСФФCONTENTS SECTION 1 Љ УУIntroduction ФФ0С СУУIntroductionФФ 1С СУУScope and field of applicationФФ 2С СУУReferencesФФ 3С СУУDefinitionsФФ 4С СУУAbbreviationsФФ 5С СУУNotationФФ SECTION 2 Љ УУOverviewФФ 6С СУУOverviewФФ SECTION 3 Љ УУDistributed directory modelsФФ 7С СУУDistributed directory system model ФФ8С СDSA interactions model С С8.1СpСChaining С С8.2СpСMulticasting С С8.3СpСReferral С С8.4СpСMode determination 9С СУУDirectory distribution ФФ10С  СУУKnowledge ФФС С10.1Си СMinimal knowledge references С С10.2Си СRoot context С С10.3Си СKnowledge references С С10.4Си СKnowledge administration SECTION 4 Љ УУDSA abstract service ФФ11С  СУУOverview of DSA abstract service ФФ12С  СУУInformation types ФФС С12.1Си СIntroduction С С12.2Си СInformation types defined elsewhere С С12.3Си СChaining arguments С С12.4Си СChaining results С С12.5Си СOperation progress С С12.6Си СTrace information С С12.7Си СReference type С С12.8Си СAccess point С С12.9Си СContinuation reference 13С  СУУAbstractЉbind and abstractЉunbind ФФС С13.1Си СDSA bind С С13.2Си СDirectory unbind 14С  СУУChained abstractЉoperations ФФ15С  СУУChained abstractЉerrors ФФС С15.1Си СIntroduction С С15.2Си СDSA referral SECTION 5 Љ УУDistributed operations procedures ФФ16С  СУУIntroduction ФФС С16.1Си СScope and limits С С16.2Си СConceptual model С С16.3Си СIndividual and cooperative operation of DSAs 17С  СУУDistributed directory behaviour ФФС С17.1Си СCooperative fulfillment of operations С С17.2Си СPhases of operation processing С С17.3Си СManaging distributed operations С С17.4Си СOther considerations for distributed operation С С17.5Си СAuthentication of distributed operations 18С  СУУDSA behaviour ФФС С18.1Си СIntroduction С С18.2Си СOverview of the DSA behaviour С С18.3Си СSpecific operations С С18.4Си СOperation dispatcher С С18.5Си СLooping С С18.6Си СName resolution procedure С С18.7Си СObject evaluation procedures С С18.8Си СResult merging procedure С С18.9Си СProcedures for distributed authentication УУAnnex A ФФЉ ASN.1 for distributed operations УУAnnex B ФФЉ Modelling of knowledge УУAnnex C ФФЉ Distributed use of authentication УУAnnex D ФФЉ Distributed directory object identifiers SECTION 1 Љ УУIntroduction аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚ФФУ У0ТX ТIntroductionФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа0.1С  СThis document, together with the others of the series, has been produced to facilitate the interconnection of information processing systems to provide directory services. The set of all such systems, together with the directory information which they hold, can be viewed as an integrated whole, called the Directory. The information held by the Directory, collectively known as the Directory Information Base (DIB), is typically used to facilitate communication between, with or about objects such as OSI application entities, people, terminals, and distribution lists. а H а0.2С  СThe Directory plays a significant role in Open Systems Interconnection, whose aim is to allow, with a minimum of technical agreement outside of the interconnection standards themselves, the interconnection of information processing systems: Та ТТ№ ТС€ СЉСpСfrom different manufacturers;ЦЦ Та ТТ№ ТС€ СЉСpСunder different managements;ЦЦ Та ТТ№ ТС€ СЉСpСof different levels of complexity; andЦЦ Та ТТ№ ТС€ СЉСpСof different ages.ЦЦ а H а0.3С  СThis Recommendation specifies the procedures by which the distributed components of the Directory interwork in order to provide a consistent service to its users. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У1ТX ТScope and field of applicationФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа1.1С  СThis Recommendation specifies the behaviour of DSAs taking part in the distributed Directory application. The allowed behaviour has been designed so as to ensure a consistent service given a wide distribution of the DIB across many DSAs. а H а1.2С  СThe Directory is not intended to be a general purpose database system, although it may be built on such systems. It is assumed that there is a considerably higher frequency of queries than of updates. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У2ТX ТReferencesФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаRecommendation X.200 ЉС СOpen Systems Interconnection Љ Basic Reference Model а H аRecommendation X.208 ЉOpen Systems Interconnection Љ Specification of Abstract Syntax Notation (ASN.1) а H аRecommendation X.500 ЉС СThe Directory Љ Overview of Concepts, Models and Services Recommendation X.501 ЉС СThe Directory Љ Models Recommendation X.511 ЉС СThe Directory Љ Abstract Service Definitionд œ'дŒRecommendation X.519 ЉС СThe Directory Љ Protocol Specifications Recommendation X.520 ЉС СThe Directory Љ Selected Attribute Types Recommendation X.521 ЉС СThe Directory Љ Selected Object Classes а H аRecommendation X.407 ЉС СMessage Handling Systems Љ Abstract Service Definition Conventions аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У3ТX ТDefinitionsФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe definitions contained in this paragraph make use of the abbreviations defined in  4. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа3.1Тh  ТУУOSI Reference Model DefinitionsЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThis Recommendation makes use of the following term defined in X.200: Та ТТ№ ТС€ Сa)СpСapplication entity title.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа3.2Тh  ТУУBasic Directory DefinitionsЦЦ а Hр ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThis Recommendation makes use of the following terms defined in Recommendation X.500: Та ТТ№ ТС€ Сa)СpС(the) Directory;ЦЦ Та ТТ№ ТС€ Сb)СpСDirectory Information Base.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа3.3Тh  ТУУDirectory Model DefinitionsЦЦ а Hр ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThis Recommendation makes use of the following terms defined in Recommendation X.501: Та ТТ№ ТС€ Сa)СpСaccess point;ЦЦ Та ТТ№ ТС€ Сb)СpСalias;ЦЦ Та ТТ№ ТС€ Сc)СpСdistinguished name;ЦЦ Та ТТ№ ТС€ Сd)СpСDirectory Information Tree;ЦЦ Та ТТ№ ТС€ Сe)СpСDirectory System Agent;ЦЦ Та ТТ№ ТС€ Сf)СpСDirectory User Agent;ЦЦ Та ТТ№ ТС€ Сg)СpСrelative distinguished name.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа3.4Тh  ТУУAbstract Service Definition ConventionsЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThis Recommendation makes use of the following terms defined in X.407: Та ТТ№ ТС€ Сa)СpСabstract error;ЦЦ Та ТТ№ ТС€ Сb)СpСabstract operation;ЦЦ Та ТТ№ ТС€ Сc)СpСresult.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа3.5Тh  ТУУDistributed Operation DefinitionsЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThis Recommendation makes use of the following terms, as defined here: а H аТа ТТ№ ТС€ Сa)СpСchaining: a mode of interaction optionally used by a DSA which cannot perform an operation itself. The DSA chains by invoking an operation of another DSA and then relaying the outcome to the original requestor;ЦЦ а H аТа ТТ№ ТС€ Сb)СpСcontext prefix: the sequence of RDNs leading from the Root of the DIT to the initial vertex of a naming context, corresponds to the distinguished name of that vertex;ЦЦ а H аТа ТТ№ ТС€ Сc)СpСcross reference: a knowledge reference containing information about the DSA that holds an entry. This is used for optimisation. The entry need have no superior or subordinate relationship; ЦЦ а Hx аТа ТТ№ ТС€ Сd)СpСDIB fragment: the portion of the DIB that is held by one DSA, comprising one or more naming contexts;ЦЦ а H аТа ТТ№ ТС€ Сe)СpСdistributed name resolution: the process by which name resolution is performed in more than one DSA;ЦЦ а H аТа ТТ№ ТС€ Сf)СpСinternal reference: a knowledge reference containing an internal pointer to an entry held in the same DSA;ЦЦ а H аТа ТТ№ ТС€ Сg)СpСknowledge information: the information which a particular DSA has about the entries it holds and how to locate other entries in the directory;ЦЦ а H аТа ТТ№ ТС€ Сh)СpСknowledge reference: knowledge which associates, either directly or indirectly, a DIT entry with the DSA in which it is located;ЦЦ а H аТа ТТ№ ТС€ Сi)СpСknowledge tree: the conceptual model of the knowledge information that a DSA holds to enable it to perform distributed name resolution;ЦЦ а H аТа ТТ№ ТС€ Сj)СpСmulticasting: a mode of interaction which may optionally be used by a DSA which cannot perform an operation itself. The DSA multicasts the operation, i.e. invokes the same operation of several other DSAs (in series or in parallel) and passes an appropriate outcome to the original requestor;ЦЦ а H аТа ТТ№ ТС€ Сk)СpСname resolution: the process of locating an entry by sequentially matching each RDN in a purported name to a vertex of the DIT;ЦЦ а H аТа ТТ№ ТС€ Сl)СpСnaming context: a partial subЉtree of the DIT which starts at a vertex and extends downwards to leaf and/or nonЉleaf vertices. Such vertices constitute the border of the naming context. NonЉleaf vertices belonging to the border denote the start of further naming contexts;ЦЦ а H аТа ТТ№ ТС€ Сm)СpСnonЉspecific subordinate reference: a knowledge reference that holds information about the DSA that holds one or more unspecified subordinate entries;ЦЦ а H аТа ТТ№ ТС€ Сn)СpСoperation progress: a set of values which denotes the extent to which name resolution has taken place;ЦЦ а Hx аТа ТТ№ ТС€ Сo)СpСreference path: a continuous sequence of knowledge references;ЦЦ а H аТа ТТ№ ТС€ Сp)СpСreferral: an outcome which can be returned by a DSA which cannot perform an operation itself, and which identifies one or more other DSAs more able to perform the operation;ЦЦ а H аТа ТТ№ ТС€ Сq)СpСrequest decomposition: decomposition of a request into subrequests each accomplishing a part of the distributed operation;ЦЦ а H аТа ТТ№ ТС€ Сr)СpСroot context: the naming context for the vertex whose name comprises the empty sequence of RDNs;ЦЦ а H аТа ТТ№ ТС€ Сs)СpСsubordinate reference: a knowledge reference containing information about the DSA that holds a specific subordinate entry;ЦЦ Та ТТ№ ТС€ Сt)СpСsubrequest: a request generated by request decomposition;ЦЦ а H аТа ТТ№ ТС€ Сu)СpСsuperior reference: a knowledge reference containing information about the DSA that holds a superior entry.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У4ТX ТAbbreviationsФ ФЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe following abbreviations are used in this Recommendation: Та ТТ№ ТС€ СDIBСpССи ССЈ СDirectory Information BaseЦЦ Та ТТ№ ТС€ СDITСpССи ССЈ СDirectory Information TreeЦЦ Та ТТ№ ТС€ СDSAСpССи СDirectory System AgentЦЦ Та ТТ№ ТС€ СDUAСpССи СDirectory User AgentЦЦ Та ТТ№ ТС€ СRDNСpССи СRelative Distinguished NameЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У5ТX ТNotationФ ФЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe notation used in this paragraph is defined as follows: а H аТа ТТ№ ТС€ Сa)СpСthe data syntax notation, encoding and macro notation are defined in Recommendation X.208;ЦЦ а H аТа ТТ№ ТС€ Сb)СpСthe notations for abstract models and abstract services are defined in Recommendation X.407.ЦЦ а HH аSECTION 2 Љ УУOverview аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚ФФУ У6ТX ТOverviewФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe Directory Abstract Service allows the interrogation, retrieval and modification of Directory information in the DIB. This service is described in terms of the abstract Directory object as specified in Recommendation X.511. а H аС СNecessarily, the specification of the abstract Directory object does not in any way address the physical realization of the Directory, in particular it does not address the specification of Directory System Agents (DSA) within which the DIB is stored and managed, and through which the service is provided. Furthermore, it does not consider whether the DIB is centralized, i.e. contained within a single DSA, or distributed over a number of DSAs. Consequently, the requirements for DSAs to have knowledge of, navigate to, and cooperate with other DSAs, in order to support the abstract service in a distributed environment, is also not covered by the service description. а H аС СThis Recommendation specifies the refinement of the abstract Directory object, the refinement being expressed in terms of a set of one or more DSA objects which collectively constitute the distributed directory service. Inherent in this is the identification and specification of the DSA ports that are internal to the Directory object. For each such port, this Recommendation specifies the associated abstract services and its procedures. а H аС СIn addition, this Recommendation specifies the permissible ways in whichд Д-д the DIB may be distributed over one or more DSAs. For the limiting case where the DIB is contained within a single DSA, the Directory is in fact centralized; for the case where the DIB is distributed over two or more DSAs, knowledge and navigation mechanisms are specified which ensure that the whole of the DIB is potentially accessible from all DSAs that hold constituent entries. С СAdditionally, request handling interactions are specified that enable particular operational characteristics of the Directory to be controlled by its users. In particular, the user has control over whether a DSA, responding to a directory enquiry pertaining to information held in other DSA(s), has the option of interrogating the other DSA(s) directly (chaining/multicasting) or, whether it should respond with information about other DSA(s) which could further progress the enquiry (referral). а H аС СGenerally, the decision by a DSA to chain/multicast or refer is determined by the service controls set by the user, and by the DSA's own administrative, operational, or technical circumstances. С СRecognizing that, in general, the Directory will be distributed, that directory enquiries will be satisfied by an arbitrary number of cooperating DSAs which may arbitrarily chain/multicast or refer according to the above criteria, this Recommendation specifies the appropriate procedures to be effected by DSAs in responding to distributed directory enquiries. These procedures will ensure that users of the distributed Directory service perceive it to be both userЉfriendly and consistent. SECTION 3 Љ Distributed directory models аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У7ТX ТDistributed directory system modelФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe Directory abstract service as defined in Recommendation X.511 models the directory as an object which provides a set of directory services to а H аits users. The services of the directory are modelled in terms of ports, where each port provides a particular set of directory services. Users of the а H аdirectory access its services through an access point. The directory may have one or more access points and each access point is characterized by the services it provides and the mode of interaction used to provide these services. а H аС СThis paragraph addresses the internal structure of the directory object, identifying its constituent objects and their ports, and thereby facilitates the specification of a distributed directory service. а H аС СFigure 1/X.518 illustrates the distributed directory which will be used as the basis for specifying the distributed aspects of the directory. It illustrates the directory object as comprising a set of one or more DSAЉobjects. ‚Ср KСб cмˆ4 PŽТ бFIGURE 1/X.518 Љ T0706790Љ89 б cмˆ4 PŽТ б С СDSA objects are specified in detail in the subsequent clauses of this Recommendation. This clause merely states a number of their characteristics in order to serve as an introduction and to establish the relationship between this Recommendation and other Recommendations. С СDSA objects are defined in order that distribution of the DIB can be accommodated and that a number of physically distributed DSAs can interact in a prescribed, cooperative manner to provide directory services to the users of the directory (DUAs). С СDSA objects, like the Directory object, are characterized by their externally visible ports. The ports associated with a DSAЉobject are of two types: serviceЉports and chainedЉserviceЉports. а H аС СThe serviceЉports of a DSA object are identical to those of the Directory object, namely, read, search and modify. Figure 1/X.518 illustrates that а H аthe serviceЉports associated with a DSA object constitute an accessЉpoint through which directory services are made available. а H аС СThe detailed specification of theУ У readФ Ф, У УsearchФ Ф, and У Уmodify Ф ФserviceЉports of the DSA object can be found in Recommendation X.511. (The protocol specification for the corresponding OSI application service elements, as derived from these port definitions, can be found in Recommendation X.519.) С СIn addition to the serviceЉports of the DSA object which accommodate access to the Directory object, a second set of ports are defined, the chainedЉserviceЉports. These permit interЉDSA communication in order that the Directory abstract service can be realized in a distributed environment. а H аС СThe chainedЉserviceЉports and the operations provided through them are in direct correspondence to the similarly named serviceЉports, and are, respectively, У УchainedReadФ Ф, У УchainedSearchФ Ф, and У УchainedModifyФ Ф. С СThe process of specifying the constituent objects of a more abstract object is termed "refinement". The specification of the refinement of the Directory object into its component parts (the DSAs), and the specification of the abstract service provided by each of them (the DSA Abstract Service) is contained in Section Four of this Recommendation. The protocol specification of the corresponding OSI application service elements, as derived from the chained port definitions, can be found in Recommendation X.519. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У8ТX ТDSA interactions modelФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СA basic characteristic of the Directory is that, given a distributed DIB, a user should potentially be able to have any service request satisfied (subject to security, access control and administrator policies) irrespective of the access point at which the request originates. In accommodating this requirement it is necessary that any DSA involved in satisfying a particular service request have some knowledge (as specified in  10 of this Recommendation) of where the requested information is located and either return this knowledge to the requestor or attempt to have the request satisfied on its behalf. (The requestor may either be a DUA or another DSA: in the latter case both DSAs must have a chained port.) а H аС СThree modes of DSA interaction are defined to meet these requirements, namely "chaining", "multicasting", and "referral". "Chaining" and "multicasting" are defined to meet the latter of the above requirements whilst referrals address the former. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа8.1Тh  ТУУChainingЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThis mode of interaction (depicted in Figure 2/X.518) may be used by one DSA, to pass on a request to another DSA when the former has knowledge а H аabout naming contexts held by the latter. Chaining may be used to contact a single DSA pointed to in a cross reference, a subordinate reference, or a superior reference. Multicasting is a form of chaining, described in  8.2. ‚Ср KСб cмˆ4 PŽТ бFIGURE 2/X.518 Љ T0704500Љ88 б cмˆ4 PŽТ б С СУУNote ФФЉ In Figure 2/X.518, the order of interactions is defined by the numbers associated with the interaction lines. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа8.2Тh  ТУУMulticastingЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThis mode of interaction (depicted in Figures 3a/X.518 and 3b/X.518) may be used by a DSA, to chain an identical request in parallel (a) or sequential (b) to one or more DSAs, when the former does not know the complete naming contexts held by the other DSAs. Multicasting is only used by a DSA to contact other DSAs pointed to in a nonЉspecific subordinate reference. Each of the DSAs is passed the identical request. Normally, during name resolution, only one of the DSAs will be able to continue processing the remote operation, all of the others returning the unableToProceed ServiceError. However, during the evaluation phase of search and list operations, all DSAs in a nonЉ specific subordinate reference should be able to continue processing the request. С СУУNote ФФЉ In Figures 3a/X.518 and 3b/X.518, the order of interactions is defined by the numbers associated with the interaction lines. ‚Ср KСб cмˆ4 PŽТ бFIGURE 3a/X.518 Љ T0704510Љ88 б cмˆ4 PŽТ б Ср KСб cмˆ4 PŽТ бFIGURE 3b/X.518 Љ T0704520Љ88 б cмˆ4 PŽТ б аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа8.3Тh  ТУУReferralЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СA referral (depicted in Figures 4a/X.518 and 4b/X.518) is returned by a DSA in its response to a request which it had been requested to perform, either by a DUA, or by another DSA (in which case both DSAs must have a chainedЉservice port). The referral may constitute the whole response (in which case it is categorized as an error) or just part of the response. The referral contains a knowledge reference, which may be either a superior,д Д-д subordinate, cross or nonЉspecific subordinate reference. а H аС СThe DSA (Figure 4a/X.518) receiving the referral may use the knowledge reference contained therein, to subsequently chain or multicast (depending upon the type of reference) the original operation to other DSAs. Alternatively, a DSA receiving a referral, may in turn pass the referral back in its response. A DUA (Figure 4b/X.518) receiving a referral may use it to contact one or more other DSAs to progress the request. ‚Ср KСб cмˆ4 PŽТ бFIGURE 4a/X.518 Љ T0704530Љ89 б cмˆ4 PŽТ б Ср KСб cмˆ4 PŽТ бFIGURE 4b/X.518 Љ T0704540Љ89 б cмˆ4 PŽТ б С СУУNote ФФЉ In Figures 4a/X.518 and 4b/X.518, the order of interactions is defined by the numbers associated with the interaction lines. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа8.4Тh  ТУУMode determinationЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СIf a DSA cannot itself fully resolve a request, it must chain/multicast the request (or a request formed by decomposing the original one), to another DSA, unless: а H аТа ТТ№ ТС€ Сa)СpСchaining is prohibited by the user via the service controls, in which case the DSA must return a referral or a chainingRequired ServiceError (at its choice), orЦЦ а H аТа ТТ№ ТС€ Сb)СpСthe DSA has administrative, operational, or technical reasons for preferring not to chain, in which case the DSA must return a referral.ЦЦ а H аС СУУNote 1 ФФЉ A "technical reason" for not chaining/multicasting is that the DSA identified in the knowledge reference has no chained service ports. а H аУУС СNote 2 ФФЉ If the localScope service control is set, then the DSA (or DMD) must either resolve the request or return an error. С СУУNote 3 ФФЉ If the user prefers referrals, the user should set chainingProhibited. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У9ТX ТDirectory distributionФ ФЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThis paragraph defines the principles according to which the DIB can be distributed. С СEach entry within the DIB is administered by one, and only one, DSA's Administrator who is said to have administrative authority for that entry. Maintenance and management of an entry must take place in a DSA administered by the administrative authority for the entry. а H аС СAlthough the Directory does not provide any support for the replication of entries, it is nevertheless possible to realize replication in two ways: а H аТа ТТ№ ТС€ СЉСpСCopies of an entry may be stored in other DSA(s) through bilateral agreement. The means by which these copies are maintained and managed is a function of the bilateral agreement and is not defined in this Recommendation.ЦЦ а H аТа ТТ№ ТС€ СЉСpСCopies of an entry may be acquired by storing (locally and dynamically) a copy of an entry which results from a request.ЦЦ а H аС СУУNote ФФЉ The acquisition of cache entries is subject to access control. а H аС СThe originator of the request is informed (via fromCopy) as to whether information returned in response to a request is from a replicated entry or not. A service control, dontUseCopy, is defined which allows the user to prohibit the use of replicated entries. С СEach DSA within the Directory holds a fragment of the DIB. The DIB fragment held by a DSA is described in terms of the DIT and comprises one or more naming contexts. A naming context is a partial subtree of the DIT defined as starting at a vertex and extending downwards to leaf and/or nonЉleaf vertices. Such vertices constitute the border of the naming context. Subordinates of the nonЉleaf vertices belonging to the border denote the start of further naming contexts. а H аС СIt is possible for a DSA's administrator to have administrative authority for several disjoint naming contexts. For every naming context for which a DSA has administrative authority, it must logically hold the sequence of RDNs which lead from the root of the DIT to the initial vertex of the subtree comprising the naming context. This sequence of RDNs is called the context prefix. С СA DSA's administrator may delegate administrative authority for any immediate subordinates of any entry held locally to another DSA. A DSA that delegated authority is called a superior DSA and the context that holds the superior entry of one for which the administrative authority was delegated, а H аis called the superior naming context. Delegation of administrative authority begins with the root and proceeds downwards in the DIT; that is, it can only occur from an entry to its subordinates. а H аС СFigure 5/X.518 illustrates a hypothetical DIT logically partitioned into five naming contexts (named A, B, C, D and E), which are physically distributed over three DSAs (DSA1, DSA2, and DSA3). С СFrom the example it can be seen that the naming contexts held by particular DSAs may be configured so as to meet a wide range of operational requirements. Certain DSAs may be configured to hold those entries that represent higher level naming domains within some logical part(s) of the DIB, the organizational structure of a large company say, but not necessarily all the subordinate entries. Alternatively, DSAs may be configured to hold only those naming contexts representing primarily leaf entries. а H аС СFrom the above definitions, the limiting case for a naming context can be either a single entry or the whole of the DIT. а H аС СWhilst the logical to physical mapping of the DIT onto DSAs is potentially arbitrary, the task of information location and management is simplified if the DSAs are configured to hold a small number of naming contexts. С СIn order for a DUA to begin processing a request it must hold some information, specifically the presentation address, about at least one DSA а H аthat it can contact initially. How it acquires and holds this information is a local matter. С СDuring the process of modification of entries it is possible that the directory may become inconsistent. This will be particularly likely if modification involves aliases or aliased objects which may be in different DSAs. The inconsistency must be corrected by specific administrator action, for example to delete aliases if the corresponding aliased objects have been deleted. The Directory continues to operate during this period of inconsistency. ‚Ср KСб cмˆ4 PŽТ бFIGURE 5/X.518 Љ T0704550Љ88 б cмˆ4 PŽТ б а H аС СУУNote ФФЉ The Root is not held by any DSA, however some indication must exist at the local level to distinguish those vertices (e.g. C = VV, C = WW) which are immediate subordinates of the Root. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа‚У У10Тр  ТKnowledgeФ ФЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СThe DIB is potentially distributed across multiple DSAs with each DSA holding a DIB fragment; the principles that govern distribution of the DIB are specified in  9 of this Recommendation. а H аС СIt is a requirement of the Directory that, for particular modes of user interaction, the distribution of the directory be rendered transparent, thereby giving the effect that the whole of the DIB appears to be within each and every DSA. а H аС СIn order to support the operational requirements described above, it is necessary that each DSA holding a fragment of the DIB be able to identify and optionally interact with other fragments of the DIB held by other DSAs. а H аС СThis paragraph defines knowledge as the basis for the mapping of a name to its location within a fragment of the DIT. С СConceptually DSAs hold two types of information: Та ТТ№ ТС€ Сa)СpСDirectory Information;ЦЦ Та ТТ№ ТС€ Сb)СpСKnowledge Information.ЦЦ а H аС СDirectory Information is the collection of entries comprising the Naming Context(s) for which the Administrator of a particular DSA has Administrative Authority. а H аС СKnowledge Information embodies the Naming Context(s) held by a particular DSA and denotes how these fit into the overall DIT hierarchy. Name Resolution, the process of locating the DSA which has Administrative Authority for a particular entry given that entry's name, is based on knowledge information. а H аС СA Context Prefix is the sequence of RDNs leading from the Root of the DIT to the initial vertex of a naming context and corresponds to the distinguished name of that vertex. С СA Naming Context comprises a collection of knowledge references and a Context Prefix. A Naming Context must contain exactly the following knowledge references: а H аТа ТТ№ ТС€ СЉСpСAll the internal references which define the internal structure of the portion of the DIT included in the Naming Context.ЦЦ а H аТа ТТ№ ТС€ СЉСpСAll the subordinate and nonЉspecific subordinate references to other Naming Contexts.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа10.1Т№  ТУУMinimal knowledge referencesФФЦЦ а H№ ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаС СIt is a property of the Directory that each entry can be accessed independently of where a request is generated. С СTo accomplish this, each DSA shall at least maintain the following knowledge references: а H аТа ТТ№ ТС€ СЉСpСsubordinate references as defined in  10.3.2 and/or nonЉspecific subordinate references as defined in 10.3.5; andЦЦ Та ТТ№ ТС€ СЉСpСsuperior references as defined in  10.3.3.ЦЦ а Hx аС СIt is then possible to establish a reference path, as a continuous sequence of knowledge references, to all naming contexts within the Directory. а H аС СOptionally, cross references, as defined in  10.3.4 may form part of a reference path to optimize performance. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа10.2Т№  ТУУRoot contextЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СBecause of the autonomy of the different countries or global organizations, there is likely to be no "single" DSA which holds the root context. The functionality of a "rootЉDSA" concerning the name resolution process has to be provided by those DSAs which have administrative authority for naming contexts that are immediately subordinate to the root. These DSAs are called First Level DSAs. Each First Level DSA must be able to simulate the functionality of the "rootЉDSA". This requires full knowledge about the root naming context. The root context is replicated onto each First Level DSA and therefore has to be administered commonly by the autonomous first level administrative authorities. Administration procedures have to be determined by multilateral agreements outside the scope of this Recommendation. а H аТа ТТ№ ТС€ СЉСpСEach first level DSA shall hold the root context, which implies a reference path to each other first level DSA.ЦЦ а H аТа ТТ№ ТС€ СЉСpСEach nonЉfirst level DSA shall have a superior reference, which implies a reference path to any arbitrary first level DSA.ЦЦ а HH ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа10.3Т№  ТУУKnowledge referencesЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СThe knowledge possessed by a DSA is defined in terms of a set of one or more knowledge references where each reference associates, either directly or indirectly, entries of the DIB with DSAs which hold those entries. а H аС СTo be able to fulfill the requirements to reach every DIB entry from any DSA, every DSA is required to have knowledge about the entries which it itself holds, and about subordinates and possibly superiors thereof. This gives rise to the following types of knowledge references: Та ТТ№ ТС€ СЉСpСInternal referencesЦЦ Та ТТ№ ТС€ СЉСpСSubordinate referencesЦЦ Та ТТ№ ТС€ СЉСpСSuperior referencesЦЦ Та ТТ№ ТС€ СЉСpСNonЉspecific subordinate references.ЦЦ а H аТа ТТ№ ТС€ СAdditionally, for optimization purposes the following type of optional reference is defined:ЦЦ Та ТТ№ ТС€ СЉСpСCross referencesЦЦ а H аС СIn the event that the set of knowledge references associated with a particular DSA contain only internal references, the DSA has no knowledge of other DSAs and the DIB is therefore centralized. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС10.3.1С јСУУInternal referencesЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СAn internal reference consists of: Та ТТ№ ТС€ СЉСpСthe RDN corresponding to a DIB entry;ЦЦ а H аТа ТТ№ ТС€ СЉСpСan internal pointer to where the entry is stored in the local DIB. (The specification of this pointer is outside the scope of this Recommendation.)ЦЦ а H аС СAll entries for which a particular DSA has Administrative Authority are represented by internal references in the knowledge information of that DSA. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС10.3.2С јСУУSubordinate referencesЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СA subordinate reference consists of: а Hр аТа ТТ№ ТС€ СЉСpСan RDN corresponding to an immediate subordinate DIB entry;ЦЦ а H аТа ТТ№ ТС€ СЉСpСthe Access Point of the DSA to which Administrative Authority for that entry was delegated.ЦЦ а H№ аС СAll subordinate entries held by another DSA to which this DSA has delegated Administrative Authority, must be represented by subordinateд Д-д references (or nonЉspecific subordinate references as described in  10.3.5). аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС10.3.3С јСУУSuperior referencesЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СA superior reference consists of: Та ТТ№ ТС€ СЉСpСthe Access Point of a DSA.ЦЦ а H аС СEach nonЉfirst level DSA maintains precisely one superior reference. The superior reference shall form part of a reference path to the root. Unless some method outside of the standard is employed to ensure this, for example within a DMD, this shall be accomplished by referring to a DSA which holds a naming context whose context prefix has less RDNs than the context prefix with fewest RDNs held by this DSA. а H аС СIf a new nonЉfirst level DSA is introduced, it must have a minimal initial knowledge, which is represented by the superior reference. Any further knowledge will be added by subordinate references or cross references (as described in  10.3.4). If a new first level DSA is introduced, it must acquire the root context and advise all other first level DSAs. How this is accomplished is outside the scope of this Recommendation. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС10.3.4С јСУУCross referenceЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СA cross reference consists of: Та ТТ№ ТС€ СЉСpСa Context Prefix;ЦЦ а H аТа ТТ№ ТС€ СЉСpСthe Access Point of a DSA which has Administrative Authority for that Naming Context.ЦЦ а H аС СThis type of reference is optional and serves to optimize Name Resolution. A DSA may hold any number (including zero) of cross references. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС10.3.5С јСУУNonЉspecific subordinate referencesЦЦ аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СA nonЉspecific subordinate reference consists of: а Hx аТа ТТ№ ТС€ СЉСpСThe Access Point of a DSA which holds one or more immediately subordinate Naming Contexts.ЦЦ а H аС СThis type of reference is optional, to allow for the case in which a DSA is known to contain some subordinate entries but the specific RDNs of those entries is not known. С СFor each naming context which it holds, a DSA may hold any number (including zero) of nonЉ specific subordinate references, which will be evaluated if all specific internal and subordinate references have been pursued. DSAs accessed via a nonЉspecific reference must be able to resolve the request directly (either success or failure). In the event of failure a ServiceError reporting a problem of unableToProceed is returned to the requestor. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬа10.4Т№  ТУУKnowledge administrationЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СTo operate a widely distributed Directory with an acceptable degree of consistency and performance, procedures are required to maintain and extend the knowledge held by each DSA. The same procedures are appropriate for creating initial knowledge. С СKnowledge can be maintained by: а H аТа ТТ№ ТС€ Сa)СpСThe DSA or its administrative authority propagating changes of knowledge to those DSAs holding all kinds of references to it, whenever changes at that DSA cause the references to become invalid. This is the only way superior, subordinate and nonЉspecific subordinate references can be maintained.ЦЦ а Hx аТа ТТ№ ТС€ Сb)СpСDSAs requesting and obtaining cross references to improve the performance through ordinary directory operations.ЦЦ а Hx аС СThis Recommendation does not define any procedures for propagating knowledge changes as described in a). Bilateral agreements must be established locally for this. аЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHјP Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаТа ТС€ HС10.4.1С јСУУRequesting cross referenceЦЦ а H ааЬџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџHpи P Ј XА`ИhР!(#џџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџЬаФФС СTo improve the performance of the Directory System, the local set of cross references can be expanded using ordinary Directory operations. If a DSA has a chained port it may request another DSA (which also must have a chained port) to return those knowledge references which contain information about the location of naming contexts related to the target object name of an ordinary Directory operation. а H аС СIf the У УreturnCrossReferenceФ Ф component of the У УChainingArgumentФ Ф is set to У УTRUEФ Ф, the У УcrossReferenceФ Ф component of the У УChainingResultФ Ф may be present, consisting of a sequence of cross reference items. С СIf a DSA is not able to chain a request to the next DSA a referral is returned to the originating DSA. If the У УreturnCrossReferenceФ Ф component of а H аthe chaining argument was У УTRUEФ Ф, the referral may contain additionally the context prefix of the naming context which the referral refers to. The У УcontextPrefixФ Ф component is absent if the referral is based on a nonЉspecific subordinate reference. The cross reference returned by a referral is only based on knowledge held by the DSA which generated the referral.