ISO/IEC 9594-2:1990

I NTE R NATIONAL
ISOIIEC
STANDARD
First edition
1990-1 2- 15
Information technology - Open Systems
Interconnection - The Directory -
Part 2:
Models
Technologies de l'information - Interconnexion de systèmes ouverts - L'annuaire -
Partie 2: Modèles
Reference number
ISO/IEC 9594-2 : 1990 (E)
ISO/IEC 9594-2 1990(E)
Con tents
Page
...
Foreword . 111
Introduction . iv
SECTION 1: GENERAL 1
1 Scope . 1
2 Normative references . 1
3 Definitions . 1
4 Abbreviations . 2
SECTION 2: DIRECTORY MODEL 2
5 Directory Model . 2
SECTION 3: INFORMATION MODEL 3
6 Directory Information Base . 3
7 Directory Entries . 5
8 Names . 6
9 Directory Schema . 8
SECTION 4: SECURITY MODEL 13
10 Security . 13
Annex A - The Mathematics of Trees . 14
Annex B - Object Identifier Usage . 15
Annex C - Information Framework in ASN.l . 16
Annex D - Alphabetical Index of Definitions . 19
Annex E - Name Design Criteria . 20
Annex F - Access Control . 21
O ISO/IEC 1990
All rights reserved . No part of this publication may be reproduced or utilized in any form or by
any means. electronic or mechanical. including photocopying and microfilm. without permission
in writing from the publisher .
ISO/IEC Copyright Office 0 Case postale 56 0 CH-1211 Genève 20 0 Switzerland
Printed in Switzerland
ISO/IEC 9594-2 : 1990(E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardiz-
ation. National bodies that are members of IS0 or IEC participate in the development
of International Standards through technical committees established by the respective
organization to deal with particular fields of technical activity. IS0 and IEC technical
committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with IS0 and IEC, also take part in the
work.
In the field of information technology, IS0 and IEC have established a joint technical
committee, ISOAEC JTC 1. Draft International Standards adopted by the joint
technical committee are circulated to national bodies for voting. Publication as an
International Standard requires approval by at least 75 '70 of the national bodies casting
a vote.
International Standard ISO/IEC 9594-2 was prepared by Joint Technical Committee
ISO/IEC JTC 1, In formation technology.
ISO/IEC 9594 consists of the following parts, under the general title Information
technology - Open Systems Interconnection - The Directory:
- Part I: Overview of concepts, models and services
- Part 2: Models
- Part 3: Abstract service definition
- Part 4: Procedures for distributed operation
- Part 5: Protocoi specifications
e
- Part 6: Selected attribute types
- Part 7: Selected object classes
- Part 8: Authentication framework
Annexes B and C form an integral part of this part of ISOAEC 9594. Annexes A,
D, E and F are for information only.
...
ISO/IEC 9594-2 : 1990(E)
Introduction
0.1 This part of ISO/IEC 9594, together with the other parts, has been produced to facilitate the interconnection of
information processing systems to provide directory services. A set of such systems, together with the directory information
which they hold, can be viewed as an integrated whole, called the Directory. The information held by the Directory,
collectively known as the Directory Information Base (DIB), is typically used to facilitate communication between, with or
about objects such as application entities, people, terminals and distribution lists.
0.2 The Directory plays a significant role in Open Systems Interconnection, whose aim is to allow, with a minimum of
technical agreement outside of the interconnection standards themselves, the interconnection of information processing
systems:
from different manufacturers;
under different managements;
of different levels of complexity; and
of different ages.
0.3 This part of ISO/IEC 9594 provides a number of different models for the Directory as a framework for the other parts of
ISO/IEC 9594. The models are the overall (functional) model; the organizational model; the security model; and the
information model. The latter describes the manner in which the Directory organizes the information it holds. It describes, for
example, how information about objects is grouped to form directory entries for those objects and how that information
provides names for objects.
0.4 Annex A summarizes the mathematical terminology associated with tree structures.
0.5 Annex B summarizes the usage of ASN.l object identifiers in ISO/IEC 9594.
0.6 Annex C provides the ASN.l module which contains all of the definitions associated with the infoimation framework.
0.7 Annex D lists alphabetically the terms defined in this document.
0.8 Annex E describes some criteria that can be considered in designing names.
0.9 Annex F describes guidelines for access control.
0.10 Annex G describes the derivation of a subclass.
iv
ISO/IEC 9594-2 : 1990 (E)
INTERNATIONAL STANDARD
Information technology - Open Systems Interconnection -
The Directory -
Part 2:
Models
SECTIOP 1: GENERAL
Information Technology - Open
ISO/IEC 8824: 1990,
1 Scope
Systems Interconnection -
1.1 The models defined in this part of ISO/IEC 9594
Specifcation of Abstract Syntax
provide a conceptual and terminological framework for the
Notation One (ASNJ).
other parts of ISO/IEC 9594 which define various aspects
of the Directory.
ISO/IEC 9594-1 : 1990, Information Technology - Open
Systems Interconnection - The
1.2 The functional and organizational models define
Directory - Part I: Overview of
ways in which the Directory can be distributed, both
Concepts, Models and Services.
functionally and administratively.
ISOAEC 9594-3: 1990, In formation Technology - Open
The security model defines the framework within
1.3
Systems Interconnection - The
which security features, such as access control, are
Directory - Part 3: Abstract Service
provided in the Directory.
Definition.
1.4 The information model describes the logical structure
ISOAEC 9594-4:1990, Information Technology - Open
of the DIB. From this viewpoint, the fact that the Directory
Systems Interconnection - The
is distributed, rather than centralized, is not visible. The
Directory - Part 4: Procedures for
other parts of ISODEC 9594 make use of the concepts of
Distributed Operation.
the information framework. Specifically:
ISOAEC 9594-5: 1990, Information Technology - Open
the service provided by the Directory is described
a)
Systems Interconnection - The
(in ISO/IEC 9594-3) in terms of the concepts of the
Directory - Part 5: Protocol
information framework: this allows the service
Specifications.
provided to be somewhat independent of the
physical distribution of the DIB;
ISOAEC 9594-6:1990, Information Technology - Open
b) the distributed operation of the Directory is
Systems Interconnection - The
specified (in ISO/IEC 9594-4) so as to provide that
Directory - Part 6: Selected At-
service, and therefore maintain that logical
tribute Types.
information structure, given that the DIB is in fact
highly distributed.
ISOAEC 9594-7: 1990, Information Technology - Open
Systems Interconnection - The
Directory - Part 7: Selected Object
Classes.
2 Normative references
The following standards contain provisions which, through
ISOAEC 9594-8:1990, Information Technology - Open
reference in this text, constitute provisions of this part of
Systems Interconnection - The
ISO/IEC9594. At the time of publication, the editions
Directory - Part 8: Authentication
indicated were valid. All standards are subject to revision,
Framework.
and parties to agreements based on this part of
ISODEC 9594 are encouraged to investigate the possibility
of applying the most recent editions of the standards listed
below. Members of IEC and IS0 maintain registers of
currently valid International Standards.
3 Definitions
Definitions of terms are included at the beginning of
IS0 7498: 1984, Information Processing Systems -
individual clauses, as appropriate. An index of these terms
Open Systems Interconnection -
is provided in annex D for easy reference.
Basic Reference Model.
ISO/IEC 9594-2 : 1990(E)
DIT Directory Information Tree
DMD Directory Management Domain
4 Abbreviations
DSA Directory System Agent
ADDMD Administration Directory Management DUA Directory User Agent
Domain PRDMD Private Directory Management Domain
AVA attribute value assertion RDN Relative Distinguished Name
DIB Directory Information Base
SECTION 2: DIRECTORY MODEL
(DUA), which actually accesses the Directory and interacts
with it to obtain the service on behalf of a particular user.
5 Directory Model
The Directory provides one or more access points at which
such accesses can take place. These concepts are illustrated
5.1 Definitions
in figure 1.
5.1.1 Access Point : the point at which an abstract
service is obtained
Access Point
5.1.2 Administration Directory Management Domain
(ADDMD) : A DMD which is managed by an
Administration.
Note - The term Administration denotes a public
telecommunications administration or other organization
offering public telecommunications services;
5.1.3 Administrative Authority : An entity which has
administrative control over all entries stored within a
~
single Directory System Agent.
Figure 1 - Access to the Directory
5.1.4 the Directory : A repository of information about
The services provided by the Directory are defined
5.2.2
objects, and which provides directory services to its users
in ISODEC 9594-3.
which allow access to the information.
5.2.3 The Directory is a repository of information about
5.1.5 Directory Management Domain (DMD) : A
objects, and the directory services it provides to its users
collection of one or more DSAs and zero or more DUAs
are concerned with various kinds of access to this
which is managed by a single organization.
information. The information is collectively known as the
Directory Information Base (DIB). A model for the DIB is
5.1.6 Directory System Agent (DSA) : An OS1
defined in section three of this part of ISODEC 9594.
application process which is part of the Directory.
5.2.4 A DUA is manifested as an application-process.
5.1.7 (Directory) user : The end user of the Directory,
Each DUA represents precisely one directory user.
i.e., the entity or person which accesses the Directory.
Notes
5.1.8 Directory User Agent (DUA) : An OS1 application
1. Some open systems may provide a centralized DUA
process which represents a user in accessing the Directory.
function retrieving information for the actual users (application-
processes, persons, etc.). This is transparent to the Directory.
Note - DUAs may also provide a range of local facilities to
2 The DUA functions and a DSA (see 5.3.1) can be within
assist users compose queries and interpret the responses.
the same open system, and it is an implementation choice
whether to make one or more DUAs visible within the OS1
5.1.9 Private Directory Management Domain (PRDMD) Environment as application-entities.
: A DMD which is managed by an organization other than
3. A DUA may exhibit local behavior and structure which is
an Administration*.
outside the scope of ISO/IEC 9594. For example, a DUA which
represents a human directory user may provide a range of local
facilities to assist its user to compose queries and interpret the
5.2 The Directory and its Users
responses.
5.2.1 A directory user (e.g., a person or an application-
process) obtains directory services by accessing the
Directory. More precisely, it is a Directory User Agent
ISO/IEC 9594-2 : 1990(E)
different open systems. Such an interaction is carried out
5.3 Functional Model
by means of OS1 Directory protocols, as specified in
5.3.1 The Directory is manifested as a set of one or more
ISO/IEC 9594-5.
application-processes known as Directory System Agents
(DSAs), each of which provides zero, one, or more of the
5.4 Organizational Model
access points. This is illustrated in figure 2. Where the
Directory is composed of more than one DSA, it is said to 5.4.1 A set of one or more DSAs and zero or more
be distributed. The procedures for the operation of the
DUAs managed by a single organization may form a
Directory when it is distributed are specified in
Directory Management Domain (DMD).
ISO/IEC 9594-4.
Note - The organization which manages a DMD may be an
Note - A DSA will likely exhibit local behavior and structure Administration* (i.e., a public telecommunications
which is outside the scope of ISO/IEC 9594. For example, a administration or other organization offering public
DSA which is responsible for holding some or all of the telecommunications services) in which case the DMD is said to
information in the DIB will normally do so by means of a be an Administration DMD (ADDMD); otherwise it is a Private
database, the interface to which is a local matter. DMD (PRDMD). It should be recognized that the provision of
support for private directory systems by CCITT members falls
within the framework of national regulations. Thus, the technical
possibilities described may or may not be offered by an
Administration* which provides directory services. The internal
operation and configuration of private DMDs is not within the
scope of envisaged CCITT Recommendations.
5.4.2 Management of a DUA by a DMD implies an
ongoing responsibility for service to that DUA, e.g.,
maintenance, or in some cases ownership, by the DMD.
5.4.3 The organization concerned may or may not elect
to make use of ISO/IEC 9594 to govern any interactions
among DUAs and DSAs which are wholly within the
DMD.
5.4.4 Each DSA is administered by an Administrative
Authority. This entity has control over all object entries
and alias entries stored by that DSA. This includes
responsibilities for the Directory schema being used to
~~~ ~~
guide the creation and modification of entries (see clause
Figure 2 -The Directory Provided by Multiple DSAs
9). The structure and allocation of names is the
responsibility of a naming authority (see 8.1.6) and the role
5.3.2 A particular pair of application-processes which of the Administrative Authority is to implement these
need to interact in the provision of directory services naming structures in the schema.
(either a DUA and a DSA, or two DSAs) may be located in
SECTION 3: INFORMATION MODEL
6.1.3 Directory Information Tree (DIT): the DIB
considered as a tree, whose vertices (other than the root)
6 Directory Information Base
are the Directory entries.
6.1 Definitions
Note - The term DIT is used instead of DIB only in contexts
6.1.1 alias entry : an entry of the class "alias" containing
where the tree structure of the information is relevant.
information used to provide an alternative name for an
object.
6.1.4 (Directory) entry : a part of the DIB which
contains information about an object.
6.1.2 Directory Information Base (DIB) : the complete
set of information to which the Directory provides access,
6.1.5 immediate superior (noun) : relative to a particular
and which includes all of the pieces of information which
entry or object (it shall be clear from the context which is
can be read or manipulated using the operations of the
intended), the immediately superior entry or object.
Directory.
ISO/IEC 9594-2 : 1990(E)
6.1.6 inzmediately superior which can be read or manipulated by the operations of the
Directory are considered to be included in the DIB.
(entry): relative to a particular entry - an entry which is
at the initial vertex of an arc in the DIT whose final
6.2.3 An object class is an identified family of objects
vertex is that of the particular entry:
(or conceivable objects) which share certain
characteristics. Every object belongs to at least one class.
(object): relative to a particular object - an object whose
object entry is the immediate superior of any of the An object class may be a subclass of another object class,
entries (object or alias) for the second object. in which case the members of the former class (the
subclass) are also considered to be members of the latter
(the superclass). There may be subclasses of subclasses,
6.1.7 object (of interest) : anything in some 'world',
etc., to an arbitrary depth.
generally the world of telecommunications and
information processing or some part thereof, which is
identifiable (can be named), and which it is of interest to
6.3 Directory Entries
hold information on in the DIB.
6.3.1 The DIB is composed of Directory entries (entries)
each containing information about (describing) a single
object class : an identified family of objects (or
6.1.8
object.
conceivable objects) which share certain characteristics.
6.3.2 For any particular object there is precisely one
6.1.9 object entry : an entry which is the primary
object entry, this being the primary collection of e
collection of information in the DIB about an object, and
information in the DIB about that object. The object entry
which can therefore be said to represent that object in the
is said to represent the object.
DIB.
6.3.3 For any particular object there may, in addition to
6.1.10 subclass: relative to a superclass -- an object class
the object entry, be one or more alias entries for that
derived from a superclass. The members of the subclass
object, which are used to provide alternative names (see
share all the characteristics of another object class (the
8.5).
superclass) and additional characteristics possessed by
none of the members of that object class (the superclass).
6.3.4 The structure of directory entries is depicted in
figure 3 and described in 7.2.
6.1.11 subordinate linferiol.: the converse of superior.
6.3.5 Each entry contains an indication of the object
6.1.12 superclass: relative to a subclass -- an object class
class and the superclasses of that object class with which
from which a subclass is derived.
the entry is associated. In the case of an object entry, this
indicates the class(es) to which the object belongs. In the
6.1.13 superior : (applying to entry or object)
case of an alias entry, this indicates (by means of a special
immediately superior, or superior to one which is
object class, "alias" (defined in 9.4.8.2)) that it is in fact an
immediately superior (recursively),
alias entry, and may also indicate to which subclass(es) of
the alias object class the entry belongs.
6.2 Objects
-
6.2.1 The purpose of the Directory is to hold, and 6.4 The Directory Information Tree (DIT)
provide access to, information about objects of interest
6.4.1 In order to satisfy the requirements for the
(objects) which exist in some 'world'. An object can be
distribution and management of a potentially very large
anything in that world which is identifiable (can be
DIB, and to ensure that objects can be unambiguously
named).
named (see clause S), and their entries found, a flat
Notes structure of entries is not likely to be feasible.
Accordingly, the hierarchical relationship commonly
1. The 'world' is generally that of telecommunications and
found among objects (e.g., a person works for a
information processing or some part thereof.
department, which belongs to an organization, which is
2 The objects known to the Directory may not correspond
headquartered in a country) can be exploited, by the
exactly with the set of 'real' things in the world. For example, a
arrangement of the entries into a tree, known as the
real-world person may be regarded as two different objects, a
Directory Information Tree (DIT).
business person and a residential person, as far as the Directory
is concerned. The mapping is not defined in ISO/IEC 9594, but
Note - An introduction to the concepts and terminology of tree
is a matter for the users and providers of the Directory in the
structures can be found in annex A.
context of their applications.
6.4.2 The component parts of the DIT have the
6.2.2 The complete set of information to which the following interpretations:
Directory provides access is known as the Directory
the vertices are the entries. Object entries may be
a)
Znfornzation Base (DIB). All of the pieces of information
either leaf or non-leaf vertices, whereas alias entries
ISO/IEC 9594-2 : 199O(E)
suitable value. Although the attribute types in the examples are
are always leaf vertices. The root is not an entry as
often based upon real types, such as those defined in
such, but can, where convenient to do so (e.g., in the
ISO/IEC 9594-7 (e.g., "C" stands for "Country", CN for
definitions of (b) and (c) below), be viewed as a null
"Common Name"), this is not strictly necessary for the purposes
object entry (see (d) below);
of this document, as the Directory is usually unaware of the
meanings of the attribute types in use.
b) the arcs define the relationship between vertices
(and hence entries). An arc from vertex A to vertex
7.1.5 distinguished value : an attribute value in an entry
B means that that the entry at A is the immediately
which has been designated to appear in the relative
superior entry (immediate superior) of the entry at
B, and conversely, that the entry at B is an distinguished name of the entry.
immediately subordinate entry (immediate
subordinate) of the entry at A. The superior entries
7.2 Overall Structure
(superiors) of a particular entry are its immediate
7.2.1 As depicted in figure 3, an entry consists of a set of
superior together with & superiors (recursively).
attributes.
The subordinate entries (subordinates) of a
particular entry are its immediate subordinates
together with their subordinates (recursively);
ENTRY
the object represented by an entry is, or is closely
c)
ttribute 0 0 O ttribute
associated with, the naming authority (see clause 8)
bz1
for its subordinates;
the root represents the highest level of naming
d)
A
authority for the DIB.
1 ATTRIBUTE \
6.4.3 A superiorlsubordinate relationship between
objects can be derived from that between entries. An
object is an immediately superior object (immediate
superior) of another object if and only if the object entry
for the first object is the immediate superior of any of the
entries for the second object. The terms immediately
subordinate object, immediate subordinate, superior and
subordinate (applied to objects) have their analogous
meanings.
6.4.4 Permitted superiorlsubordinate relationships
among objects are governed by the DIT structure
definitions (see 9.2).
Figure 3 -Structure of an Entry
7 Directory Entries
7.2.2 Each attribute provides a piece of information
about, or describes a particular characteristic of, the object
7.1 Definitions
to which the entry corresponds.
7.1.1 attribute : the information of a particular type
Note - Examples of attributes which might be present in an entry
concerning an object and appearing in an entry describing
include naming information such as the object's personal name,
that object in the DIB.
and addressing information, such as its telephone number.
7.1.2 attribute type : that component of an attribute
7.2.3 An attribute consists of an attribute type, which
which indicates the class of information given by that
identifies the class of information given by an attribute,
attribute.
and the corresponding attribute value(s), which are the
particular instances of that class appearing in the entry
7.1.3 attribute value : a particular instance of the class of
information indicated by an attribute type.
Attribute ::=
SEQUENCE {
type AttributeType,
7.1.4 attribute value assertion : a proposition, which
values SET OF Attributevalue
may be true, false, or undefined, concerning the values (or
- - at least une value is required - - }
perhaps only the distinguished values) of an entry.
Note - In this document the notation "string1 = string2" is used 7.3 Attribute Types
to write down examples of attribute value assertions. In this
7.3.1 Some attribute types will be internationally
notation, "stringl" is an abbreviation for the 'name' of the
standardized. Other attribute types will be defined by
attribute type, and "string2" is a textual representation of a
ISO/IEC 9594-2 : 1990(E)
2 the attribute syntax for the type has no equality
national administrative authorities and private
organizations. This implies that a number of separate matching rule,
authorities will be responsible for assigning types in a way
3) the value does not conform to the data type of
that ensures that each is distinct from all other assigned
the attribute syntax;
types. This is accomplished by identifying each attribute
Note - 2) and 3) normally indicate a faulty AVA; 1),
type with an object identifier when the type is defined (as
however, may occur as a local situation (e.g., a particular
described in 9.5):
DSA has not registered that particular attribute type).
AttributeType ::= OBJECT IDENTIFIER
b) true, if the entry contains an attribute of that type,
one of whose values matches that value (if the
7.3.2 All attributes in an entry shall be of distinct
assertion is concerned only with distinguished
attribute types.
values, then the matched value shall be the
distinguished one);
7.3.3 There are a number of attribute types which the
Directory knows about and uses for its own purposes. Note - The matching of values is for equality, and involves the
matching rule associated with the attribute syntax.
They include:
Objectclass - An attribute of this type appears in
a)
c) false, otherwise.
every entry, and indicates the object class and
superclass(es) to which the object belongs.
b) AliasedObjectName - An attribute of this type
8 Names
appears in every alias entry, and holds the
distinguished name (see 8.5) of the object which
8.1 Definitions
this alias entry describes.
8.1.1 alias, alias nanze: a name for an object, provided
by the use of one or more alias entries in the DIT.
These attributes are (partially) defined in 9.5.4.
8.1.2 dereferencing : replacing the alias name for an
7.3.4 The types of attributes which shall or which may
object by the object’s distinguished name.
appear within an entry (other than as mentioned in 7.3.3)
are governed by rules applying to the indicated object
8.1.3 distinguished nunze (of an object): one of the
class(es).
names of the object, formed from the sequence of the
RDNs of the object entry and each of its superior entries.
7.4 Attribute Values
7.4.1 Defining an attribute type (see 9.5) also involves
8.1.4 (directory) name : a construct that singles out a
specifying the syntax, and hence data type, to which every
particular object from all other objects. A name shall be
value in such attributes shall conform. This could be any
unambiguous (that is, denote just one object), however it
data type:
need not be unique (that is, be the only name which
unambiguously denotes the object).
Attributevalue ::= ANY
8.1.5 purported name : a construct which is syntactically
7.4.2 At most one of the values of an attribute may be
a name, but which has not (yet) been shown to be a valid
designated as a distinguished value, in which case the
name.
attribute value appears in the relative distinguished name
(see 8.3) of the entry.
8.1.6 naming authority : an authority responsible for the
allocation of names. Each object whose object entry is
7.4.3 An attribute value assertion (A VA) is a
located at a non-leaf vertex in the DIT is, or is closely
proposition, which may be true, false, or undefined,
associated with, a naming-authority.
concerning the values (or perhaps only the distinguished
values) of an entry. It involves an attribute type and an
8.1.7 relative distinguished name (RDN): a set of
attribute value
attribute value assertions, each of which is true, concerning
the distinguished values of a particular entry.
AttributeValueAssertion :=
SEQUENCE {AtîributeType, AttributeValuel
8.2 Names in General
and is:
8.2.1 A (directory) name is a construct that identifies a
particular object from among the set of all objects. A name
undefined, if any of the following holds:
a)
shall be unambiguous, that is, denote just one object.
However, a name need not be unique, that is be the only
1) the attribute type is unknown,
name that unambiguously denotes the object.
ISO/IEC 9594-2 : 1990(E)
in the Directory itself) without concerns for their obsolescence.
8.2.2 Syntactically, each name for an object is an
Thus RDNs should be changed cautiously.
ordered sequence of relative distinguished names (see 8.3).
Name ::=
8.4 Distinguished Names
CHOICE { - - only one possibility for now - -
RDNSequence 1
8.4.1 The distinguished name of a given object is
defined as being the sequence of the RDNs of the entry
RDNSequence ::= SEQUENCE OF
RelativeDistinguishedName which represents the object and those of all of its superior
entries (in descending order). Because of the one to one
DisiinguishedName ::= RDNSequence
correspondence between objects and object entries, the
Note- Names which are formed in other ways than as described distinguished name of an object can be considered to also
herein are a possible future extension.
identify the object entry.
Notes
The null sequence is the name for the root of the
8.2.3
1 It is preferable that the distinguished names of objects
tree.
which humans have to deal with be user-friendly.
8.2.4 Each initial subsequence of the name of an object
2 IS0 7498-3 defines the concept of a primitive name. A
is also the name of an object. The sequence of objects so distinguished name can be used as a primitive name for the
object it identifies because: (a) it is unambiguous, (b) it is
identified, starting with the root and ending with the object
unique, and (c) the semantics of its internal structure (a
being named, is such that each is the immediate superior of
scquence of RDNs) need not (but of course may) be understood
that which follows it in the sequence.
by the user of the Directory.
3 Because only the object entry and its superiors are
8.2.5 A purported name is a construct which is
involved, distinguished names of objects can never involve alias
syntactically a name, but which has not (yet) been shown
entries.
to be a valid name.
8.4.2 It proves convenient to define the 'distinguished
name' of the root and of an alias entry, although in neither
8.3 Relative Distinguished Names
case is the name also the distinguished name of an object.
8.3.1 Each entry has a unique relative distinguished
The distinguished name of the root is defined to be the null
name (RDN). An RDN consists of a set of attribute value
sequence. The distinguished name of an alias entry is
assertions, each of which is true, concerning the
defined to be the sequence of RDNs of the alias entry and
distinguished values of the entry.
those of all of its superior entries (in descending order).
RelativeDistinguishedName ::=
~ 8.4.3 An example which illustrates the concepts of RDN
SET OF AttributeValueAsseriion
and distinguished name appears in figure 4.
The set contains exactly one assertion about each
RDN Distinguished Name
distinguished value in the entry.
ROOT I I
8.3.2 The RDNs of all of the entries with a particular
immediate superior are distinct. It is the responsibility of
the relevant naming authority for that entry to ensure that
this is so by appropriately assigning distinguished attribute
values.
Organizations
O=Telecom {C=GB, O=Telecom)
Note - Frequently, an entry will contain a single distinguished
value (and the RDN will thus comprise a single AVA); however,
3rganizational Units
{C=GB, O=Telecom,
under certain circumstances (in order to differentiate), additional (OU=Sales,
(OU=Sales, L=lpswich))
values (and hence AVAs) may be used. L=lpçwich)
{CsGB, O=Telecom,
8.3.3 The RDN for an entry is chosen when the entry is
d h CN=Smith (OU=Sales, L=lpswich),
created. A single value instance of any attribute type may
CN=Smith)
form part of the RDN, depending on the nature of the
~-~~ ~~ ~
object class denoted. Allocation of RDNs is considered an
Figure 4 -Determination of Distinguished Names
administrative undertaking that may or may not requise
some negotiation between involved organizations or
8.5 Alias Names
administrations. This part of ISO/IEC 9594 does not
provide such a negotiation mechanism, and makes no
8.5.1 An alias, or an alias name, for an object is a name
assumption as to how it is performed. The RDN may be
at least one of whose RDNs is that of an alias entry.
modified if necessary by complete replacement.
Aliases permit object entries to achieve the effect of
having multiple immediate superiors. Therefore, aliases
Note - RDNs are intended to be long-lived so that the users of
provide a basis for alternative names.
the Directory can store the distinguished names of objects (e.g.,
ISO/IEC 9594-2 : 1990(E)
9.2.2 Formally , the Directory Schema comprises a set of
8.5.2 Just as the distinguished name of an object
expresses its principal relationship to some hierarchy of
a) DIT Structure definitions (rules) that define the
objects, so an alias expresses (in the general case) an
distinguished names that entries may have and the
alternative relationship to an different hierarchy of objects.
ways in which they may be related to one another
through the DIT.
8.5.3 An object with an entry in the DIT may have zero
b) Object Class definitions that define the set of
or more aliases. It, therefore, follows that several alias
mandatory and optional attributes that shall be
entries may point to the same object entry. An alias entry
present, and may be present, respectively, in an
may point to an object entry that is not a leaf entry. Only
entry of a given class (see 6.2.3 of ISO/IEC 9594-
object entries may have aliases. Thus aliases of aliases are
not permitted.
2).
c) Attribute Type definitions that identify the object
An alias entry shall have no subordinates, that is,
8.5.4
identifier by which an attribute is known, its syntax,
an alias entry is a leaf entry.
and whether it is permitted to have multiple values.
8.5.5 The Directory makes use of the aliased object d) Attribute Syntax definitions that define for each
attribute the underlying ASN.1 data type and
name attribute in an alias entry to identify and to find the
matching rules.
corresponding object entry.
Figure 5 summarizes the relationships between the schema
definitions on the one side, and the DIT, directory entries,
9 Directory Schema
attributes, and attribute values on the other.
9.1 Definitions
9.2.3 The Directory Schema is distributed, like the DIB
9.1.1 Directory Schema: The set of rules and constraints
itself. Each Adniinistrative Authority establishes the part
concerning DIT structure, object class definitions, attribute
of the schema that will apply for those portions of the DIB
types and syntaxes which characterize the DIB.
administered by the authority.
9.1.2 DIT Sn-ucture Rule: A rule, forming part of the Note - Distribution of schema information across DSAs managed
by different Administrative Authorities is not supported by this
Directory Schema, which relates an object class (the
version of ISO/IEC 9594. Such distribution is handled adminis-
subordinate) to another object class (the superior) and
tratively by bilateral agreements.
which allows an entry of the former class to be
immediately subordinate to one of the latter classes in the
9.2.4 The specification of what is involved in the definition
DIT. The rule also governs the attribute type(s) permitted
of DIT structure, object classes, attribute types and
to appear in the (subordinate) entry's RDN, and may
attribute syntaxes can be found in 9.3 through 9.6
impose additional conditions. The schema may contain
respectively.
many such rules.
9.2 Overview
Definitions DIT elements
9.2.1 The Directory Schema is a set of definitions and
DIT
constraints concerning the structure of the DIT and the
possible ways entries are named, the information that can
belongs to
be held in an entry, and the attributes used to represent that
information.
Entries
Notes
1 The schema enables the directory system to, for example:
prevent the creation of subordinate entries of the wrong
object-class (e.g., a country as a subordinate of a
uses 4
belongs to?
person);
prevent the addition of attribute-types to an entry
inappropriate to the object-class (e.g., a serial number
to a person's entry);
Figure 5 - Overview of Directory Schema
prevent the addition of an attribute value of a syntax
not matching that defined for the attribute-type (e.g., a
9.3 DIT Structure Definition
printable string to a bit string).
9.3.1 A DIT Structure Rule defines the permitted
2 Dynamic mechanisms for the management of the directory
hierarchical relationships between entries, and their
schema are not presently provided by ISO/IEC 9594.
ISO/IEC 9594-2 : 1990(E)
permitted RDNs. The definition of a DIT Structure Rule
d) listing the optional attribute types that an entry of
involves: the object class may contain in addition to the
optional attributes of all its superclasses.
identifying the subordinate and superior object
classes;
Note -- An object class without an assigned object identifier is
intended for local use as a means of conveniently adding new
identifying the attribute types which may be
attribute types to a pre-defined superclass. This addition allows
involved in subordinate entries' RDNs; and
for a number of possibilities. For example, an Administrative
authority may define an unregistered Object Class so as to
(optionally) additional information.
permit a user to add any registered attribute to the entry. The
Administrative authority may limit the attributes for an entry for
9.3.2 The Directory permits an entry to stand in the
a particular object class to those on a locally held list. It may
relationship of immediate subordinate to another (its
also make particular attributes mandatory for a particular object
immediate superior) only if there exists a DIT structure
class, over and above those required by the registered object
rule, contained in the schema (see 9.2.3) applicable to the
class definition.
portion of the DIB that would contain the entry, for which:
9.4.2 There is one special object class, of which every
the entry is of the subordinate object class;
other class is a subclass. This object class is called Top and
the immediate superior of the entry is of the
is defined in 9.4.8.1.
superior object class;
9.4.3 Every entry shall contain an attribute of type object
the attribute type(s) forming the entry's RDN is
class to identify the object class and superclasses to which
(are) among those permitted;
the entry belongs. The definition of this attribute is given
any conditions imposed by the additional
in 9.5.4. The attribute is multivalued. There shall be one
information are satisfied.
value of the attribute for the object class and each of its
superclasses for which an object identifier is defined,
Notes
except that the value of Top need not be present so long as
1. Techniques for documenting DIT Structure or for some other value is present.
rcpresenting structure rules in thc DIB arc not presently
providcd by ISO/IEC 9594.
Notes
2. if a DIT Structure rule permits subordinates or supcriors
1. The requirement that the Objectclass attribute be
bclonging to a particular class, it implicitly (unless cxplicitly
present in every entry is reflected in the definition of Top.
overridden) also allows subordinates or superiors belonging to
2 Because an object class is considered to belong to all its
any object class derivcd from that class (see 9.4).
superclasses, each member of the chain of superclasses up to
9.3.3 The Directory enforces the defined structure rules Top is represented by a value in the object class attribute (and
at every entry in the DIT. Any attempt to modify the DIT any value in the chain may be matched by a filter).
in such a way as to violate the applicable structure rules
The ObjectClass attribute is managed by the Directory,
fails.
i.e., it may not be modified by the user.
9.3.4 A DIT Structure Rule in which an object class is
9.4.4 The Directory enforces the defined object class for
0 the subordinate is termed a name binding for that object
every entry in the DIB. Any attempt to modify an entry
class.
that would violate the entry's object class definition fails.
9.3.5 For an object class to be represented by entries in a
Note - In particular, the Directory will prevent:
portion of the DIB, at least one name binding for that
a) attribute types absent from the object class definition being
object class shall be contained in the applicable part of the
added to an entry of that object class;
schema. The schema contains additional name bindings as
required. b) an entry being created with one or more absent mandatory
attribute types for the object class of the entry;
9.4 Object Class Definition c) a mandatory attribute type for the object class of the entry being
deleted.
9.4.1 The definition of an object-class involves:
9.4.5 The special object class Alias is defined in 9.4.8.2.
a) optionally, assigning an object-identifier for the
Every alias entry shall have an object class which is a
object-class;
subclass of this class.
b) indicating which classes this is to be a subclass of;
Note- The Directory's dereferencing of alias entrics ensures that
c) listing the nzundutory attribute types that an entry
the values of the Objectclass attribute of an alias entry arc rarely
of the object class shall contain in addition to the
seen. It is recommended that appropriate alias object classes be
mandatory attribute types of all its superclasses;
derived from Alias without assigning an object identifier.
ISO/IEC 9594-2 : 1990(E)
notation ("OBJECT-CLASS") can be used to denote any possible
9.4.6 The following ASN.l macro may (but need not) be
object class.
used to define an object class. The empty production for
SubcIassOf is permitted only in defining Top:
9.4.7 An attribute
...