S% b  !"# $&'()*+,-./0214356789:;<>?@ABDEFGHIJKLMNOPQRCTUVXYZ[\]W^_`acdegfhijkSlmnoprsvqwxyz{|}~ YXWUR}|{zyxwvutsrqpHonmlkjihgGfedcbQa`_^P  >^BLTT TTTATKTZTbRe^BLTT TTTATKTZTbRe^BLTT TTTTATKTZTbRe ]DLTRe^BLTT TTTTATKTZTbRe^BLT T TTTATKTZTbTeRi^BLT T TTTATKTZTbTeRi SECTION 2 - wInformation modelw %! ? #6wDirectory information basew%! 6 7wDirectory entriesw%! * 8wNamesw%! 5 9wDirectory schemaw%! 9 SECTION 3 - wSecurity modelw %! - 10wSecur  fFascicle VIII.8 - Rec. X.501#@@|u ]Fascicle VIII.8 - Rec. X.501@@jB (#Fascicle VIII.8 - Rec. X.501 @$# @##@@    +Recommendation X.501@    a ?THE DIRECTORY-MODELS^)%@@!` X<w(Melbourne, 1988)w(%!@8))@1/V<p4R ='/:GNZfoz{   ccitt\ap-ix\doc\47e02.txss - PrintedE (1@)ROMAN,ccitt)ARABIC, (3@)MANUALOo/c CuevasXccitt\ap-ix\doc\47e01.txpages 24-47inted LYOPYTO SAVE ------ R@E@T@U@R@N@.  F2-of different levels of complexity; and22-of different ages. ye0.3This Recommendation provides a number of different models for the Directory as a framework for ey ethe other Recommendations. The models are the overall (functional) model; the organizational model; et `the security model; and the information framew ye0.2The Directory plays a significant role in Open Systems Interconnection, whose aim is to allow, es _with a minimum of technical agreement outside of the interconnection standards themselves, the _G 3interconnection of information processing systems:3= )-from different manufacturers;) < (-under different managements;(ork. The latter describes the manner in which the `s _Directory organizes the information it holds. It describes, for example, how information about _u aobjects is grouped to form directory entries for those objects and how that information provides a'names for objects.]DLk W0.4Annex A summarizes the mathematical terminology associated with tree structures.W$?J e objectsP' x d5.4.3The organization concerned may or may not elect to make use of this series of Recommendations dd Pto govern any interactions among DUAs and DSAs which are wholly within the DMD.Pua5.4.4Each DSA is administered by an Administrative Authority. This entity has control over all ayeobject entries and alias entries stored by that DSA. This includes responsibilities for the Directo C /Recommendation X.509 - The Directory - Authenti/ramework.A }ion Framework.Ad b NRecommendation X.511 - The Directory - Access and System Services Definition.N a MRecommendation X.518 - The Directory - Procedures for Distributed Operation.M fRRecommendation X.519 - The Directory - Access and System Protocolt classes be derived from "Alias" without assigning an object identifier. @*dddtd`9.4.6The following ASN.1 macro may (but need not) be used to define an object class. The empty `Ud=production for SubclassOf is permitted only in defining Top:@ #d5dOBJECT-CLASS MACRO ::=@$d BEGIN@A  ye1.1The models defined in this Recommendation provide a conceptual and terminological framework fore]DLIthe other Recommendations which define various aspects of the Directory.I y e1.2The functional and organizational models define ways in which the Directory can be distributed,e< (both functionally and administratively.(r^1.3The security model defines the framework within which security features, such as access ^<(control, are provided in the Directory.(v b1.4The information model describes the logical structure of the DIB. From this viewpoint, the bp \fact that the Directory is distributed, rather than centralized, is not visible. The other \x dRecommendations in the series make use of the concepts of the information framework. Specifically:d x  da)the service provided by the Directory is described (in Recommendation^X.511) in terms of dy  ethe concepts of the information framework: this allows the service provided to be somewhateT  @independent of the physical distribution of the DIB;@ y eb)the distributed operation of the Directory is specified (in Recommendation^X.518) so as toev bprovide that service, and therefore maintain that logical information structure, given bK  7that the DIB is in fact highly distributed.7+ 2References@@   a MRecommendation X.200 - Open Systems Interconnection - Basic Reference Model.MDLfs Specification.R UDLARecommendation X.520 - The Directory - Selected Attribute Types.A T@Recommendation X.521 - The Directory - Selected Object Classes.@  , 3Definitions@@   x dDefinitions of terms are included at the beginning of individual clauses, as appropriate. An dTGVB* TYPENOTATION <(::= AttributeSyntax Multivalued | emptymQ =VALUENOTATION ::= value (VALUE OBJECT IDENTIFIER)= 1 AttributeSyntax ::=I]DL5"WITH ATTRIBUTE-SYNTAX" Syntax Choice5E1Multivalued ::= "SINGLE VALUE"1M9+DITDirectory Information Tree+ @,DMDDirectory Management Domain, ; 'DSADirectory System Agent' 9 %DUADirectory User Agent%P HP 4PRDMDPrivate Directory Management Domain4 A -RDNRelative distinguished name.-shed n 4PRDMDPrivate Directory Management Domain4  RDN 1Relative distinguished name.\ : SECTION 1 - wDirectory modelw %!   0 5Directory model@@ 0 5.1wDefinitionsw% ! kfering public telecommunications services;K   cc)wAdministrative Authority:w An entity which has administrative control over all entries %!=N  :stored within a single Directory System Agent;:   cd)wThe Directory:w A repository of information about objects and which provides directory %!H\  Hservices to its users which allow access to the information;H ~ Tbe)wDirectory Management Domain (DMD):w A collection of one or more DSAs and zero or more %"!3O  ;DUAs which is managed by a single organization;;w [f)wDirectory System Agent (DSA):w An OSI application process which is part of the %!1*  Directory;z  ^g)w(Directory) user:w The end user of the Directory, i.e. the entity or person which %!@7  #accesses the Directory;# {  _h)wDirectory User Agent (DUA):w An OSI application process which represents a user in %!78  $accessing the Directory;${  _wNotew - DUAs may also provide a range of local facilities to assist users, compose %!ND  0queries and interpret the responses;0qq  UwNotew - DUAs may also provide a range of local facilities to assist users %!D8  queries `   rpret the responses;(   di)wPrivate Directory Management Domain (PRDMD):w A DMD which is managed by an organization %,!+~= )other than an Administration.) @$5.2wThe Directory and its usersw%! s _5.2.1A directory user (e.g. a person or an application process) obtains directory services by _ `accessing the wDirectoryw. More precisely, it is a wDirectory User Agentw (DUA), which actually % !%!zw caccesses the Directory and interacts with it to obtain the service on behalf of a particular user. cte 3w - A DUA will likely exhibit local behaviour and structure which is outside the scope %!V~yeof envisaged Recommendations. For example, a DUA which represents a human directory user may provide es _a range of local facilities to assist its user to compose queries and interpret the responses._ 5 5.3wFunctional modelw%! | d5.3.1The Directory is manifested as a set odinformation is collectively known as the wDirectory Information Base (DIB)w. A model for the DIB is )% !~A-defined in section^2 of this Recommendation.- u]DLa5.2.4A DUA is manifested as an application-process. Each DUA represents precisely one directory aTuser. ewNote 1w - Some open systems may provide a centralised DUA function retrieving information for %!W}s _the actual users (application-processes, persons, etc.). This is transparent to the Directory._  ewNote 2w - The DUA functions and a DSA (see  5.3.1) can be within the same open system, and it%!W}w cis an implementation choice whether to make one or more DUAs visible within the OSI environment as c* application-entities.  dwNo3V >Access to the Directory&@(P  tP `5.2.3The Directory is a repository of information about objects, and the directory services it `o [provides to its users are concerned with various kinds of access to this information. The [ictory@  a M5.2.3The Directory isf one or more application-processes known as wDirectory Y% w _System Agents (DSAs)w, each of which provides zero, one or more of the access points. This is !Jyeillustrated in Figure^2/X.501. Where the Directory is composed of more than one DSA, it is said to beeewdistributedw. The procedures for the operation of the Directory when it is distributed are specified% !X-in Recommendation^X.518.  wNotew - A DSA will likely exhibit local behaviour and structure which is outside the scope of %!Y}v benvisaged Recommendations. For examplB ewNotew - A DSA will likely exhibit local behaviour and structure which is outside the scope of %!Y}v benvisaged Recommendations. For example, a DSA which is responsible for holding some or all of the by einformation in the DIB will normally do so by means of a database, the interface to which is a local ematter.y e5.3.2A particular pair of application-processes which need to interact in the provision of directoryeu aservices (either a DUA and a DSA, or two DSAs) may be located in different open systems. Such an ad Pinteraction is carried out by means of OSI directory protocols, as specified in P*Recommendation^X.519.Es, as specified in P* Recommendation^X.519. T]LN :FIGURE 2/X.501:G 33^ FThe Directory provided by multiple DSAs@'95.4wOrganizational modelw%! v b5.4.1A set of one or more DSAs and zero or more DUAs managed by a single organization may form a b? %wDirectory Management Domain (DMD)w.%!!P xP \wNotew - The organization which manages a DMD may be an Administration (i.e. a public %!Py etelecommunications administration or other organization offering public telecommunications services) euTain which case the DMD is said to be an Administration DMD (ADDMD); otherwise it is a Private DMD ay e(PRDMD). It should be recognized that the provision of support for private directory systems by CCITTer ^members falls within the framework of national regulations. Thus, the technical possibilities ^t`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. r ^5.4.2Management of a DUA by a DMD implies an ongoing responsibility for service to that DUA, ^N:e.g.^maintenance, or in some cases ownership, by the DMD.: xr ^5.4.2Management of a DUA by a DMD implies an ongoing responsibility for service to that DUA, ^e.g. Rryeu aschema being used to guide the creation and modification of entries (see ^9). The structure and aw callocation of names is the responsibility of a naming authority [see  8.1^f)] and the role of the cd PAdministrative Authority is to implement these naming structures in the schema.PT X@ T0]DL DER \ H4XeM"*7BlMS|_kr}* 8wNamesw%! 5 9 4XeM"*7BlMS|_kr}w% ! ~  ba)walias entry:w an entry of the class "alias" containing information used to provide an % !I?  +alternative name for an object;+  eb)wDirectory Information Base (DIB):w the complete set of information to which the Directory %!!7}x  dprovides access and which includes all of the pieces of information which can be read or dR  >manipulated using the operations of the Directory;>   cc)wDirectory Information Tree (DIT):w the DIB considered as a tree, whose vertices (other %!!5I  5than the root) are the Directory entries;5   ewNotew - The term DIT is used instead of DIB only in contexts where the tree structure of %!T}%(DIT):w the DIB considered as a tre<  (the information is relevant.(z ^d)w(Directory) entry:w a part of the DIB which contains information about an object; %!?   ce)wimmediate superiorw (noun): relative to a particular entry or object (it must be clear %!DPd)w(Directory) entry:w a part of the DIB which contains information%!-# om  Yfrom the context which is intended) the immediately superior entry or object;Y>"f)wimmediately superiorw %!   ew(entry):w relative to a particular entry - an entry which is at the initial vertex of an %!P}b  Narc in the DIT whose final vertex is that of the particular entry;N2 Pw(entry):w relative to a par  T_w(object):w relative to a particular object - an object whose wobjectw entry is the % !3%!{{ DL_immediate superior of wanyw of the entries (object or alias) for the second object;!%!9p  Tg)wobject (of interest):w anything in some "world", generally the world of %!2V%%!htries %!$%!# y etelecommunications and information processing or some part thereof, which is identifiable en  Z(can be named), and which it is of interest to hold information on in the DIB;Z|  `h)wobject class:w an identified family of objects (or conceivable objects) which share % !F8  $certain characteristics;$   di)wobject entry:w an entry which is the primary collection of information in the DIB about % !J~n  Zan object and which can therefore be said to represent that object in the DIB;Z} aj)wsubclass:w relative to a superclass - an object class derived from a superclass. The % !Kr ^members of the subclass share all the characteristics of another object class (the ^y  esuperclass) and additional characteristics possessed by none of the members of that objecte7  #class (the superclass);#P YP =k)wsubordinate/inferior:w the converse of superior; %! dl)wsuperclass:w relative to a subclass - an object class from which a subclass is derived; % !L~] #class (the superclass);#s);3 Y   dm)wsuperior:w (applying to entry or object) immediately superior, or superior to one which % !N~F  2is immediately superior (recursively).2T,]DL6.2wObjectsw%! | d6.2.1The purpose of the Directory is to hold, and provide access to, information about wobjects of X% z binterest (objects)w which exist in some "world". An object can be anything in that world which is !O1 identifiable (can be named).  cwNote 1w - The "world" is generally that of telecommunications and information processing or %!U' some part thereof. ewNote 2w - The objects known to the Directory may not correspond exactly with the set of "real"%!W}v bthings in the world. For example, a real-world person may be regarded as two different objects, a bw cbusiness person and a residential person, as far as the Directory is concerned. The mapping is not cw cdefined in this Recommendation but is a matter for the users and providers of the Directory in the c3 context of their applications.='pplications.Pq]6.2.2The complete set of insed of wDirectory entries (entries)w each containing information about %!#2 (describing) a single object. z ^6.3.2For any particular object there is precisely one wobject entryw, this being the primary 7% !vbcollection of information in the DIB about that object. The object entry is said to represent the b object. z b6.3.3For any particular objectelongs to at least one class. An object class may be a ^ewsubclassw of another object class, in which case the members of the former class (the subclass) are %![y]DLealso considered to be members of the latter (the superclass). There may be subclasses of subclasses, e0 etc. to an arbitrary depth. 6 6.3wDirectory entriesw%!Ty]DL]6.3.1The DIB is compois associated. In the case of an object entry, this indicates the class(es) to dyewhich the object belongs. In the case of an alias entry, this indicates, by means of a special objectew cclass, "alias" (defined in ^9.4.8.2), that it is in fact an alias entry, and may also indicate to c alias entry, this indicates, by means of a special `Kk Wclass, "alias" (defined in ^9.4.8.2), that it is in fact an alias entry, and may also WW^ there may, in addition to the object entry, be one or more walias [%j Rentriesw for that object which are used to provide alternative names (see  8.5).!J q ]6.3.4The structure of directory entries is depicted in Figure^3/X.501 and described in 7.2.] ye6.3.5Each entry contains an indication of the object class and the superclasses of that object classex dwith which the entry T@which subclass(es) of the alias object class the entry belongs.@gs.L I-6.4wThe Directory information tree (DIT)w%$!ye6.4.1In order to satisfy the requirements for the distribution and management of a potentially very ey elarge DIB, and to ensure that objects can be unambiguously named (see  8) and their entries found, aew cflat structure of entries is not likely to be feasible. Accordingly, the hierarchical relationship cy ecommonly found among objects (e.g. a person works for a department, which belongs to an organization,eyTewhich is headquartered in a country) can be exploited, by the arrangement of the entries into a tree,eMDL1known as the wDirectory Information Tree (DIT)w. % !~ bwNotew - An introduction to the concepts and terminology of tree structures can be found in %!V Annex^A. P ]P I6.4.2The component parts of the DIT have the following interpretations:I u  aa)the vertices are the entries. Object entries may be either leaf or non-leaf vertices, ay  ewhereas alias entries are always leaf vertices. The root is not an entry as such, but can,ey  ewhen convenient to do so (e.g. in the definitions of b) and c) below), can be viewed as a eA  -null object entry [see d) below];-see d) below);  `when convenient to do so (e.g. in the definitions of b) and c) bel1  null object entry T# see d) below);- y  eb)the arcs define the relationship between vertices (and hence entries). An arc from vertex ey aA to vertex^B means that the entry at A is the wimmediately superior entry (immediate :%&|  `superior)w of the entry at B, and conversely, that the entry at B is an wimmediately !>% { _subordinate entry (immediate subordinate)w of the entry at A. The wsuperior entries 4!%}  e(superiors)w of a particular entry are its immediate superior together with its superiors !N}  a(recursively). The wsubordinate entries (subordinates)w of a particular entry are its %"!f  Rimmediate subordinates together with their subordinates (recursively);Rx dc)the object represented by an entry is or is closely associated with the naming authority d?  +(see ^8) for its subordinates;+ f  Rd)the root reiately subordinate object, immediate subordinate, superiorw and wsubordinatew%?!% !wH 4(applied to objects) have their analogous meanings.4 w c6.4.4Permitted superior/subordinate relationships among objects are governed by the DIT structure c- definitions (see ^9.2).  2 7Directory entries@@  | 2 7Directory entries@@ q 0 7.1wDefinitionsw% %  ea)wattribute:w the information of a particular type concerning an object and appearing in an % !N}H  4entry describing that object in the DIB;4$a)wattribute:w the informatio objectP The Diate superior of any of the entries for the second object. The L^Jterms immediately subordinate object, immediate subordinate, superior and J-T @subordinate (applied to objects) have their analogous meanings.@ d P6.4.4Permitted superior/subordinate relationships among objects are governedP@ ,by the DIT structure definitions (see 9.2).,   eb)wattribute type:w that component of an attribute which indicates the class of information %!I}8  $given by that attribute;$ |  `c)wattribute value:w a particular instance of the class of information indicated by an %!C/ attribute type;z ^d)wattribute value assertion:w a proposition, which may be true, false or undefined, %!7m DLYconcerning the values (or perhaps only the distinguished values) of an entry;Y   ewNotew - In this document the notation "string1 = string2" is used to write down examples %!T}u  aof attribute value assertions. In this notation, "string1" is an abbreviation for the ay  e"name" of the attribute type, and "striy  eName"), this is not strictly necessary for the purposes of this document, as the Directoryea Mis usually unaware of the meanings of the attribute types in use.M   ee)wdistinguished value:w an attribute value in an entry which has been designated to appear %!D}P  <in the relative distinguished name of the entry.< 6 7.2wOverall structurew%! m Q7.2.1As depicted in Figure 3/X.501, an entry consists of a set of wattributesw.C% !P N :FIGURE 3/X.501:G 33U =Structure of an entry'@ Tye7.2.2Each attribute provides a piece of information about, or describes a particular characteristic eC /of, the object to which the entry corresponds./ dwNotew - Examples of attributes which might be present in an entry include naming information %!X~r^such as the object's personal name, and addressing information, such as its telephone number.^ ! d8.2.1A w(directory) namew is a construct that identifies a particular object from among the set of %!J~y eall objects. A name must be unambiguous, that is, denote just one object. However, a name need not bee\ Hunique, that is be the only name that unambiguously denotes the object.H xd8.2.2Syntactically, each name for an object is an ordered sequence of relative distingd7.2.3An attribute consists of an wattribute typew, which identifies the class of information given "%!2~Tcby an attribute, and the corresponding wattribute value(s)w, which are the particular instances of '%!(7#that class appearing in the entry.# , Attribute ::=@ - SEQUENCE{ @ H ,typeAttribute Type@ @OT3valuesSET OF AttributeValue@@XDL8-- wat least one value is requiredw --}@%@!@ t 7.3wAU]DL7-- wat least one value is requiredw --}@%@!@tDL 47.3wAttribute typesw%!s_7.3.1Some attribute types will be internationally standardized. Other attribute types will be _y edefined by national administrative authorities and private organizations. This implies that a number ew cof separate authorities will be responsible for assigning types in a way that ensures that each is cy edistinct from all other assigned types. This is accomplished by identifying each attribute type with e[ Gan object identifier when the type is defined (as described in ^9.5):G9.5):r assigned types. This is accomplished by identifying each HP <an object identifier when the type is defined (as described . shown to be a valid name. A %8.3wRelative distinguished namesw%! {_8.3.1Each entry has a unique wrelative distinguished name (RDN)w. An RDN consists of a set of %!!y eattribute value assertions, each of which is true, concerning the distinguished values of the entry.e]has a unique wrelative distinguished name (RDN)w. An RDN !%!! <G 3att `c) the semantics of its internal structure (a sequence of RDNs) need not (but of course may) be ` a)^it is unambiguous, b) it is Zbl Xc) the semantics of its internal structure (a sequence of RDNs) need not (but of course Xjrse d= )understood by the user of the Directory.)1 ewNote 3w - Because only the object entry and its superiors are involved, distinguished names of%!W}e value assertions, each of which is true, 3ich is true, HF 2concerning the distinguished values of the entry.2p < $RelativeDistinguishedName ::=@BT*SET OF AttributeValueAssertion @nZThe set contains exactly one assertion about each distinguished value in the entry.Z - eAssertion @e values. l PwNotew - Frequently, an entry will contain a single distinguished value %!Ajyecomprise a single AVA); however, under certain circumstances (in order to differentiate), additional e9%values (and hence AVAs) may be used.% s _8.3.3The RDN for an entry is chosen when the entry is created. A single value instance of any _s _attribute type may form part of the RDN, depending on the nature of the object class denoted. _t `Allocation of RDNs is considered an administrative undertaking that may or may not require some `xdnegotiation between involved organizations or administrations. This Recommendation does not provide dt`such a negotiation mechanism and makes no assumption as to how it is performed. The RDN may be `7een PdPinvolved organizations orC /modified if necessary by complete replacement./  cwNotew - RDNs are intended to be long-lived so that the users of the Directory can store the %!Wm Ydistinguished names of objects (e.g. in the Directory itself) without concerns for their YJ 6obsolescence. Thus RDNs should be changed cautiously.68 8.4wDistinguished namesw%! e8.4.1The wdistinguished namew of a given object is defined as being the sequence of the RDNs of the %!G}v bentry which represents the object and those of all of its superior entries (in descending order). bx dBecause of the one to one correspondence between objects and object entries, the distinguished name dVBof an object can be considered to also identify the object entry.B dwNote 1w - It is preferable that the distinguished names of objects which humans have to deal %!V~+ with be user-friendly.PTP ewNote 2w - ISO 7498/3 defines the concept of a primitive name. A distinguished name can be used%!W}yeas a primitive name for the object it identifies because: a)^it is unambiguous, b) it is unique, and e>wNote 2w - ISO 7498/3 defines the concept of a primitive= )objects can never involve alias entries.) u a8.4.2It proves convenient to define the "distinguished name" of the root and of an alias entry, avbalthough in neither case is the name also the distinguished name of an object. The distinguished buaname of the root is defined to be the null sequence. The distinguished name of an alias entry is awcdefined to be the sequence of RDNs of the alias entry and those of all of its superior entries (in c' descending order). m Y8.4.3An example which illustrates the concepts of RDN and distinguished name appears in Y$ Figure^4/X.501. 9 #  N  N:FIGURE 4/X.501:G33]EDetermination of distinguished names @$  0 8.5wAlias namesw% !  d8.5.1An waliasw, or an walias namew, for an object is a name at least one of whose RDNs is that of %!% !@vuaan alias entry. Aliases permit object entries to achieve the effect of having multiple immediate aY Esuperiors. Therefore, aliases provide a basis for alternative names.E s _8.5.2Just as the distinguished name of an object expresses its principal relationship to some _w chierarchy of objects, so an alias expresses (in the general case) an alternative relationship to a c4 different hierarchy of objects. x d8.5.3An object with an entry in the DIT RRecommendation X.500 - The Directory - Overview of Concepts, Models and Services.R U ARecommendation X.509 - The Directory - Authentication Framework.A3del.MDLfRRecommendation X.500 - The Directory - Overview of Concepts, Models and Services.R C /Recommendation X.509 - The Directory - Authenti/& cation Framework.ation X.500 - The Directory -may have zero or more aliases. It, therefore, follows that du aseveral alias entries may point to the same object entry. An alias entry may point to an object ay]DLeentry that is not a leaf entry. Only object entries may have aliases. Thus aliases of aliases are noteobject aw]DLcentry that is not a leaf entry. Only object entries may have aliases. Thus aliases of aliases are cx<he same object K5]DL!entry that is not a entry. !T permitted.  n Z8.5.4An alias entry shall have no subordinates, that is, an alias entry is a leaf entry.Z y e8.5.5The Directory makes use of the aliased object name attribute in an alias entry to identify and e< (to find the corresponding object entry.(1P 9Directory schema@@  09.1wDefinitionsw% !}  aa)wDirectory Schema:w The set of rules and constraints concerning DIT structure, object %!Ck  Wclass definitions, attribute types and syntaxes which characterize the DIB;W   eb)wDIT Structure Rule:w A rule, forming part of the Directory Schema which relates an object %!E}x dclainate) as  _entry's RDN, and may impose additional conditions. The schema may contain many such _&  rules.-9.2wOvervieww%! w c9.2.1The Directory Schema is a set of definitions and constraints concerning the structure of the cw cDIT and the possible ways entries are named, the information that can be held in an entry, and the css (the subordinate) to another object class (the superior) and which allows an entry dy eof the former class to be immediately subordinate to one of the latter classes in the DIT.e in the DIT.   k Wof the former class to be immediately subordinate to one of the latter classWk!   in the DIT. Fu  aThe rule also governs the attribute type(s) permitted to appear in the (subordC]DL/attributes used to represent that information./ed, the 1e named, the F1]DLattributes used to represent .try, and the attributes used to represent O&Tthat information.Lf JwNote 1w - The schema enables the directory system to, for example:%!<| wNote 1 %P < - The schema enables the directory system to, for example:< y e-prevent the creation of subordinate entries of the wrong object-class (e.g. a country as ae9  %subordinate of a person);% u  a-prevent the addition of attribute-types to an entry inappropriate to the object-class aO-prevent the creation of subordinate entries of the wrong object-O9  %subordinate of a person);%aK  7(e.g. a serial number to a person's entry);7 x d-prevent the addition of an attribute value of a syntax not matching that defined for the dY Eattribute type (e.g. a printable string to a bit string).E } awNote 2w - Dynamic mechanisms for the management of the directory schema are not presently %!S@ ,provided by this series of Recommendations., M 99.2.2Formally, the Directory Schema comprises a set of:9  da)wDIT Structurew definitions (rules) that define the distinguished names that entries may % !J~n  Zhave and the ways in which they may be related to one another through the DIT;Z   db)wObject Classw definitions that define the set of mandatory andg Sknown, its syntax, and whether it is permitted to have multiple values;S  cd)wAttribute Syntaxw definitions that define for each attribute the underlying ASN.1 data %!F8  $type and matching rules.$ y eFigure 5/X.501 summarizes the relationships between the schema definitions on the one side, ande)%!/%8  $_ Kthe DIT, directory entries, attributes, and attribute values on the other.K r^9.2.3The Directory Schema is distributed, like the DIB itself. Each Administrative Authority ^yeestablishes the part of the schema that will apply for those portions of the DIB administered by the e  authority.  ~ bwNotew - Distribution of schema information across DSAs managed by different Administrative %!Vq ]Authorities is not supported by this series of Recommendations. Such distribution is handled ]> *administratively by bilateral agreements.* t`9.2.4The specification of what is involved in the definition of DIT structure, object classes, `g Sattribute types and attribute syntaxes can be found in ^9.3 - ^9.6 respectively.SP   ` N:FIGURE 5/X.501:G33YAOverview of directory schema$@  = !9.3wDIT structure definitionw%! y e9.3.1A DIT Structure Rule defines the permitted hierarchical relationships between entries and theireU Apermitted RDNs. The definition of a DIT Structure Rule involves:A involves:3zionships betwe  permitted G 3. The definition of a DIT Structure Rule involves:3qX  D-identifying the subordinate and superior object classes;Dw  c-identifying the attribute types which may be involved in subordinate entries' RDNs; andcure Rule permits subordinates or superiors belonging to a particular %!W}x dclass, it implicitly (unless explicitly overridden) also allows subordinates or superiors belonging dM 9to any object class derived from that class (see ^9.4).9  dinates or superiors belonging dM 9to any object class derived from that class (see ^9.4).9P ]x d9.3.3The Directory D 0-(optionally) additional information.0 y e9.3.2The Directory permits an entry to stand in the relationship of immediate subordinate to anotherev b(its immediate superior) only if there exists a DIT Structure definition, contained in the schema b additional information.0 \P H9.3.2The Directory permits an entry to stand in the relvpDL\(see ^9.2.3) applicable to the portion of the DIB that would contain the entry, for which:\M 9-the entry is of the subordinate object class;9d  P-the immediate superior of the entry is of the superior object class;P m  Y-the attribute type(s) forming the entry's RDN is (are) among those permitted;Yte superior of the entry i(e operations of d PFigure 5 summarizes the relationships between the schema definitions onPc Othe one side, and the DIT, directory entries, attributes, and attribute values O" on the other. dP9.2.3The Directory Schema is distributed, like the DIB itself, and may vary PbNbetween DSAs. Each Administrative Authority establishes the schema that will ory is concerned. The mapping is not defined in this Jc ORecommendation but is a matter for the users and providers of the Directory in O7#the context of their applications.# dP6.2.2The complete set of information to which the Directory provides access P\His known as the Directoa     and o [-any conditions imposed by the additional information set element are satisfied.[  ewNote 1w - Techniques for documenting DIT Structure or for representing structure rules in the %!W}V BDIB are not presently provided by this series of Recommendations.B  ewNote 2w - If a DIT Struct enforces the defined structure rules at every entry in the DIT. Any attempt to de Qmodify the DIT in such a way as to violate the applicable structure rules fails.Q e9.3.4A DIT Structure Rule in which an object class is the subordinate is termed a wname bindingw forS% !}' that object class. v]DLb9.3.5For an object class to be represented by entries in a portion of the DIB, at least one name buTabinding for that object class must be contained in the applicable part of the schema. The schema aC/contains additional name bindings as required./ ewNotew - It is conceivable that an object class, occurring in two distinct schemas, might have %!Y}; 'distinct name bindings in each schema.' <  9.4wObject class definitionw%! F 29.4.1The definition of an object-class involves:2 ` La)optionally, assigning an object-identifier for the object-class;LPUP Ab)indicating which classes this is to be a subclass of;A  ec)listing the wmandatoryw attribute types that an entry of the object class must contain in % !C}U b  Naddition to the mandatory attribute types of all its superclasses.N   cd)listing the woptionalw attribute types that an entry of the object class may contain in %!B\  Haddition to the optional attributes of all its superclasses.H  dwNotew - An object class without an assigned object identifier is intended for local use as a %!X~x dmeans of conveniently adding new attribute types to a pre-defined superclass. "This addition allows dwcfor a number of possibilities. For example, an Administrative Authority may define an unregistered cy eObject Class so as to permit a user to add any registered attribute to the entry. The Administrative ex dauthority may limit the attributes for an entry for a particular object class to those on a locally dx dhes to identify the object class and 5@ !wcsuperclasses to which the entry belongs. The definition of this attribute is given in ^9.5.4. The cyeattribute is multivalued. There shall be one value of the attribute for the object class and each of e|dits superclasses for which an object identifier is defined, except that the value of "Top" need not V@ G 3be present so long as some other value is present.3 }]wNote 1w - The requirement that the ObjectClass attribute be present in every entry is %!@ 'B &reflected in the definition of "Top".@@ 1w - The requirement that the ObjectClass attribute be present in every entry is %!@ '> &reflected in the definition of "Top".@Z  ewNote 2w - Because an object class is considered to belong to all its superclasses, each member%!W}x dof the chain of superclasses up to Top is represented by a value in the object class attribute (and dH4any value in the chain may be matched by a filter).4x `The ObjectClass attribute is managed by the Directory, i.e. it may not be modified by the @ Jany value in the chain may be G*te (and any value in the chain may be L*matched by a filter).j user. u a9.4.4The Directory enforces the defined object class for every entry in the DIB. Any attempt to ab Nmodify an entry that would violate the entry's object class definition fails.Nhe PP <modify an entry that would violate the entry's object class <bject class P&definition fails.e V :wNotew - In particular, the Directory will prevent:%!. w  ca)attribute types absent from the object class definition being added to an entry of that c-  object class;w  cb)an entry being created with one or more absent mandatory attribute types for the object c3 class of the entry; k ]DLWc)a mandatory attribute type for the object class of the entry being deleted.Wdde9.4.5The special object class Alias is defined in ^9.4.8.2. Every alias entry shall have an object @@=d)class which is a subclass of this class.)dyd]wNotew - The Directory's dereferencing of alias entries ensures that the values of the %!QxdbObjectClass attribute of an alias entry are rarely seen. It is recommended that G9w(Melbourne, 1988))%@   O 7CONTENTS.@G 33 g Q ; ((1 0wIntroductionw% !  _PK9.4.6The following ASN.1 macro may (but need not) be used to define an KdPobject class. The empty production for SublcassOf is permitted only in definingPTop:4  OBJECT-CLASS MACRO ::= # BEGIN < (TYPENOTATION ::=SubclassOf(E 1MandatoryAttributes1D0OptionalAttributes0 / VALUENOTATION ::=B .value(VALUE OBJECT IDENTIFIER). , SubclassOf ::=>*"SUBCLASS OF" Subclasses |*) empty C /Subclasses ::= subclass/subclass ","/9]DL% subclassses%BT.Subclass ::= value (OBJECT-CLASS).5!MandatoryAttributes ::=!F 2"MUST CONTAIN {"Attributes"}"|empty2 4  OptionalAttributes ::= F 2"MAY CONTAIN {"Attributes"}"|empty 2 Y EAttributes ::= AttributeTerm | AttributeTerm, AttributesEH 4AttributeTerm ::= Attribute | AttributeSet4@ ,Attribute ::= value(ATTRIBUTE), D 0AttributeSet ::= value(ATTRIBUTE-SET)0 !  END bNThe correspondence between the parts of the definition, as listed in NaM9.4.1, and the various pieces of the notation introduced by the macro, is as M  follows:  c Oa)the object identifier to the object class is the value supplied OI 5in the value assignment of the macro;5 dPb)the superclass of which this object class is a subclass are thoseP` Lidentified by the SubclassOf production, i.e. that following L2 "SUBCLASS OF"; `]DLLc)the mandatory attributes are those identified by the list of LZTFobject identifiers produced by the MandatoryAttributes FT@production, i.e. those following "MUST CONTAIN";@_ Kd)the optional attributes are those identified by the list of KZ Fobject identifiers produced by the Optional Attributes FS ?production, i.e. those following "MAY CONTAIN".? c ONote - The object identifiers in c) and d) identify both individual attributes Od Pand sets of attributes (see 9.4.8). The effective list in both cases is the setP_Kunion of these. If an attribute appears in both the mandatory set and the KD 0optional set, it shall be considered mandatory.0T @Note - The macro is used in defining selected object classes in @* Recommendation^X.521. ^ JShould all of the pieces of notation introduced by the macro and J` Ldescribed in b), c), and d) above be empty, the resulting notation ("OBJECT-LM9CLASS") can be used to denote any possible object class.9]I9.4.7An attribute set is a set of attributes identified by an object IN :identifier. The definition of an attribute set involves:: N :a)assigning an object identifier to the set;: ^ Jb)listing the object identifiers of the attributes and other JWCattribute sets whose members together form the set.C d PThe following ASN.1 macro may (but need not) be used to define a set ofPD 0attributes for use with the OBJECT CLASS macro:0]DL5T!ATTRIBUTE-SET-MACRO ::=!)BEGIN W CTYPE NOTATION ::= "CONTAINS"{"Attributes"}" | emptyC U AVALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER)A 2 Attributes ::=VBAttributeTerm | AttributeTerm "," AttributesB M9AttributeTerm ::= Attribute|AttributeSet9 G 3Attribute ::= value(ATTRIBUTE)3 K 7AttributeSet ::= value(ATTRIBUTE-SET)7 'ENDdPThe correspondence between the parts of the definition of an attribute PP <set and the notation introduced by the macro is as follows:< d Pa)the object identifier assigned to the attribute set is the value PR >supplied in the value assignment of the macro;> dPb)the set of attributes comprising the attribute set is that formedP] Iby the set union of the attributes and sets of attributes I[ Gidentified by the Attributes production, i.e. following G/ "CONTAINS".]DL]TIShould the "empty" alternative of the notation be selected, the I\Hresulting notation ("ATTRIBUTE-SET") can be used to denote any possible H# attribute set. _ K9.4.9The object classes previously mentioned are defined in 9.4.9.1-2.K ` JNote - These are partial definitions: the object identifiers are actually Fb Nallocated for these object classes in Recomm6"resulting notation ("ATTRIBUTE-SET"p  attribute ue object identifiers in this series of I%Recommendations. K79.4.8.1The object class "Top" is defined as follows:7 % Top ::=0 OBJECT-CLASSD 0MUST CONTAIN {ObjectClass}0 M99.4.8.2The object class "Alias" is defined as follows:9'Alias ::=0 OBJECT-CLASS9 %SUBCLASS OF top%J 6MUST CONTAIN {aliasedObjectName}6 c ONote 1 - The object class "Alias" does not specify appropriate attribute types O[Gfor the RDN of an alias entry. Administrative Authorities may specify Gd Psubclasses of the class "Alias" which specify useful attribute types for RDNs ofP> *alias entries (see Recommendation^X.521).* []DLGNote 2 - Entries of a subclass of the class "Alias" are alias entries.GT7#9.5Attribute Type definition#K 79.5.1The definition of an attribute type involves:7 Y Ea)assigning an object identifier to the attribute type:E a Mb)indicating or defining the attribute syntax for the attribute M) type;d Pc)indicating whether an attribute of this type may have only one orPI5may have more than one value (recur).5 c O9.5.2The Directory ensures that the indicated attribute syntax is used for Oa Mevery attribute of this type. The Directory also ensures that attributes of Md Pthis type will have one and only one value in entries if attributes of this typeP8 $are defined to have only one value.$_K9.5.3The following ASN.1 macro may (but need not) be used to define an K$attribute type: 6 "ATTRIBUTE MACRO ::="# BEGIN Z FTYPENOTATION ::= AttributeSyntax Multivalued | emptyFV BVALUENOTATION ::= value (VALUE OBJECT IDENTIFIER)B 6 "AttributeSyntax ::="::="WITH ATTRIBUTE-SYNTAX" Syntax Choice5E1- AttributeSyntax j::=N |"MULTIVALUE"|empty9 N:SyntaxChoice ::= value(ATTRIBUTE-SYNTAX):M 9 Constraint|type MatchTypes9 X DConstraint ::= "("ConstraintAlternative")"|emptyD YEConstraintAlternative::= StringConstraint|IntegerConstraintE R >StringConstraint ::= "SIZE" "("SizeConstraint")"> H 4SizeConstraint ::= SingleValue|Range4 E1SingleValue ::= value(INTEGER)1NTEGER)O ;Range ::= value (INTEGER)".."value;*SingleValue j' ::= value(INTEGER)? N :Range ::= value(INTEGER)".."value:D0 (INTEGER)0<(IntegerConstraint ::= Range( R >MatchTypes ::= "MATCHES FOR" Matches|empty> J 6Matches ::= Match Matches|Match6 O ;Match ::= "EQUALITY"|"SUBSTRINGS"|;arious pieces of the notation introduced by the macro, is as M follows: d Pa)the object identifier assigned to the attribute type is the valuePR>supplied in the value assignment of the MACRO;> d Pb)the attribute syntax for the attribute type is that identified byPc OAttributeSyntax production; either separately defined attribute O_ Ksyntax described by an object identifier, or explicitly the K`Lattribute syntax with ASN.1 type and matching rules as given L^ J(see^9.6). If a separately identified attribute syntax is J` Lemployed, a size constraint for underlying string types or a L` Lvalue range for an underlying integer type may optionally be L. indicated. cOc)the attribute is single valued if the MultiValued production is Oc O"SINGLE VALUE", and may have one or more values if it is "MULTI O4  VALUE" or empty. UANote - The macro is used in defining selected attribute types in A*Recommendation^X.520. b NShould the "empty" alternative of the type notation be selected, the Nb Nresulting notation ("ATTRIBUTE") can be used to denote any possible attribute N type.  d P9.5.4The attribute types identified in 7.3.3 which are known to and used by PO ;the Directory for its own purposes are defined as follows:;]DL?+ObjectClass::= ATTRIBUTE+P<WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax<U ?+AliasedObjectName::- ATTRIBUTE+Q =WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax=0 SINGLE VALUE b Q9WITH ATTRIBUTE-SYNTAX objectIdentifierSynt#2cOallocated for these attribute types in Recommendation^X.520 so as to provide a O] Isingle point of allocation of these object identifiers in this series of I% Recommendations. d PNote 2 - The attribute syntaxes referred to in these definitions are themselves P&defined in 9.6.5. 9 %9.6Attribute Syntax definition%M99.6.1The definition of an attribute syntax involves:9_ Ka)optionally, assigning an object identifier to the attribute K+ syntax; _ Kb)indicating the data type, in ASN.1 of the attribute syntax;K d Pc)defining appropriate rules for matching a presented value with a PbNtarget attribute value held in the DIB. None, some, or all of N` Lthe following matching rules may be defined for a particular L5 !attribute syntax:! ]]DLIi)equality. Applicable to any attribute syntax. The I^Jpresented value must conform to the data type of the J; 'attribute syntax;'` Lii)substrings. Applicable to any attribute syntax with a Lc Ostring data type. The presented value must be a sequence Oa M("SEQUENCE OF"), each of whose elements conforms to the M4 data type;  cOiii)ordering. Applicable to any attribute syntax ford}de9.4.5The special object class Alias is defined in ^9.4.8.2. Every alias entry shall have an object @@=d)class which is a subclass of this class.)dyd]wNotew - The Directory's dereferencing of alias entries ensures that the values of the %!QxdbObjectClass attribute of an alias entry are rarely seen. It is recommended that appropriate alias @ VgdOobjec %TYPENOTATION ::=SubclassOf@@ F]DL.MandatoryAttributes@Ed-OptionalAttributes@)d A %TYPENOTATION ::=SubclassOf@@ F]DL.MandatoryAttributes@Ed-OptionalAttributes@dry services. A set of such `u asystems, together with the directory information which they hold, can be viewed as an integrated 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.V v b0.5Annex B summarizes the usage of ASN.1 object identifiers in this series of Recommendations.b vb0.6Annex C provides the ASN.1 module which contains all of the definitions associated with the b+ information framework.P [P G0.7Annex D lists alphabetically the terms defined in this document.G e Q0.8Annex E desccODirectory is composed of more than one DSA, it is said to be distributed. The OPzero, one or more of the access points. This is illustrated in Figure^2. Whre P4_KDirectory is composed of more than one DSA, it is said to be distributed. K8]Iprocedures for the operation of the Directory when it is distributed are I7 #specified in Recommendation^X.518.# d PNs) in which case the DMD is said to be an DManagement Domain (DMD).; d NNote - The organization which manages a DMD may be an Administration* (i.e. a JdTPpublic telecommunications administration or other organizations offering public P<]DL$telecommunications services) in whic2D is said to be an 2$2 case the DMD is said to be an .]DLCtelecommunications services) 4 Zobject identifiers produced by the Optional Attributes FS ?production, i.e. those following "MAY CONTAIN".? f PNote - The object identifiers in (c) and (d) identid Pthe intial vertex of an arc in the DIT whose final vertex is thatP# articular entry;(N _TK(object): relative formation to which the Directory provides access is known as the ]ewDirectory Information Basew (DIB). All of the pieces of information which can be read or manipulated%!Ia Mby the operations of the Directory are considered to be included in the DIB.M | `6.2.3An wobject classw is an identified family of objects (or conceivable objects) which share % !Ir^certain characteristics. Every object b }ed for these attributd Pd)the root repreents the highest level of naming authority for the Pk( DIB.Td]DLP6.4.3A superior/subordinate relationship between objects can be derived fromPb Nthat between entries. An object is an immediately superior object (immediate Nd Psuperior) of another object if and only if the object entry for the fng2" is a textual representation of suitable value.eu TaAlthough the attribute types in the examples are often based upon real types, such as at ]DL`those defined in Recommendation^X.520 (e.g. "C" stands for "Country", CN for "Common `d "string2" is a textual representation of VTT@Although the attril ]DLXthose defined in Recommendation^X.520 (e.g. "C" stands for "Country", CN for X*H : "AttributeValueAssertion ::=@9#SEQUENCE {AttributeType, @q&AttributeValue}@&alue} @'csertion ::=%K3SEQUENCE {AttributeType,AttributeValue} @'and is:I 5a)undefined, if any of the following holds:5 CO ;schemas, might have distinct name bindings in each schema.;_ Kor non-leaf vertices, whereas alias entries are always leaf Kd Pvertices. The root can be viewed as a null object entry (see (d)P+ Q 7Note - It is conceivable that an object class, occurrin (2 z  schemas, F 2might have distinct name bindings in each schema.2b  tself) without P^ Jconcerns for tN:WITH ATTRIBUTE-SYNTAX objectIdentierSyntax:a ?+AliasedObjectName::= ATTRIBUTE+Q =WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax=0 SINGLE VALUE ` LNote 1 - These are partial definitions: the object identifiers are actually L which a Od Prule can be defined that will allow a presented value to bePd Pdescribed as less than, equal to, or greater than a target Pc Ovalue. The presented value must conform to the data type OB .of the attribute syntax..U A9.6.2If no equality matching rule is defined, the Directory:A zstrative Authority is to implement these naming structures in the schema.PTn X<  SECTION 2 - wInformation modelw %!  ; !6Directory information base@@S ; !6Directory Information Base@@ T0]DL6.1wDefinitions|T`The Directory provides one or more waccess pointsw at which such accesses can take place. These #% !.@ ,concepts are illustrated in Figure^1/X.501., f]DLR5.2.2The services provided by the Directory are defined in Recommendation^X.511.RT XN:FIGURE 1/X.501:G 3presents the highest level of naming authority for the DIB.RTy]DLe6.4.3A superior/subordinate relationship between objects can be derived from that between entries. e dAn object is an wimmediately superior object (immediate superior)w of another object if and only if %0!"~y ethe object entry for the first object is the immediate superior of any of the entries for the second e eobject. The terms wimmedttribute types which the Directory knows about and uses for its own a,purposes. They include:z  ba)ObjectClass. An attribute of this type appears in every entry and indicates the object @ LU  Aclass and superclass(es) to which the object belongs.AP{P cb)AliasedObjectName. An attribute of this type appears in every alias entry and holds the @GJ'E OF RelativeDistinguishedName@%DL@(DistinguishedName ::= RDNSequence@! cwNotew - Names which are formed in other ways than as described herein are a possible future %!W  extension. R>8.2.3The null sequence is the name for the root of the tree.> x d8.2.4Each initial subsequenP w]DLc8.3.2The RDNs of all of the entries with a particular immediate superior are distinct. It is the cpT\responsibility of the relevant naming authority for that entry to ensure that this is so by \L8appropriately assigning distinguished attribute values.8  ewNotew - Frequently, an entry will contain a single distinguished value (and the RDN will thus %!Y} atld list. It may also make particular attributes mandatory for a particular object class, over and dU Aabove those required by the registered object class definition."A y e9.4.2There is one special object class, of which every other class is a subclass. This object class eA -is called "Top" and is defined in ^9.4.8.1.-]DLzTb9.4.3Every entry shall contain an attribute of type ObjectClasm objectP` Lis the immediate superior of any of the entriesset. _ K9.4.8The object classes previously mentioned are defined in 9.4.9.1-2.K ^ JNote - These are partial definitions: the object identifiers are actually Jb Nallocated for these object classes in Recommendation^X.521 so as to provide a N] Isingle point of allocation of thes MatchUALITY"|"SUBSTRINGS"|3ahat type, onG 3Match ::- "EQUALITY"|"SUBSTRINGS"|3;&E 1 "ORDERING"1!  END  b NThe correspondence between the parts of the definition, as listed in Na]DLM9.5.1, and the v TO DISPLAY A DIFFERENT FILE ---- T@Y@P@E@ N@A@M@E@ & R@E@T@U@R@N@. LYzZOPY TO DISPLAY A DIRECTORY LIST ---- T@Y@P@E@ D@ & R@E@T@U@R@N@. LYBqY)Recommendations X.501 and ISO 9594-2, The Directory-Models were developed in close UE 1collaboration and are technically aligned.1C '1wScope and field of applicationw%! /2wReferencesw% !0 3wDefinitionsw% ! 24wAbbreviationsw% ! : SECTION 1 - wDirectory modelw %! 4 5wDirectory modelw%!P <P  @index of these terms is provided in Annex^D for easy reference.@ T. 4Abbreviations@@  O;ADDMDAdministration Directory Management Domain;>*AVAAttribute value assertion*?+DIBDirectory Information Base+?ityw%! ? %wAnnex Aw - The mathematics of trees%! > $wAnnex Bw - Object identifier usage%! E +wAnnex Cw - Information framework in ASN.1%!" H .wAnnex Dw - Alphabetical index of definitions%!% ; !wAnnex Ew - Name design criteria%! 5 wAnnex Fw - Access control%!  e O 9]DLu a0.1This d - 0Introduction@@  ]DLu a0.1This document, together with the others of the series, has been produced to facilitate the at`interconnection of information processing systems to provide directoribes some criteria that can be considered in designing names.Q subclass.?]DL 10 TZ] I8)Annex E describes some criteria that can be considered in I names. K70.9Annex F describes guidelines for access control.7  ?%1Scope and field of application@@ Oa)waccess point:w The point at which an abstract service is obtained. % !5 z  ^b)wAdministration Directory Management Domain (ADDMD):w A DMD which is managed by an %3!/  Administration.  dwNotew - The term "Administration" denotes a public telecommunications administration or %!S~_ Kother organization of