S|Qr F 9 !"#$%'&)+,-./*023415678:;<=>?@ABCDEGHIJKLMNOPRSTVUWXYZ\]^_`abcdefghijklmnoqstpuvw[yxz{(}~>^BLTT TTTATFT_TbRe^BLTT TTTTATFT_TbRe^BLTT TTTT$Re^BLTT TTTATFRP^BLT T TTTATFT_TbRe^BLTT TTTATFT_TbTeRi^BLTT TTTATFT_TbRe^BLTT TTTATFT_TbRe_cit|V-D   . ld q)69cAJmSn[R_cit|V- ,D   . A '#Fascicle VIII.8 - Rec. X.500 @oQTHE DIRECTORY - OVERVIEW OF CONCEPTS, MODELS AND SERVICES)L@!`G 33O ;(Melbourne, 1988);  K 7= '#Fascicle VIII.8 - Rec. X.500&] terminals and distribution lists.Ved w c2)The Directory plays a significant role in Open Systems Interconnection, whose aim is to cFsBy_with a minimum of technical agreement outside of the interconnection standards themselves, the _Gec3interconnection of information processing systems:3pr=as)-from different manufacturers;) < lustrated in [$ Figure^1/X.500.G These concepts are illus  . dwNotew - This series of Recommendations refers to the Directory in the singular, and reflects X~e needs change.f P XN :FIGURE 1/X.500:G 3 (-under different managements;( F 2-of different levels of complexity; and2 2-of different ages. u a0.3This Recommendation introduces and models the concepts of the Directory and of the DIB and ay eoverviews the services and capabilities which they provide. Other Recommendations make use of these ew cmodels in defining the abstract service provided by the Directory, and in specifying the protocols cN :through which this service can be obtained or propagated.:T Scope and field of application@@ y e1.1The Directory provides the directory capabilities required by OSI applications, OSI management ey eprocesses, other OSI layer entities, and telecommunication services. ong the capabilities which itew cprovides are those of "user-friendly naming" whereby objects can be referred to by names which are cy esuitable for citing by human users (though not all objects need have user-friendly names); and "name-ey eto-address mapping" which allows the binding between objects and their locations to be dynamic. The es _latter capability allows OSI networks, for example, to be "self-configuring" in the sense that _n Zaddition, removal and the changes of object location do not affect OSI network operation.Z uBya1.2The Directory is not intended to be a general-purpose data base system, although it may be aqRec]built on such systems. It is assumed, for instance, that, as is typical with communications ]ud yadirectories, there is a considerably higher frequency of "queries" than of updates. The rate of au praupdates is expected to be governed by the dynamics of people and organizations, rather than, for aubasaexample, the dynamics of networks. There is also no need for instantaneous global commitment of ay eupdates: transient conditions where both old and new versions of the same information are available, e* are quite acceptable. t `1.3It is a characteristic of the Directory that, except as a consequence of differing access `r^rights or unpropagated updates, the results of directory queries will not be dependent on the ^x didentity or location of the enquirer. This characteristic renders the Directory unsuitable for some dX Dtelecommunications applications, for example some types of routing.D +2References@@   b Y ERecommendation X.511 -The Directory - Abstract Service Definition.EbPNRecommendation X.518 -The Directory - Procedures for Distributed Operation.N UByARecommendation X.519 -The Directory - Protocol Specifications.AVprBRecommendation X.520 -The Directory - Selected Attribute Types.BU ARecommendation X.521 -The Directory - Selected Object Classes.A h TRecommendation X.219 -Remote Operations - Model, Notation and Service Definition.TX DRecommendation X.229 -Remote Operations - Protocol Specification.Dpecification.,UprARecommendation X.520 - The Directory - Selected* * Recommendation X.229 -_@ ,Remote Operations - Protocol Specification.,* Recommendation X.229 -)Operations - Protocol Specification.C {iW CRecommendation X.229 - Remote Operations - Protocol Specification.C  , 3Definitions@@  lXThe definitions contained in this  make use of the abbreviations defined in  4.XTD (3.1wOSI reference model definitionsw%! x dThis Recommendation is based on the concepts developed in Recommendation^X.200, and makes use d< (of the following terms therein defined:( = !a)wapplication-entityw; %! <  b)wApplication Layerw; %! >"c)wapplication processw; %!d I -d)wapplication protocol data unitw; %!ByFec*e)wapplication service elementw. %! y@pr$3.2wBasic directory definitionsw%!as  da)The wDirectoryw: a collection of open systems cooperating to provide directory services;% !J~ |  `b)wDirectory Information Base (DIB):w the set of information managed by the Directory; %!!2z  ^c)w(Directory) user:w the end user of the Directory, i.e. the entity or person which %!@7  #accesses the Directory.# @ $3.3wDirectory model definitionsw%!p \This Recommendation makes use of the following terms defined in Recommendation^X.501.\ U 9a)wAdministration Directory Management Domainw; %*! 0 b)waliasw; %! 4 c)wattributew; % ! 9 d)wattribute typew; %!: e)wattribute valuew; %! K /f)wDirectory Informa !r)wsubordinate objectw; %! 9 s)wsuperior entryw; %!:P t)wsuperior objectw; %!/ u)wtreew. %! F *3.4wDistributed operation definitionsw%!! p \This Recommendation makes use of the following terms defined in Recommendation X.518:\tion Tree (DIT)w; % ! L 0g)wDirectory Management Domain (DMD)w; %!! G +h)wDirectory System Agent (DSA)w; %! E)i)wDirectory User Agent (DUA)w; %! = !j)wdistinguished namew; %! 0 k)wentryw; %!/ l)wnamew; %! ? #m)wobject (of interest)w; %! N2n)wPrivate Directory Management Domainw; %#! FT*o)wrelative distinguished namew; %! / p)wrootw; %! 1 q)wschemaw; %! = 3a)wchainingw; %! 7 b)wmulticastingw; % ! 3 c)wreferralw. %! . 4Abbreviations@@   O ;ADDMDAdministration Directory Management Domain;6 = )DAPonnection- H 4PRDMDPrivate Directory Management Domain4 @ ,RDNRelative Distinguished Name,hent Domain3 ? +RDNRelative Distinguished Name+uished Name G 3PRDMDPrivate Directory Management Domain3  RDN l0 Relative Distinguished Name8    Directory Management Domain* L > *PRDMDPrivate Directory Management Domain*D Z lative Distinguished Name"  : 5Overview of the Directory@@   e5.1The wDirectoryw is a collection of open systems which cooperate to hold a logical data base of % !P} einformation about a set of objects in the real world. The wusersw of the Directory, including people :%!$}q ]and computer programs, can read or modify the information, or parts of it, subject to having ]w cpermission to do so. Each user is represented in accessing the Directory by a Directory User Agent co [(DUA), which is considered to be an application-process. These concepts are il estored in its local data base or interact with other DSAs to carry out requests. Alternatively, the ey eDSA may direct a requestor to another DSA which can help carry out the request. Local data bases aree7 #entirely implementation dependent.# 9 8.2wOrganizational modelw%!y Local data bases aree7 #entirely implementation dependent.#  P(to B)" will not occur. Similarly, if DSA C conveys the request PX Dto DSA B, it will not return a referral to the DUA.D SA^A and is responsible for either ?y ?C /to DSA B, it will not return a /T+request to DSA B, it will not return a ^$ x  to the DUA.% x N :3V >Access to the Directory&@  f Recommendations refers to the Directory in the singular, and reflects %!X~v bthe intention to create, through a single, unified, name space, one l9 dwNotew - This series of Recommendations refers to the Directory in the singular, and reflects %!X~v bthe y e5.3The Directory provides a well-defined set of access capabilities, known as the abstract serviceet `of the Directory, to its users. This service, which is overviewed in  7 of this Recommendation `q ]provides a simple modification and retrieval capability. This can be built on with local DUA ]U Afunctions to provide the capabilities required by the end-users.A v b5.4It is likely that the Directory will be distributed, perhaps widely distributed, both along by efunctional and organizational lines. ^8 overviews the corresponding models of the Directory. These ey ehave been developed in order to provide a framework for the cooperation of the various components to eous W1provide an integrated whole. x d5.5The provision and consumption of the Directory services requires that the users (actually the dx dDUAs) and the various functional components of the Directory should cooperate with one another. In dvbmany cases this will require cooperation between application processes in different open systems, bq ]which in turn requires standardized application protocols, overviewed in ^9, to govern this ]!  cooperation.  y e5.6The Directory has been designed so as to support multiple applications, drawn from a wide rangeew cof possibilities. The nature of the application supported will govern which objects are listed in cv bthe Directory, which users will access the information, and which kinds of access they will carry bx dout. Applications may be very specific, such as the provision of distribution lists for electronic dx dmail, or generic, such as the "inter-personal communications directory" application. The Directory d^ Jprovides the opportunity to exploit commonalities among the applications:J y  e-a single object may be relevant to more than one application; perhaps even the same piece eX  Dof information about the same object may be so relevant.D u aTo support this, a number of object classes and attribute types are defined, which will be at `useful across a range of applications. These definitions are contained in Recommendations X.520 `  and^X.521:  x  d-certain patterns of use of the Directory will be common across a range of applications: d  7this area is overviewed further in Annex^A.7 E +6The Directory Information Base (DK)@@$  l PwNotew - The DIB, and its structure, are defined in Recommendation^X.501.%!D e6.1The DIB is made up of information about objects. It is composed of w(directory) entriesw, each I%!}m Yof which consists of a collection of information on one object. Each entry is made up of Y ewattributesw, each with a type and one or more values. The types of attribute which are present in a % !YoTSparticular entry are dependent on the wclassw of object which the entry describes.&%!& y e6.2The entries of the DIB are arranged in the form of a tree, the Directory Information Tree (DIT)ev bwhere the vertices represent the entries. Entries higher in the tree (nearer the root) will often bx drepresent objects such as countries or organizations while entries lower in the tree will represent d5 !people or application processes.!  cwNotew - The services defined in this Recommendation operate only on a tree-structured DIT. %!Ww cThis Recommendation does not preclude the existence in the future of other structures (as the need c  arises).   e6.3Every entry has a wdistinguished namew, which u!u awrong types of attributes for its object class, attribute values being of the wrong form for the ad Pattribute type, and even entries having subordinate entries of the wrong class.PgPTS6.6Figure 2/X.500 illustrates the above concepts of the DIT and its components.S   0 N :FIGURE 2/X.500:G3 of the tree are alias entries, while all other entries are cw cobject entries. Alias entries point to object entries, and provide the basis for alternative names c3 for the corresponding objects.y e6.5The Directory enforces a set of rules to ensure that the DIB remains well-formed in the face ofe~ bmodifications over time. These rules, known as the wDirectory schemaw, prevent entries having the 3%ronic mail, the entry will have someev badditional information such as the types of information which the user's equipment can handle. If br's equipment can Wm Yauthentication is to be supported, then User Password and/or Credentials will be needed.YwP cThe naming schemes used for the various object classes should be user-friendly, with aliases cv bbeing set up as appropriate to provide alternative names, provide co3\ DStructure of the DIT and of entries @#   . Figure 3/X.500 gives a ye6.7Figure 3/X.500 gives a hypothetical example of a DIT. The tree provides examples of some of theeb Ntypes of attributes used to identify different objects. For example the name:N 7.1wIntroductionw% ! ye7.1.1This  provides an overview of the service provided to users, as represented by their DUAs, by ew cthe Directory. All services are provided by the Directory in response to requests from DUAs. There cr ^are requests which allow interrogation of the Directory, as described in  7.3, and those for ^y emodification, as described in  7.4. In addition, requests for  [ G{C = GB, L = Winslow, O = Graphic Services, CN = Laser Printer}G n Zidentifies the application entity "Laser Printer" which has in its distinguished name the Zl Xgeographical attribute of Locality. The residential person John Jones, whose name is GBX C /{C = GB, L = Winslow, CN = John Jones}/ S ?has the same geographical attribute in his distinguished name.? P R N :FIGURE 3/X.500:G 33_ GA Hypothetical directory information tree@)   T  } :FIGURE 3/X.500:G 33_ GA Hypothetical Directory Information Tree@)h3[ GA Hypothetical Directory Information TreeG  w c6.8The growth and form of the DIT, the definition of the Directory schema, and the selection of cu adistinguished names for entries as they are added, is the responsibility of various authorities, ay ewhose hierarchical relationship is reflected in the shape of the tree. The authorities must ensure, ex dfor example, that all of the entries in their jurisdiction have unambiguous distinguished names, by dv bcarefully managing the attribute types and values which appear in those names. Responsibility is by epassed down the tree from superior to subordinate authorities, with control being exercised by means e# of the schema.6 7The Directory service@@  sWwNotew - The definition of the abstract service of the Directory can be found in %!K* Recommendation^X.511. 1service can be qualified, as describedewcin  7.2. The Directory always reports the outcome of each request that is made of it. The form of cx dthe normal outcome is specific to the request, and is evident from the description of the request. d request. cu aMost abnormal outcomes are common to several requests. The possibilities are described in ^7.5.a r ^7.1.2A number of aspects of the eventual a7.1.4A User and the Directory are bound together for a period of time at an access point to the ar ^Directory. At the time of binding, the User and the Directory optionally verify each other's ^ identity.  : 7.2wService qualificationw%! 5 7.2.1wService controlsw%! v bA number of controls can be appldirectory service are not presently provided by the ^q ]standards specified in this series of Recommendations. The corresponding capabilities will, ]u atherefore, need to be provided as a local function until such time as a standardized solution is a< (available. These capabilities include:( w  c-addition and deletion of arbitrary entries, thus allowing a distributed Directory to be c(  created; y  e-the management of access control (i.e. granting or withdrawing permission for a particularel  Xuser to carry out a particular access on a particular piece of information);XG  3-the management of the Directory schema;3 H  4-the management of knowledge information;4TD 0-the replication of parts of the DIB.0 T 8wNotew - This list is not necessarily exhaustive.%!, sP _7.1.3The Directory ensures that changes to the DIB, whether the result of a Directory service _vbrequest, or by some other (local) means, result in a DIB which continues to obey the rules of the b& Directory schema. uied to the various service requests, primarily to allow the bv buser to impose limits on the use of resources which the Directory must not surpass. Controls are by eprovided on, among other things: the amount of time, the size of the results, the scope of search theeK 7interaction modes, and on the priority of the request.7 8 7.2.2wSecurity parametersw%!y eEach request may be accompanied by information in support of security mechanisms for protectingeu athe Directory information. Such information may include the user's request for various kinds of ay eprotection; a digital signature of the request, together with information to assist the correct partye-Tto verify the signature. , 7.2.3wFiltersw%! yeA number of requests whose outcome involves information from or concerning a number of entries,ey emay carry with them a filter. A filter expresses one or more conditions that an entry must satisfy iney eorder to be returned as part of the outcome. This allows the set of entries returned to be reduced toe) only those relevant.<  7.3wDirectory interrogationw%! )  7.3.1wReadw%! u aA read request is aimed at a particular entry, and causes the values of some or all of the at `attributes of that entry to be returned. Where only some attributes are to be returned, the DUA `F 2supplies the list of attribute types of interest.2 , 7.3.2wComparew%! u aA compare requ ? +DITDirectory Information Tree+ @ ,DMDDirectory Management Domain, ; 'DSADirectory System Agent' > *DSPDirectory System Protocol* 9 %DUADirectory User Agent% A -OSIOpen Systems Intercest is aimed at a particular attribute of a particular entry, and causes the ac ODirectory to check whether a supplied value matches a value of that attribute.O  ewNotew - For example, this can be used to carry out password checking, where the password, held%!Y}bNin the Directory, might be inaccessible for read, but accessible for compare.N )T 7.3.3wListw%! p \A list request causes the Directory to return the list of immediate subordinates of a \7 #particular named entry in the DIT.# +7.3.4wSearchw%! w cA search request causes the Directory to return information from all of the entries within a ct `certain portion of the DIT which satisfy some filter. The information returned from each entry `[Gconsists of some or all of the attributes of that entry, as with read.G , 7.3.5wAbandonw%! x dAn abandon request, as applied to an outstanding interrogation request, informs the Directory dv bthat the originator of the request is no longer interested in the request being carried out. The bq ]Directory may, for example, cease processing the request, and may discard any results so far ]  achieved.  ;P 7.4wDirectory modificationw%! . 7.4.1wAdd entryw% ! yeAn add entry request causes a new leaf entry (either an object entry, or an alias entry) to be e& added to the DIT. } awNotew - In its present form this service is intended to be used to add entries which will %!Us _remain as leaves, such as entries for people or application entities, rather than to add whole _yTesubtrees by repeated applications of this service. It is envisaged that the service will be enhanced eE 1in the future to cater to the more general case.1 17.4.2wRemove entryw% ! a MA remove entry request causes a leaf entry to be removed from the DIT.M  cwNotew - As with add entry, this service is presently intended for operation on "true leaf" %!WVBentries, and will be enhanced in the future for the general case.B 1 7.4.3wModify entryw% ! w cA modify entry request causes the Directory to execute a sequence of changes to a particular cw centry. Either all of the changes are made, or none of them, and the DIB is always left in a state cu aconsistent with the schema. The changes allowed include the addition, removal, or replacement of a4  attributes or attribute values.  G +7.4.4wModify relative distinguished namew%"! y eA modify relative distinguished name (RDN) request causes the relative distinguished name of a ey eleaf entry (either an object entry or an alias entry) in the DIT to be modified by the nomination of e> *different distinguished attribute values.*3 7.5wOther outcomesw%! + 7.5.1wErrorsw%! v bAny service may fail, for example because of problems with the user supplied parameters, in by ewhich case an error is reported. Information is returned with the error, where possible, to assist inev bcorrecting the problem. However, in general, only the first error encountered by the Directory is bxdreported. Besides the above-mentioned example of problems with the parameters supplied by the user dy e(particularly invalid names for entries or invalid attribute types), errors may arise from violationseL 8of security policy, schema rules, and service controls.8. 7.5.2wReferralsw% ! v bA service may fail because the particular access point to which the DUA is bound is not the bx dmost suitable for carrying out the request, e.g. because the information affected by the request is dy e(logically) far away from the access point. In this case the Directory may return a referral, which e` Lsuggests an alternative access point at which the DUA can make its request.L  ewNotew - The Directory and the DUA may each have a preference as to whether referrals are used,%!Y} dor whether the requests are wchainedw (see  8.3.3.2). The DUA can express its preference by means %!?~n Zof service controls. The Directory makes the final decision as to which approach is used.Z  :  8The distributed Directory@@  dwNotew - the models of the directory are defined in Recommendation X.501 while the procedures %!X~jVfor the operation of the distributed Directory are specified in Recommendation^X.518.V 5 8.1wFunctional modelw%!TNRecommendation X.200 -Open Systems Interconnection - Basic Reference Model.N y eRecommendation X.208 -Open Systems Interconnection - Specification of Abstract Syntax Notation One e5!(ASN.1).! D 0Recommendation X.501 -The Directory - Models.0 V BRecommendation X.509 -The Directory - Authentication framework.B \ HThe functional model of the Directory is shown in Figure^4/X.500.HRN :FIGURE 4/X.500:G 33[ CFunctional model of the Directory!@!  dA wDirectory System Agentw (DSA) is an OSI application process which is part of the Directory %!D~JDirectory C8ry %Zyeand whose role is to provide access to the DIB to DUAs and/or other DSAs. A DSA may use information ey es7 A wDirectory System Agent%W C(DSA) is an OSI application process which is part of the Directory Cyeand whose role is to provide access to the DIB to DUAs and/or other DSAs. A DSA may use information eyv b8.2.1A set of one or more DSAs and zero or more DUAs managed by a single organization may form a bv bDirectory Management Domain (DMD). The organization concerned may or may not elect to make use of bw cthis series of Recommendations to govern the communications among the functional components within c the DMD.  y e8.2.2Subsequent Recommendations specify certain aspects of the behaviour of DSAs. For this purpose,ex da group of DSAs within one DMD may, at the option of the organization which manages the DMD, behave d% as a single DSA. y e8.2.3A DMD may be an Administration DMD (ADDMD), or a Private DMD (PRDMD), depending on^whether e of the organization which manages the DMD, behave d% as a single DSA. u as] Ior not it is being operated by a public telecommunications organization.I`Z Fnot it is being operated by a public telecommunications organization.F ewNotew - It should be recognized that the provision of support for private directory systems by%!Y}x dCCITT members falls within the framework of national regulations. Thus, the technical possibilities dt `described may or may not be offered by an Administration which provides directory services. The `t `internal operation and configuration of private DMDs is not within the scope of envisaged CCITT `% Recommendations.; 8.3wOperation of the modelw%! y e8.3.1The DUA interacts with the Directory by communicating with one or more DSAs. A DUA need not beex dbound to any particular DSA. It may interact directly with various DSAs to make requests. For some dx dadministrative reasons, it may not always be possible to interact directly with the DSA which needs dy eto carry out the request, e.g. to return some directory information. It is also possible that the DUAey ecan access the Directory through a single DSA. For this purpose, DSAs will need to interact with eacheother. y e8.3.2The DSA is concerned with carrying out the requests of DUAs and with obtaining the information et `where it does not have the necessary information. It may take the responsibility to obtain the `UAinformation by interacting with other DSAs on behalf of the DUA.AiP U8.3.3A number of cases of request handling have been identified, as illustrated in U< (Figures^57/X.500, and described below.( y e8.3.3.1In Figure 5a/X.500, the DSA^C receives a referral from DSA^A and is responsible for eitherey econveying the request to the DSA^B (named in the referral from DSA^A) or conveying the referral back e, to the originating DUA.   l PwNotew - If DSA C returns the referral to the DUA, the "request %!:dFIGURE 5a/X.500: O 7Referrals-@   x dIn Figure 5b/X.500, the DUA receives the referral from DSA^C and is responsible for reissuing dVBthe request directly to DSA^A (named in the referral from DSA^C).B    @7 #7.3Directory interrogation#6}e)Recommendation X.500 and ISO 9594-1, The Directory - Overview of Concepts, Models and Services,a] Iwere developed in close collaboration and are technically aligned.I PfFascicle VIII.8 - Rec. X.500#@@|N :FIGURE 5b/X.500:G 33O7Referrals-@   y e8.3.3.2Figure 6/X.500 shows DSA chaining, whereby the request can be passed through several DSAs e5 !before the response is returned.! P  N :FIGURE 6/X.500:G 33O 7Chaining.@  x d8.3.3.3Figure 7/X.500 shows multicasting, where the DSA associated with the DUA carries out the dq ]request by forwarding it to two or more other DSAs, the request to each DSA being identical.]   N:FIGURE 7/X.500:G 33Q 9Multicasting,@   wc8.3.4All of the approaches have their merits. For example, the approach in Figure^5/X.500 may be ct R N :FIGURE 8/X.500: X @Mixed modes hybrid approach$@  4 9Directory protocols@@   dwNotew - The OSI application layer protocols defined to allow DUAs and DSAs in different open %!X~ `used where it is desirable to offload the burden from the local DSA. In other circumstances, a `s _hybrid approach that combines a more elaborate set of functional interactions may be needed to _W Csatisfy the initiator's request, as illustrated in Figure^8/X.500.C   N Q =satisfy the initiator's request, as illustrated in Figure^8.=bP H( P <systems to cooperate are specified in Recommendation^X.519.< 9Directory protocolsX n systems Xpplication layer protocols defined to allow DUAs and DSAs in different open systems dH 4to cooperate are specified in Recommendation^X.519.4 = )9.1There are two Directory protocols:) x  d-the Directory Access Protocol (DAP), which defines the exchange of requests and outcomes d8  $between a DUA and a DSA;$ x d-the Directory System Protocol (DSP), which defines the exchange of requests and outcomes d1  between two DSAs. y e9.2Each protocol is defined by an application context, each containing a set of protocol elements.et `For example, the DAP contains protocol elements associated with interrogating and modifying the `  Directory. y e9.3Each application context is made up of application service elements. These application serviceey eelements are defined to use the Remote Operations Service (ROS) of Recommendation^X.219 to structure ew cand support their interactions. Thus the DAP and DSP are defined as sets of remote operations and c3 errors using the ROS notation. J 6ANNEX A6G 33S ?(to Recommendation X.500)?G 33G 3c applicationsw%!  1 A.4.1wIntroductionw% ! y eThere are a number of generic applications which can be imagined as implicitly supported by theev bDirectory: applications which are not specific to any particular telecommunications service. Two bvbsuch applications are described herein: the inter-personal communications directory and the inter-3V >Applying the Directory'@   U AThis annex is not an integral part of this Recommendation.A  > "A.1wThe Directory environmentw%!  cwNotew - In this , the term "network" is used with its general meaning to denote the set of %!Wu ainterlinked systems and processes relevant to any telecommunications service, not only one which a6 "relates to the OSI network layer."fP RThe Directory exists in and provides services in the following environment:R v  ba)many telecommunications networks will be on a large scale, and will constantly undergo b'  change: y e1)objects of various kinds will enter and leave the network without warning and may do eC/so either singly or in groups;/ w c2)the connectivity of the objects (particularly network nodes) will change, owing to cS ?the addition or removal of paths between them;?Pso either singly or in groups;.  w c3)various characteristics of the objects, such as their addresses, availability, and cP <physical locations, may change at any time;< b3)various characteristics of the objects, such as their addresses, availability, and b?O ;physical locations, may change at any time;;@ y  eb)although the overall rate of changes is high, the useful lifetime of any particular objectey  eis not short. An object will typically be involved in communications much more frequently eg  Sthat it will change its address, availability, physical location, etc.;S w  cc)the objects involved in current telecommunications services are typically identified by cx  dnumbers or other strings of symbols, selected for their ease of allocation or processing dH 4but not for ease of use by human beings.4  F *A.2wDirectory service characteristicsw%!!   {  A )A.2wDirectory service characteristics%"W mK7The need for directory capabilities arises from:7 t  `a)the desire to isolate (as far as possible) the user of the network from the frequent `w  cchanges to it. This can be accomplished by placing a "level of indirection" between the cx  dusers and the objects with which they deal. This involves the users referring to objects ds  _by name, rather than by, for example, address. The Directory provides the necessary _0  mapping service;y  eb)the desire to provide a more "user-friendly" view of the network. For example, the use of ey  ealiases, the provision of "yellow-pages" (see A.3.5) etc., helps to relieve the burden of eF  2finding and using network information.2 x dThe Directory allows users to obtain a variety of information about the network, and provides dX Dfor the maintenance, distribution and security of that information.D  E )A.3wPatterns of use of the directoryw% !  } awNotew - This subclause is concerned only with Directory retrieval: it is assumed that the %!Uv bDirectory modification services are used solely to maintain the DIB in the form necessary for the b+ application over time. 1 A.3.1wIntroductionw% !y eThe Directory service is defined in these standards in terms of particular requests that a DUA ev bcan make and the parameters of them. An application designer is likely, however, to think in more by egoal-oriented terms when considering the information retrieval requirements of the Directory in that er^application. Accordingly, this clause describes a number of high-level patterns of use of the ^[ GDirectory service that are likely to be relevant to many applications.G , A.3.2wLook-upw%!< ' A.3.2wLook-up% p \The straight Directory look-up is likely to be the most frequent type of query of the \s _Directory. It involves the DUA supplying the distinguished name of an object, together with an _xdattribute type. The Directory will return any value(s) corresponding that attribute type. This is a dy egeneralization of the classic directory function, which is obtained when the attribute type requesteder ^corresponds to a particular type of address. Attribute types for various kinds of address are ^t `standardized, including OSI PSAP address, Message Handling O/R address, and telephone and telex `  numbers. nP ZLook-up is supported by the read service, which also provides the following further Z% generalizations: v  b-look-up can be based upon names other than the distinguished name of the object, e.g. bRhe object, e.g. a(  aliases;un a-look-up can be based upon names other than the distinguished name of the object, e.g. a(  aliases; w  c-the values from a number of attribute types can be requested with a single request: the cu  aextreme case being that the values of all attributes in the entry are to be returned.a 9A.3.3wUser-friendly namingw%! y eNames can be given to objects in such a way as to maximize the chances that these names can be ex dpredicted (or perhaps remembered) by human users. Names which have this property would typically be dy emade up of attributes which are somehow inherent to the object, rather than being fabricated for the es _purpose. The name of an object will be common among all of the applications which refer to it._ - A.3.4wBrowsingw%! x dIn many human-oriented uses of the Directory, it may not be possible for the user (or DUA) to dy edirectly quote a name, user-friendly or otherwise, for the object about which information is sought. ey eHowever, perhaps the user will "know it when he sees it". The browsing capability will allow a humaneVBuser to wander about the DIB looking for the appropriate entries.B p \Browsing is accomplished by combinations of the list and search services, possibly in \i Uconjunction with read (although the search service includes the capability of read).U 3 A.3.5w"Yellow Pages"w%! y eThere are a variety of ways to provide a "Yellow Pages" type capability. The simplest is basedex dupon filtering, using assertions about particular attributes whose values are the categories (e.g. d3tributes whose values are the categories (e.g. cu athe "Business Category" attribute type defined in Recommendation^X.520). This approach does not aq ]require any special information being set-up in the DIT, except to ensure that the requisite ]yeattributes are present. However, in the general case, it may be expensive to search where there is aes _large population because filtering requires the generation of the universal set which is to be _  filtered.  t `An alternative approach is possible, based upon the setting up of special subtrees, whose `jVnaming structures are designed especially for "Yellow Pages" type searching. Shown in Vs _Figure^A1/X.500 is an example of a "Yellow Pages" subtree populated by alias entries only. In _y ereality, the entries within the "Yellow Pages" subtrees may be a mixture of object and alias entries,ek Wso long as there exists only one object entry for each object stored in the Directory.W   O ;FIGURE A-1/X.500;G 33YT `used where it is desirable to offload the burden from the local DSA. y eMany applications require the objects taking part to offer some proof of their identify before ex dthey are permitted to carry out some action. The Directory provides support for this authentication dx dprocess. (As a separate matter, the Directory itself requires its users to authenticate themselves, d6 "so as tAAn approach to "Yellow Pages"#@+P A.3.6wGroupsw%! u aA group is a set whose membership can change over time by explicit addition and removal of am Ymembers. The group is an object, as are its members. The Directory can be requested to:Y c  O-indicate whether or not a particular object is a member of a group;O3.4Distributed operation definitions- 1 4wAbbreviationsw%! = !5wOverview of the directoryw%! H ,6wThe directory information base (DIB)w%(! 9 7wThe directory servicew%! , 7.1Introduction5 !7.2Service qualificationtribute type is defined in Recommendation^X.520). The two capabilities Ss ]N :be carried out by means of compare and read respectively.:pectively.MC s _A member of a group could itself be a group, if this is meaningful for the application. _y eHowever, the necessary recursive verification and expansion services would have to be created by the eD 0DUA out of the non-recursive versions provided.0 3 A.3.7wAuthenticationw%!ationy eMany applications require the objects taking part to offer some proof of their identify before ey ethey are permitted to carry out some action. The Directory provides support for this authentication ey eprocess. (As a separate matter, the Directory itself requires  . A.3.7wAuthentication%`o support access control)."x dThe more straightforward approach to authentication, called "simple authentication", is based dw cupon the Directory holding a "User Password" attribute in the entry for any user that wishes to be cy eable to authenticate itself to a Service. At the request of the Service, the Directory will confirm et `or deny that a particular value supplied is actually the user's password. This avoids the user `y eneeding a different password for every Service. In cases where the exchange of passwords in a local eq ]environment that uses simple authentication is considered to be inappropriate, the Directory ]y eoptionally provides means to protect those passwords against replay or misuse by a one way function.em YThe more complex approach, called "strong authentication" is based upon public key Yw ccryptography, where the Directory acts as a repository of users' public encryption keys, suitably cx dprotected against tampering. The steps that users can take to obtain each other's public keys from ds _the Directory, and then to authenticate with each other using them, are described in detail in _* Recommendation^X.509.  9 A.4wGeneri @alternatively be thought of as a generic Directory application.@P  A.4.2rsonal communications$B 6" alternatively hF2be thought of as a generic Directory application.2P = %A.4.2wInter-personal communications%t y eThe intent of this application is to provide humans or their agentb? +system communications directory (for OSI).+ | `wNotew - Authentication, described in the previous subclause as an "access pattern" could %!TT @alternatively be thought of as a generic Directory application.@ B &A.4.2wInter-personal communicationsw%!k y eThe intent of this application is to provide humans or their ages with information on how to eF 2communicate with other humans, or groups thereof.2 y eThe following classes of objects are certainly involved: person, organizational role and group.ey eMany other classes are involved too, perhaps in a less direct way, including: country, organization, e) organizational unit.w cThe attribute types concerned, other than those used in naming, are generally the addressing cy eattributes. Typically the entry for a particular person will have the addresses corresponding to eachew cof the communication methods by which that person can be reached, selected from an open-ended list cv bwhich includes at least the following: telephony, electronic mail, telex, ISDN, physical delivery by e(e.g. the postal system), facsimile. In some cases, such as elect  L تLRBntinuity after a name change, b etc.x dThe following access patterns will be manifested in this application: look-up, user-friendly dy enaming, browsing, "Yellow Pages", and groups. To varying degrees, authentication will also be used.e J .A.4.3wInter-system communications (for OSI)w%%!r ^According to the OSI Reference Model, two Directory functions are required in OSI, one, ^w coperating in the application layer, which maps application-titles onto presentation-addresses, and cy eone, in the network layer, which maps NSAP-addresses onto SNPA-addresses (SNPA = Subnetwork Point of e# Attachment).  w [wNotew - For the remainder of this , only the application layer case is dealt with.%!O r^This function is carried out by consulting the Directory if the information required to ^Y Eaccomplish the mapping is not conveniently available by other means.E i UThe users are application-entities and the object classes of interest are also UA-applicationentities, or subclasses thereof.-Dcation- 5 !entities, or subclasses thereof.! f RThe main attribute type concerned, other than those used for naming, is the Rt `presentationaddress. Other attribute types, not viewed as necessary for the directory function `p\itself, could support verifying or finding out the application entity type, or the lists of \x dapplication contexts, abstract syntaxes, etc. supported. The authentication-related attribute types d, could also be relevant.  relevant. Pported. The authentication-related attribute types could also be relevant.^Hd Psyntaxes, etc. supported. The authentication-related attribute types could alsoP!  be relevant.  T @The main access pattern to be manifested will be look-up.@ O #communications much more frequent d a| `whole, called the wDirectoryw. The information held by the Directory, collectively known as the % !Cu aDirectory Information Base (DIB), is typically used to facilitate communication between, with or aj Vabout objects such as application entities, people, terminals and distribution lists.Vd y e0.2The Directory plays a significant role in Open Systems Interconnection, whose aim is to allow, e?  +-list the membership of a group.+ u aGroups are supported by having the entry for the group contain a multiple valued "Member" aq ]attribute (such an attribute type is defined in Recommendation^X.520). The two capabilities ]a Mmentioned can then be carried out by means of compare and read respectively.M8ion^X.520). ' mentioned can then !7 #7.3Directory interrogation#6 "7.4Directory modification". 7.5Other outcomes = !8wThe distributed directoryw%! 0 8.1Functional model 4  8.2Organizational model  6 "8.3Operation of the model"  7 9wDirectory protocolsw%!  = #wAnnex Aw - Applying the directory%! 9 %A.1The directory environment%A -A.2Directory service characteristics-@ ,A.3Patterns of use of the directory,4T A.4Generic applications  T A.40wIntroductionw%! B &1wScope and field of applicationw%"! . 2wReferencesw%! /bas3wDefinitionsw%! pr?+3.1OSI reference model definitions+; '3.2Basic directory definitions'; '3.3Directory model definitions'A -d -P 0Introduction@@    This u a0.1This document, together with the others of the series, has been produced to facilitate the ay einterconnection of information processing systems to provide directory services. The set of all sucheu asystems, together with the directory information which they hold, can be viewed as an integrate?%1Scope and field of application@@  ubasaexample, the dynamics of networks. There is also no need for insta4?%1Scope and field of application@@J y e1.1The Directory provides the directory capabilities required by OSI applications, OSI management ey eprocesses, other OSI layer entities, and telecommunication services. Amniquely and unambiguously identifies the entry. %!9}x dThese properties of the distinguished name are derived from the tree structure of the information. ds _The distinguished name of an entry is made up of the distinguished name of its superior entry, _| `together with specially nominated attribute values (the wdistinguishedw values) from the entry.8% ! w c6.4Some of the entries at the leaves+ Recommendation X.500@     tRTHE DIRECTORY - OVERVIEW OF CONCEPTS, MODELS AND SERVICES^)@9@!`)0@!`M9THE DIRECTORY - OVERVIEW OF CONCEPTS, MODELS AND SERVICES@9tS 5)0@!`]    @!`)G 33X <w(Melbourne, 1988)w(%!    K 7CONTENTS7   0 > *DAPDirectory Access Protocol* ? +DIBDirectory Information Base+K / 8.2Organizational model v b8.2.1A set of one or more DSAs and zero or more DUAs managed by a single organizaN :ADDMDAdministration Directory Management Domain:= = )DAPK  7this area is overviewed further in Annex^A.7 .  9Directory protocolsX n w  c-certain patterns of use of the Directory will be common across a range of applications: cK  7this area is overviewed further in Annex^A.7 E +6The Directory Information Base (DIBintention to create, through a single, unified, name space, one logical directory composed of bw cmany systems and serving many applications. Whether or not these systems choose to interwork will cv bdepend on the needs of the applications they support. Applications dealing with non-intersecting bt `worlds of objects, may have no such need. The single name space facilitates later interworking `- should the needs change. Administration which provides directory services. The `t `internal operation and configuration of private DMDs is not within the scope of envisaged CCITT `% Recommenda  P e5.2The information held in the Directory is collectively known as the wDirectory Information BasewI%!T @(DIB). Clause 6 of this Recommendation overviews its structure.@