NAT L INST, OF STAND S TECH R IC.

lilllllliiiililllilil I NIST Special Publication 500-228

AlllOM bS7t.l3

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

uomputer

Systems Guidelines for the Evaluation

Technolosv

us DEPARTMENT OF of X.500 DiFcctory Products

COMMERCE

Technology Administration

National Institute of Johfl Tebbutt

Standards and

Technology

QC

100

.U57

10.500-228

1995
The National Institute of Standards and Technology was established in 1988 by Congress to "assist industry

in the development of technology . . . needed to improve product quality, to modernize manufacturing processes,

to ensure product reliability . . . and to facilitate rapid commercialization ... of products based on new scientific discoveries." NIST, originally founded as the National Bureau of Standards in 1901, works to strengthen U.S. industry's

competitiveness; advance science and engineering; and improve public health, safety, and the environment. One of the agency's basic functions is to develop, maintain, and retain custody of the national standards of measurement, and

provide the means and methods for comparing standards used in science, engineering, manufacturing, commerce,

industry, and education with the standards adopted or recognized by the Federal Government.

As an agency of the U.S. Commerce Department's Technology Administration, NIST conducts basic and applied research in the physical sciences and engineering, and develops measurement techniques, test methods, standards, and

related services. The Institute does generic and precompetitive work on new and advanced technologies. NIST's

research facilities are located at Gaithersburg, MD 20899, and at Boulder, CO 80303. Major technical operating units and their principal activities are listed below. For more information contact the Public Inquiries Desk, 301-975-3058.

Office of the Director

• Advanced Technology Program

• Quality Programs

• International and Academic Affairs

Technology Services

• Manufacturing Extension Partnership

• Standards Services

• Technology Commercialization

• Measurement Services

• Technology Evaluation and Assessment

• Information Services

Materials Science and Engineering

Laboratory

• Intelligent Processing of Materials

• Ceramics

• Materials Reliability'

• Polymers

• Metallurgy

• Reactor Radiation

Chemical Science and Technology

Laboratory

• Biotechnology

• Chemical Kinetics and Thermodynamics

• Analytical Chemical Research

• Process Measurements^

• Surface and Microanalysis Science

• Thermophysics^

Physics Laboratory

• Electron and Optical Physics

• Atomic Physics

• Molecular Physics

• Radiometric Physics

• Quantum Metrology

• Ionizing Radiation

• Time and Frequency'

• Quantum Physics'

Manufacturing Engineering Laboratory

• Precision Engineering

• Automated Production Technology

• Intelligent Systems

• Manufacturing Systems Integration

• Fabrication Technology

Electronics and Electrical Engineering

Laboratory

• Microelectronics

• Law Enforcement Standards

• Electricity

• Semiconductor Electronics

• Electromagnetic Fields'

• Electromagnetic Technology'

• Optoelectronics'

Building and Fire Research Laboratory

• Structures

• Building Materials

• Building Environment

• Fire Safety

• Fire Science

Computer Systems Laboratory

• Office of Enterprise Integration

• Information Systems Engineering

• Systems and Software Technology

• Computer Security

• Systems and Network Architecture

• Advanced Systems

Computing and Applied Mathematics

Laboratory

• Applied and Computational Mathematics^

• Statistical Engineering^

• Scientific Computing Environments^

• Computer Services

• Computer Systems and Communications^

• Information Systems

'At Boulder, CO 80303. ^Some elements at Boulder, CO 80303.
NIST Special Publication 500-228

Guidelines for the Evaluation

of X.500 Directory Products

John Tebbutt

Systems and Network Architecture Division

Computer Systems Laboratory

National Institute of Standards and Technology

Gaithersburg, MD 20899-0001

Funding for this document was provided by

the Department of Agriculture

May 1995

U.S. Department of Commerce

Ronald H. Brown, Secretary

Technology Administration

Mary L. Good, Under Secretary for Technology

National Institute of Standards and I^hnology

Arati Prabhakar, Director
Reports on Computer Systems Technology

The National Institute of Standards and Technology (NIST) has a unique responsibility for computer

systems technology within the Federal government. NIST's Computer Systems Laboratory (CSL) develops standards and guidelines, provides technical assistance, and conducts research for computers and

related telecommunications systems to achieve more effective utilization of Federal information technology resources. CSL's responsibilities include development of technical, management, physical, and administrative standards and guidelines for the cost-effective security and privacy of sensitive unclassified

information processed in Federal computers. CSL assists agencies in developing security plans and in improving computer security awareness training. This Special Publication 500 series reports CSL re- search and guidelines to Federal agencies as well as to organizations in industry, government, and

academia.

National Institute of Standards and Technology Special Publication 500-228

Natl. Inst. Stand. Technol. Spec. Publ. 500-228, 69 pages (May 1995)

CODEN: NSPUE2

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1995

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402
Contents

1 Introduction 1

1.1 Acknowledgments 2

2 An Introduction to X.500(1904) 3

2.1 Overview 3

2.1.1 What is the X.500 Directory ? 3

2.1.2 How does the Directory work? 4

2.1.3 About this tutorial 5

2.1.4 Tutorial Objective and Constraints . 6

2.2 Entries 6

2.2.1 Object Entries 6

2.2.2 Alias Entries 7 2.2.3 Subentries 8

2.2.4 Entry Collections 8

2.3 Attributes 8

2.3.1 Attribute Type 8

2.3.2 Attribute Values 8

2.3.3 Matching Rules 8

2.3.4 Attribute Type Hierarchies 9

2.3.5 Collective Attributes 10

2.4 Object Classes 10

2.4.1 Entry Attributes 11

2.4.2 Entry Position 11

2.4.3 Administrative Policy 11

2.4.4 Object Class Inheritance 11

2.4.5 Types of Object Class 12

2.5 The Directory Schema 13

2.5.1 Overview 13

2.5.2 Naming of Directory Entries 13

2.5.3 Directory Information Tree Structure Rules 15

2.5.4 Directory Information Tree Content Rules 16

2.6 Services 16

2.6.1 Read 18

2.6.2 Compare 18

2.6.3 List 19

2.6.4 Search 19

2.6.5 Add Entry 20

iii
2.6.6 Remove Entry 21

2.6.7 Modify Entry 21

2.6.8 Modify DN 21

2.6.9 Common Argimients 22

2.7 Distributed Operation 23

2.7.1 Relationship of DSAs to the Directory Information Tree 23

2.7.2 Knowledge 25

2.7.3 Knowledge and Efficiency 26

2.8 Security 27

2.8.1 User Authentication 27

2.8.2 Access Control 28

2.9 Operational Bindings 29

2.10 Replication 30

2.10.1 Shadowing and Caching 31

2.10.2 Shadow Operational Services 32

3 Functional Evaluation of X.600 3S

3.1 Mandatory Functions 33

3.1.1 Directory User Agents 33

3.1.2 Directory System Agents 35

3.2 Non- Standard Functions 43

3.2.1 Interoperability 43

3.2.2 Directory User Agents 45

3.2.3 Directory System Agents 53

4 Performance Evaluation of X.500 Products 67

4.1 Aspects of Directory Product Performjince 57

4.1.1 Heird Aspects of Directory Performance 58

4.1.2 Soft Aspects of Directory Performance 60

4.2 Performeince Ev£duation Methodology 61

iv
List of Figures

2.1 The Directory - Conceptual View 4

2.2 Various applications interface to the Directory via Directory User Agents 5 2.3 The structure of a Directory entry 7 2.4 The base attribute of the Address attribute hierarchy 9

2.5 The Address attribute hierarchy, showing three subtypes of the base type 9

2.6 The Address attribute hierarchy, showing subtypes o/ electronic madl address 10

2.7 The basic structure of the Directory Information Tree 14

2.8 An example of a Directory Information Tree 14

2.9 An example DIT showing different Naming Contexts 23

2.10 An example DIT showing the mapping of different naming contexts into administrative domains 24

2.11 An example DSA configuration showing the knowledge references associated with the

DIT structure 25

2.12 An example showing shadowing of a fragment of the Directory information Tree. . . 31

3.1 Interoperability in the X.500 Directory 44

3.2 An example of a menu-based editor for Common Arguments 46

3.3 An example of a windows-based Search Filter Editor 50

3.4 An example of an operation template for a Name-based Search operation 51

3.5 An example of a plain language error notification 52

3.6 Schematic representation of a DSA front-ending to a conventional Relational Database

Management System 55

V

Chapter 1

Introduction

This document provides readers with the meims to evsJuate various X.500 products and make

informed choices as to which available products best match the reqmrements of their organizations.

This document is aimed at procurement officials, systems administration staff and others involved

in the process of obtaining or recommending X.500 products for use in their organizations.

At the time of writing, the 1994 Edition of the X.500/Directory standard, Reference [1], has been

finalized, and a nimiber of 1994 conformemt products should be driving in the msirketplace within

the foreseeable future (though few if any are currently avedlable).

At the s£ime time, the requirement for a standardized, intelligent, distributed database system is increasingly being felt in organizations large and small. The initial requirement is usually for a name-to-address mapping tool for X.400 electronic m«dl, but as new applications continue to be

deployed, such as Electronic Data Interchange (EDI), the Directory is rapidly becoming a pivotal

information storage and retrieved medium.

Given that an organization has identified the need for some X.500/Directory functionzJity, in the

form of clients and/or servers, the question becomes one of how best to select a product (or

combination of products) which offers an array of features which best match the organization's

requirements.

This document has the following structure. In Chapter 2 a brief tutoried on the X.500/Directory

standcird is presented, the purpose of which is to introduce the various terms and concepts associated

with the Directory. Directory entries and their structure are described, followed by the hiereirchical

organization of the Directory information, and the rules governing this organization (the Directory

Schema); the distributed operation of the Directory is outlined; finally, security models and the

replication of Directory information are described.

Chapter 3 is entitled "Functional EveJuation of X.500"and contedns two broad sections. Section

3.1 details a list of standard Directory functions that a purchaser should require of any Directory

product, since they axe mcindated in the Directory stfindard. Such functions range from the obvious

(e.g., does the product enable the user to perform a read operation) to the less obvious (e.g., does

the product enable the user to specify that replicated information is imsatisfactory in response

to a given operation). In short, this section deeds with the product's conformance to the X.500

standard (Reference [1]) eind related docimients, such as the Industry/ Government Open Systems

1
Specification (IGOSS) (Reference [11]) and the Stable Implementation Agreements from the Open

Systems Environment Implementors' Workshop (OIW) (Reference [12]).

A product may conform to the letter of a standard and amy associated implementor agreements,

Application Progrsimming Interfaces (APIs), etc., yet still be cumbersome to use, time consimiing

to master, and resource-intensive in maintenance and administration, to name just a few potential

pitfalls. Section 3.2 suggests a list of features which, while not mandated in any standard, aie

desirable in a Directory product simply because they increase the ease of use, mainteucince, etc., of

the product, and thus increase its overaill usefulness.

Chapter 4 details how to apply the information set out in the Functional Evaluation Chapter in a practical assessment of an X.500 product, and contains some suggestions as to how to decide on which aspects of the X.500/Directory system are importzint to the organization in question. In

Chapter 4 a measure methodology is developed which enables a meeiningful compeirison between

products, and thus permits the user to firrive at an informed decision as to which product to select. This section is entitled "Performance Evaluation of X.500 Products."

1.1 Acknowledgments

The author wishes to thank Csirol A. Edgair of the National Institute of Standards and Technology

who assisted in the editing and the preparation of the text for publication. Miss Edgar's unfailing

support in both the technical and editorial review of this document was extremely helpful.
Chapter 2

An Introduction to X.500(1994)

2.1 Overview

2.1.1 What is the X.500 Directory ?

In essence the Directory^ is a distributed database, capable of storing information about people sind

objects in veirious nodes or servers distributed across a network. It is these servers, acting in concert,

which provide the potentially global access to information made possible by X.500 technology (see

fig. 2.1).

Distributing information in this manner has various advantages over the conventional method of

centralizing information storage, for example:

• The information is kept "close" to those people or processes which are most likely to make

most frequent use of it aind are most likely to be responsible for keeping it up-to-date - this

is likely to reduce access time find network costs, and increase the likelihood of the accuracy

of the stored information;

• Since the information is distributed across several (possibly hundreds, thousands, or even more) servers, the impact of a given server becoming inactive, for whatever reason, is only to make imavailable the information for which that server is responsible, rather thsin bringing

down the entire database, as would be the case if a centredized server were to go down;

• The Directory has the capacity to grow indefinitely in size find storage capacity through the

simple addition of new nodes. Such growth might be achievable but would be less practical

with a centralized system;

• The Directory offers the opportunity to unify information resources across the globe, as opposed to the insularity which tends to occiu: when orgeinizations rely on proprietary, cen- tralized databases.

The physical location of the accessed information is transparent to the user. The Directory possesses

the necessary knowledge to locate requested information, reg£irdless of where the information might

^Throughout this text the teims "X.500" and "The Directory" will be used synonymously.

3
Figure 2.1: The Directory - Conceptual View.

be on the network. To access the Directory, the user will usually interface to the server closest to him/her, and all information received will usually appeeir as if it came directly from that server. Prom the user's point of view, the Directory behaves exactly as if the user was accessing a centrsdized

server.'^

2.1.2 How does the Directory work?

The Directory user (person or process) accesses the Directory via a client process known as a

Directory User Agent, or DUA (see fig. 2.2). The DUA interfaces with the Directory using a standard protocol between itself and one of the Directory servers, termed Directory System Agents,

or DSAs. Usually the DSA contacted would be the one closest, in terms of connection cost or organizational tiffiliation, to the Directory User Agent.

The DSAs making up the Directory ailso commimicate via a standard protocol which embodies a

set of operations which may be performed by the Directory (e.g., retrieving information, adding

information, etc.). Each DSA knows how to contact one or more additional DSAs (at least one).

This is the mechanism through which a Directory request can be propagated through the system:

if a pjirticuleir DSA is unable to satisfy a request, the request is forwarded to another DSA which

is more likely to have the necessary information, and so on.

^It is envisioned that most Directory users will not be people, but application processes. Nevertheless, the uniform

interface provided by the Directory is still desirable

4
Figure 2.2: Various applications interface to the Directory via Directory User Agents.

2.1.3 About this tutorial

The tutorial provides fin introduction to the following aspects of X.500:

• Entries. The imiversfJ unit of information storage in the Directory.

• Attributes. The constituent elements of entries.

• Object Classes. An identifier signifying the class of entries to which a given entry belongs.

Entries are grouped into classes on the basis of shfired properties.

• Schema. The set of rules and assertions governing where ajo. entry may be placed within the

Directory, how it shall be neimed, and what information it may contsdn.

• Services. The set of services which enable the user to manipulate information held by the

Directory.

• Distributed Operation. The mechanisms by which multiple septate servers are linked

together to form a single Directory entity.

• Seciurity. The methods by which the Directory protects the information it holds from unauthorized access.

• Replication. The meeins by which information held by a DSA may be copied to one or more

other DSAs in order to increase efficiency and decrease access time.

• Operational Bindings. Bilatered agreements made between DSAs to provide various ser- vices to one ainother. These agreements fire usually used for the creation find administration

of Shadowing agreements.

5
2.1.4 Tutorial Objective and Constraints

1. The aim of this tutorial is to give a good working knowledge of the principles of the Directory - there is no emphasis on technical details, though references to the Standard docimient are given when appropriate.

2. It is impossible, in a brief tutoriaJ such as this, to cover in detail aU the material emd concepts

presented in the X.500(1994) Stemdard. The Standard document itself approaches the thick- ness of a telephone book! For greater detail, it is suggested the reader considt the Standard

itself, Reference [1]. Also, there are a variety of commercially available texts which cover the

material in greater depth.

3. This tutorial will be published both sep£irately as a self-contained tutorial and as part of

NIST's X.500 Evaluation Criit(2e/me« publication.

2.2 Entries

The entry is the fundamental xmit of information in the Directory. That is to say, £ill information

stored in the Directory is stored ia the form of entries, each of which is uniquely Ueimed and

represents one of three things:

1. An object in the real world - the bulk of the entries in the Directory are of this type, termed an object entry]

2. An alternative name for bld. object entry. This type of entry is termed £in alias entry, and is also uniquely named; or

3. A collection of information used to meet administrative needs of the Directory. Such an entry

is termed a subentry.

The unique neiming of entries is described ia Section 2.5.

2.2.1 Object Entries

Typically, when the term "entry" or "Directory entry" is used, it refers to an object entry, though

all entries are structured in the same manner.

All Directory entries are made up of a collection of attributes (described ia sec. 2.3), each of which

describes a peirticular quality or aspect of the object represented by the entry. Figure 2.3 displays a schematic of an object entry together with some of its constituent attributes and their associated

values. The figure represents a hypothetical object entry which has an attribute of type Telephone

Number with a wahie of 303-498 1633, indicating that the real world person ia question has the

telephone number 303-498 1633. In this regard, £in entry may be likened to a database record, and

ein attribute to a field of that record.

Initieilly it was envisioned that the entries in the Directory would contsdn information relating

largely to data commimications devices and applications, but increasingly it is being thought of as

6
Attributes

Entry

Type

Common Name

Value

Ronald A. Lester

Telephone Number 303-498 1633

E-mail Address rlester@usda.gov

/G=Ron/S=Lester/0=USDA/C=US

Street Address United States Department of

Agriculture 3825 E. Mulberry Street Fort Collins Colorado, 80524

Figure 2.3: The structure of a Directory entry.

a general purpose repository for all kinds of information, ranging from personnel records through

automotive parts inventories to on-line telephone directories and database services. That having

been said, it seems that the most import£int role for X.500 in the forseeable future is as an enabling

technology for data commtmications, especially electronic mail.

2.2.2 Alias Entries

An alias entry contains only one user attribute, the VfJue of which is the xmique name of an object

entry. Alias entries are thus used to provide alternative names for object entries. This can be useful

in the case when the actual name of an entry is cumbersomely long. The use of aliases will become

clecirer in Section 2.5 on the Directory Schema.

When an sJias entry is encoimtered by one of the Directory services (decribed in sec. 2.6) as the

name of an entry, the aliasedEntryName attribute is read, the target object of the operation is reset to the name it contains, and processing continues as if the aliasedEntryNtime had been supplied as the originid entry name to the service. This process is known as alias dereferencing.

Aliases may point to object entries or other alias entries, but they must edways be leaf entries, i.e., they are not permitted to have subordinate entries.

7
2.2.3 Subentries

A subentry is used for internal administration within the Directory architecture. It contziins information used by the Directory in various administrative functions. For example, collective attributes,

described in Section 2.3, are stored in subentries, along with accounting and access control information for the entries in the vicinity of the subentry.

2.2.4 Entry Collections

An entry collection may be formed when any set of entries shaxe properties or characteristics in

common. Usually when this is the case, the common information may be stored once in a collective

attribute (see sec. 2.3) rather than being stored many times, once in each individual entry.

2.3 Attributes

The Directory Staindeird specifies and defines a set of commonly used attribute types which c£in be

augmented by various implementor bodies, by vendors or by users. The mecheinism for attribute

definition is the ATTRIBUTE information object class, which is given in Clause 12.4.6 of Reference

[3]. The Directory attribute holds information regarding a pjirticulair quality or characteristic of an

object represented by a Directory entry, and has two principal components: a type indicator, and

a set of values. Figure 2.3 in Section 2.2 shows how attribute types and values are combined into a Directory entry. Also associated with each attribute are a set of matching rules, which indicate

whether the attribute is to have a single or multiple values. The attribute may also contain

administrative data.

2.3.1 Attribute Type

The attribute type is a unique identifier which has both a semantic and a syntactic function. The

semantic function is to indicate what purpose the information contfiined in the attribute serves. For example, is it a telephone nimiber, a network address, a social security nimiber, a nickname,

eind so on. The syntactic function is to indicate how the attribute value should be parsed in order

to accurately retrieve the information it contains.

2.3.2 Attribute Values

The attribute value is where the attribute's information is held. As mentioned above, the parsing

and interpretation of the attribute value is determined by the attribute type.

2.3.3 Matching Rules

Each attribute has associated with it a set of matching rides which determine how values of the

attribute may be matched against other values. For ex£imple, an entry may be of interest if it has

8
an attribute representing a telephone number, one of whose values is equal to 301-555 8937. In

this case, it would be desirable to permit the comparison of telephone number attribute values for equality with presented values. Such a comptirison is dictated by the equality matching rule for the attribute in question. The other matching rules which may be included in the attribute are

rules for ordering matchy to determine whether a stored quantity is greater or less than a presented

quantity; and substrings match, which enables presented substrings to be picked out of stored string

values.

2.3.4 Attribute Type Hierarchies

When defining attributes in the Directory, it is possible, though not necesseiry, to create an attribute

hierarchy, by defining groups of attributes of a genertd nature and then defining subtypes of these

attributes to hold more refined or detailed information of a similar natxire. These latter attribute

types can, in turn, serve as super types for another level of attribute sub-typing.

As an example, suppose we define an extremely genercJ attribute type, which we caU Address (see

fig. 2.4).

address

Figure 2.4: The base attribute of the Address attribute hierarchy.

Address can mean virtuedly any point of contact with some person or entity, and we reflect this

by creating several subtypes of our base attribute: Postal Address, Electronic Mail Address, and

Telephone Number. Thus we have a two tier hierarchy, as shown in Figure 2.5.

Figure 2.5: The Address attribute hierarchy, showing three subtypes of the base type.

Of course, each of the three subtypes is also fairly genersil, for example, we might wish to define

individual attribute subtypes under Electronic Mail Address for X.4OO Address, Simple Mail Transport Protocol (SMTP) Address and cc:Mail Address, which leads to the three tier hierarchy shown

in Figure 2.6. The useful aspect of attribute type hierarchies is that they offer the opportunity to examine Directory information at different levels of detail. When an attribute type is requested in an information

retrievjil request,^ attributes of that type together with all its subtypes aie returned. Thus, in om

example, if the attribute type Address is requested, the Directory wiU return aU attributes of types

'Information retrieval services are discussed in Section 2.6

9
Figure 2.6: The Address attribute hierarchy, showing subtypes of electronic mail address.

Address, Postal Address, Electronic Mail Address, Telephone Number, X.4OO Address, SMTP Address and cc:Mail Address. If Electronic Mail Address is requested, all attributes of types Electronic

Mail Address, X.4OO Address, SMTP Address and cc:Mail Address will be returned. And finzdly,

if only attributes of type X.4OO Address are desired, that is the attribute type which shoidd be

specified in the information retrieval request.

,2.3.5 Collective Attributes

Collective attributes serve as repositories for information common to £ill entries in £in entry collection

(see sec. 2.2). For exeimple, if aH entries in a group share the s£ime telephone number (as may

be the case for the members of a household), the information might be stored in a collective

attribute residing in a Directory subentry close to the object entries making up the entry collection.

One advantage of storing information in this way is that, if it becomes necessary to change the

information, this need be done only once for all the members of the collective, rather than once for

each member.

The information held in collective attributes appesirs as if it is part of the information held in any

entry in the entry collection when that entry is retrieved using any of the Directory interrogation

services, but modification must take place through the subentry where the information is actually

held.

2.4 Object Classes

Directory object classes are used principsJly to distinguish between entries representing different

types of objects. Each Directory entry must belong to at least one object class, eind contain an

attribute, the V£ilue(s) of which indicate(s) the object class(es) to which the entry belongs. Following

from this descriptive function, the entry's object class serves severed specific functions within the

Directory:

• It governs the attributes the entry contains (see sec. 2.4.1);

10
• It governs the position the entry may take in the Directory structure (see sec. 2.4.2); and

• It governs the administrative policy associated with the entry (see sec. 2.4.3).

As is the case for Directory attributes, object classes may be defined in international standards, by

other stfindards or implementor bodies, by vendors, or by users. The mechanism for object class definition is described in Clause 12.3.3 of Reference [3].

2.4.1 Entry Attributes

The object class of an entry dictates which attributes the entry may contain.* In fact, it specifies a set of attributes the entry must contiiin, along with a further set which the entry may contain.

No additional attributes £ire permitted. See Section 2.4.5 for additional information on object class types and entry composition.

As axL exzunple, suppose we define an object class. Used Car, to represent a used car. We might

conclude that certeiin information about a vehicle was indispensable in entries of this object class, so we would insist that they MUST CONTAIN attributes indicating the cm's Make/Model, Year

of Manufacture and Original Mileage. On the other hiind, there £ire several attributes the car might

have which we consider of lesser importance, but nonetheless desirable, so we stipulate that entries

of this object class MAY CONTAIN attributes indicating the vehicle's color, engine size, list of

options, availability of service record, and so on. We have now described the composition of entries

used in the Directory to describe used cars.

2.4.2 Entry Position

The object class identifier attribute of the entry is used by the Directory to ensure that the entry is not placed inappropriately within the Directory database. The structure of the Directory database

eind the placement of entries therein is described in Section 2.5.

2.4.3 Administrative Policy

Various aspects of administrative policy may be associated only with entries of particular object

classes. The Directory Administrative Model is described in Clause 4 of Reference [3].

2.4.4 Object Class Inheritance

Object classes may be created by decleiring them to be subclasses of existing object classes. In this case, the new object class inherits aU the attributes of an existing object class, its superclass, and

has the opportimity to add further attributes.

To extend our example above, suppose we have an organization, Dave's Used Cars, for which the

existing Used Car object class is useful but not sufficient. A new object class, Dave's Used Car,

may be derived from the existing one by declaring it a SUBCLASS OF Used Car, and further

*See also Section 2.5 for the influence of Directory Content Rules on the contents of entries.

11
stipulating that it MUST CONTAIN attributes indicating, say, a local stock number and date of

arrival, and that it MAY CONTAIN attributes indicating the vehicle's source and perhaps blue

book value. Thus, entries of object class Dave's Used Cm will contain all the attributes of the

Used Car object class, plus those additioneilly specified by Dave.

Each entry in the Directory must contain an attribute indicating the object classes to which it belongs. This is because, by definition, each object class is a subclass of a special object class known simply as top, which indicates that all attributes MUST CONTAIN such an attribute.

This attribute holds the unique object class identifier for the object class to which the entry belongs,

in addition to the corresponding identifiers for all the entry's superclasses. Thus, an entry belonging

to a given class also belongs to all the superclasses of that class. This set of superclasses, from the

entry up to top, is know as the object class' superclass chain.

Returning to our example, an entry of class Dave's Used Car also belongs to class Used Car,

and so on, back up the chain of whatever superclasses Used Car might have.

One important effect of this object class inheritance is that if an information retrieval request is made based on the object class of the entry, all entries of that class and all its subclasses will be

returned.

2.4.5 Types of Object Class

Object classes may be subdivided into three types: abstract, structural, and auxiliary. So far, this

section focused on structurjil object classes. The two other classes can be stunmarized as follows:

2.4.5.1 Abstract Object Class

An abstract object class is an object class which is defined purely for the purpose of serving as a

superclass or template for other (structured) object classes. It is a way of conveniently collecting

together a set of attributes which it is known wiU be common to a set of structural object classes,

in order that these classes may be derived as subclasses of the abstract class rather than being

defined from scratch. For example, an abstract object class Person can be defined with address,

phone nimiber. Date of Birth (DOB), etc., things everyone has. Then it is possible to subclass a structural object class like NISTPerson, with additional attributes of grade, s£ileiry, personnel

number, etc.

Note that an entry may not belong to an abstract object class.

2.4.5.2 Auxiliary Object Class

Each entry, while belonging to only a single structural object class, may belong to zero or more

auxiliary object classes. Auxiliary object classes serve as a means to provide multiple inheritance to Directory entries, that is to say, to combine the attributes from two or more superclass cheiins into a single entry. This is useful in the case where a common group of attributes is desired in entries

from various object class hierarchies. For example, the attributes of an object class Bank Account

Holder might be included into entries of structural object classes as varied as Residential Person,

Personnel Manager, Business Organization and Government Department.

12
2.5 The Directory Schema

2.5.1 Overview

The Directory Schema constitutes the £r£miework within which Directory information is stored. It consists of a set of rules and definitions which define the naming of entries, the content of attributes

£ind entries, the structure of the Directory as a whole, eind the hierairchic£j relationships between

entries.

The Schema comprises the following components (in accordance with Recommendation X.501

Clause 12.2, Reference [3]):

• Name Form definitions, which describe how Directory entries should be named;

• Directory Information Tree (DIT) Structure Rules, which define hierarchical relationships between entries of different object classes;

• Content Rule definitions, which allow the inclusion in entries of attributes not indicated in

the entries' structural object classes;

• Object Class definitions - see Section 2.4;

• Attribute Type definitions - see Section 2.3; £ind

• Matching Rule definitions - see Section 2.3.

2.5.2 Naming of Directory Entries

2.5.2.1 Directory Names

Each entry in the Directory is identified by at least one^ unique nsune, csiUed the entry's Distinguished Name or DN. The DN is formed in the following fashion:

1. The Directory Information Base (DEB) is organized into a tree-shaped hierarchy, the DIT,

in which each entry has exactly one superior entry but may have mfiny subordinate entries.

This organization is illustrated in Figure 2.7.

Clearly, each superior entry may have many subordinates, so the entry may be one of many

siblings at the same level in the tree.

2. Each entry contains at least one attribute value which is designated as the entry's nzime

at that level, i.e., relative to eiU its siblings. This name, known as the entry's Relative

Distinguished Name or RDN, must be unique among all the entry's siblings. There are times when it is necessary to select more than one attribute veilue in order to distinguish

between siblings, and other times when it is desirable to select more than one attribute yahie

for the sake of cleirity:

Siurname : Lester OR Surname : Lester, Given Name : Ronald

'Aliases may be used to piovide alternative names.

13
Figure 2.7: The basic structure of the Directory Information Tree.

3. The unique name of the entry, its Distinguished Name or DN, is formed by the concatenation of the RDN of the entry with those of each of its superiors, from the top of the DIT

on down to the entry.

'Organization

Government ^

f Org. Unit 1 USDA

f Org. Unit

NIST ,

[ Org. Unit

]

i DHHS J

Name

Lester, Ron

Name

~

Tebbutt, John

Name

Trus, Steve

Name

Cooley, Bob

Figure 2.8: An example of a Directory Information Tree.

The following example applies these niles to the hypothetical DIT three levels deep shown in Figure

2.8. The exeimple concerns the n£iming of organizations, orgainizationed tmits, and people connected

with those orgemizationeJ units.

The example contciins eight entries, each with its own Distinguished Name:

1. /Organization (0) = Government

2. /O = Government/Organizational Unit (OU) = USDA

3. /O = Government/OU = NIST

14
4. 10 = Government/OU = DHHS

5. 10 = Government/OU = USDA/Name (CN, for "Common Name")

6. 10 = Government/OU = NIST/CN = Tebbutt, John

7. 10 = Government/OU =: NIST/CN = Trus, Steve

8. 10 = Government/OU = DHHS/CN =: Cooley, Bob

This exctmple also illustrates the use of three standard attributes commonly used for the naming of

entries: Organization Neune (O), Organizational Unit Name (OU) and Common Name (CN). These

attributes, together with the other standard attributes (i.e., those defined by the X.500 Stfindard,

specifically Recommendation X.520), can be fotmd in Reference [7].

2.6.2.2 Name Form Definition

A Name Form specifies which attribute types within an object class may form pjirt of the RDN of

entries belonging to that class. This carries the implication that there may be certain attributes

in an entry which should not be used as part of that entry's RDN. For exiunple, in an entry

representing a person's health record, the use of the person's weight or last white blood cell count

as part of the RDN woidd in most cases be of little utility, whereas the use of the person's name,

patient niunber, Socied Security number, etc., would be a far more natural and practical choice.

The netme form definition is used to enforce such constrtdnts within the Directory.

Another implication of the name form definition is that at least one of the mzindatory attributes

of the object class must be specified as the naming attribute for the object class, if entries of that

class are to have names (which, of course, they must).

Note also that potentially several name forms may be defined for each object class, allowing for

entries belonging to that class to be named in different ways, according to their placement in the

DIT and the accompanying DIT structure rules (see sec. 2.5.3).

The formal method of Name Form Specification is given in Clause 12.6.3 of Reference [3].

2.5.3 Directory Information Tree Structure Rules

The placement of entries within a portion of the DIT is governed by rides set out by the responsible

authority, known as DIT Structure Rules. Each entry in the Directory contains fin attribute of Type

governingStructureRule, which holds the structure rule that governs the possible placement of

the entry. The entry may oidy be placed in a portion of the DIT if the Directory schema holds a DIT structiire rule which matches that held in the entry.

The DIT structtire rule consists of 3 psirts:

1. A unique identifier;

2. A naxae form identifier, which specifies the Ueime form that entries governed by this structure

rule will take;

15
3. A list of superior structiire rule identifiers, which denote where in the DIT the entry may be

placed, i.e., the classes of entry to which it is subordinate.

2.5.4 Directory Information Tree Content Rules

The content of an entry, in terms of the attributes it contains, is regulated primfiriiy by the entry's

structural and auxilifiry object classes (see sec. 2.4). However, additionsJ contents may be specified

by the definition of a DIT Content Rule associated with the entry's structural object class. A DIT content rule specifies the following (in accordiince with Reference [3], Clause 12.7.1):

• The identifier of the structural object class to which it applies;

• The identifiers of the axixiliary object classes permitted in entries governed by the rule (optioned);

• The identifiers of the mandatory attributes required for entries governed by the content rule,

in addition to those mandated in the structural and auxilifiry object classes (optional);

• The identifiers of the optional attributes required for entries governed by the content rule, in

addition to those neimed in the structural and auxiliary object classes (optional); and

• A list of identifiers of optional attributes from the entry's structural and auxilieiry object

classes which the content rule precludes from appearing in entries governed by the rule (optional).

Note that, imlike the characteristics of an object class, those of a DIT content rule Me not inherited

by any subclasses of the object class to which it applies.

The DIT content rules axe thus useful in the following ways:

• They permit the modification of an object class at a particular level in the object class hierarchy, while avoiding the inclusion of the modifications into the object class chedn;

• They permit the exclusion of certain optional attributes from entries of a given object class without modifying the object class itself; £ind

• They sillow the inclusion of individual attributes into entries, without reference to other object

classes.

2.6 Services

This section describes the set of services available to users of the Directory for the retrieval £ind

manipulation of Directory information. With these services, the user Cein retrieve information, add

new information, browse through the DIB, delete information and move information around within

the Directory Information Base.

16
Note that these services are performed on behfilf of the user^ by the Directory System Agents

(DSAs) which administer the Directory Information Base. Access to the Directory is via the

Directory User Agents (DUAs), which may present these services in a variety of ways, depending

upon the DUA product in use.

Protocols. Directory User Agents and DSAs communicate with each other using steindardized

communications protocols. The Directory Access Protocol, or DAP, is used by DUAs to communicate with DSAs, and vice versa. The more complex Directory Systems Protocol, or DSP, is used by DSAs to communicate with each other. It contains information not found in the

DAP, such as trace information, which enables DSAs to monitor the progress of an operation.

Application Contexts. An Application Context is a group of functions or operations required

in order to provide a ptirticular service or set of services. The Directory standard specifies several

Application Contexts. The directoryAccessAC Application Context describes the fonctioneility

necessMy to provide the services associated with the DAP, while the directorySystemAC Application Context acts in a similar fashion for the Directory System Protocol. The remaining

Application Contexts are concerned with Shadowing or Replication of data in the Directory, and

Directory Operational Binding Management.^

The outcome of a Directory operation takes one of three forms:

• Result. A Directory result contains either (a) the requested information from the indicated

entry or entries, in the case of the Read, List and Search operations, or (b) £in indication

of whether the operation was successful or not in the case of the rem«dning operations;

• Referral. If the DSA holding the teirget entry of the operation could not be reached for

some reason (e.g., the chainingProhibited service control was set), then £in indication of

the address of the DSA which is logicfilly the next closest to the tcirget entry's DSA is returned

to the Directory User Agent;

• Error. If the entry could not be located, a potential violation of the schema was detected, a

possible security breach was detected, or any of a number of other conditions prohibiting the

completion of the operation occurred, this is conveyed to the DUA in the form of a Directory

Error.®

The Directory offers the following basic services, each of which will subsequently be reviewed in

greater detail. It should be emphasized that, in isolation, these services provide only the building

blocks from which more sophisticated, value-added user services may be constructed.

• Read. Retrieve the information contained in an entry, as specified by its Distinguished Name;

• Compare. Compare a user-supplied attribute value against one held in an entry, as specified

by its Distinguished Nfime;

'Person or application process. ^See Sections 2.10 and 2.9 for more on Shadowing/Replication and Operational Bindings in the Directory. *See Reference [4] for a fuller explanation of Directory Errors.

17
• List. List the subordinate entries of an entry, as specified by its Distinguished Nsime;

• Search. Search through all the subordinate entries of an entry, as specified by its Distinguished Name, returning those entries which match specified criteria;

• Add Entry. Add a new entry to the Directory Information Base, specifying the new entry's

name and contents;

• Remove Entry. Delete an entry from the Directory Liformation Base, as specified by its Distinguished Name;

• Modify Entry. Modify the contents of a Directory entry, as specified by its Distinguished

Nsmae, specifying the desired modifications;

c Modify Distinguished Name. Change the Relative Distinguished Nsime of an entry, as specified by its Distinguished name, or move it to a new superior in the Directory Liformation

Tree, or both.

2.6.1 Read

Kusers know the DN of £in entry contfdning information they wish to retrieve, the Read service may

be used to obtain the entry's contents or a subset thereof. The user needs to specify the following:

• The DN of the entry;

• The parts of the entry to be retrieved. The user is able to select certain attributes or simply to request the entire contents of the entry. For example, a telephone directory application might

obtain John Smith's telephone number from his personnel record entry simply by requesting

his telephone number attribute (there is no reason for a telephone directory application to

retrieve the entire entry) while a personnel application would need access to the entire entry;®

• An optional request to the Directory to return the privileges she/he has to modify the entry

and its attributes. ^°

2.6.2 Compare

The Compare service is used to compare a value against an attribute vfilue in an entry whose name

the user knows. It returns a true or false response - true if the values matched, false if they didn't.

Such a service c£in be used for password checking applications or for other applications where the

creator or owner of a Directory entry does not wish to disclose information directly, but is willing

to confirm information to individujJs who eilready have access to it. The user specifies:

• The DN of the entry; «ind

• The value to be compared.

°In fact, the telephone application can be actively prevented horn retrieving information other than the telephone

number attribute using access control - this will be discussed in Section 2.8. ^°Thi8 is also tied into access control - see Section 2.8.

18
2.6.3 List

This service is used primarily to browse the Directory Information Tree. With it, a user can request a listing of the immediate subordinates of an entry, whose name she/he supplies. This process may

be repeated using the name of one of the subordinates returned, and so on. The user may thus

better pictorialize the part of the DIT in which she/he is interested. This process c£in also be used

as a primitive search function. For exfunple, if a user w£ints to look up Bob Walsh's project code,

and she/he knows Bob works in Accounts, but is not qmte sure of Bob's DN, she/he cam list out

the subordinates of the Accoimts Department's entry, and find Bob's entry that way. This service

requires the user to specify two items:

• The DN of the entry whose subordinates Me to be listed; and

• An optiontd indication as to whether the results are to be returned in a paged fashion.

2.6.4 Search

The most powerful of the Directory information retrieval services, Search, enables the user to extract from a portion of the DIB those entries which conform to a set of criteria she/he has specified,

returning selected information from each entry. In essence, the Search operation identifies a set of

entries which satisfy the user's requirements, and then reads each entry in much the same way as

is done by the Read service.

The sttirting point for the search is an entry whose DN the user supplies. The search criteria axe supplied in a standard logical format, using the operators AND, OR and NOT, £ind c£in be

grouped. They sJso depend on the matching rules discussed earlier (see sec. 2.3).^^

Returning to our earlier example of Dave's Used Car business, suppose that one of Dave's customers

is looking for a 1989 Corvette, but will settle for a Ceimaro, as long as it is a 1990 or newer model and

the price is less than $10,000. For the benefit of the Seeirch operation, these criteria are expressed

as follows:

((MAKE EQUAL TO Corvette) AND (YEAR EQUAL TO 1989))

OR

((MAKE EQUAL TO Camaro)

AND

(YEAR GREATER THAN 1989)

AND

(PRICE LESS THAN 10,000))

^^The means by which the user actually commumcates the search criteria to the Directory via the DUA will depend

upon the product in use, so it is only possible to describe the logical framework here.

19
Since both cars happen to be Chevrolets in this instance, the DN of the starting entry might look

something like:

/C=US/0=Dave'8 Used Car8/Category=Stock/Manufacturer=Chevrolet^^

The Search service allows the user to specify which attributes of the matched entries should be

returned, just as for the Read service (see sec. 2.6.1) so, to continue our example, Dave might pull

up the mileage and stock number of each car returned by the Search.

2.6.5 Add Entry

The Add Entry service allows the user to create a new entry in the Directory Information Base.

The new entry may only be created as a leaf entry, i.e., it must be added as a subordinate of an

existing leaf entry, as opposed to being inserted into the DIT between existing entries. Subordinate

entries to the new entry may be added later.

In order to create a new entry, the user should specify:

• The DN of the entry;

• The set of attributes which will make up the new entry (see sees. 2.2 and 2.3); and

• The DSA upon which the entry should reside, if this is different from the DSA holding the

entry's superior entry (see sec. 2.7 for more information on the distribution of information

between Directory System Agents).

The Directory performs a series of checks on the information in the Add Entry request:

• Does the superior entry exist?

• If so, does the user have the authority to create a new entry at this position in the DIT (see

sec. 2.8 for information on DIT Seciirity policy)?

• If so, is the new entry allowed as a subordinate to the superior entry, based on their respective

object classes?

• If so, are the attributes specified in the Add Entry request consistent with the supplied object

class £ind any applicable DIT Content Riiles?

• If so, the entry is added, otherwise the request is rejected.

The Add Entry service is the prim£iry meeins by which information is added to the Directory once

the initial bidk load is done.^'*

'^^For the sake of this example, Category and Manufacturer aie Object Classes assumed to have been created by Dave for the classification of the objects in his database. ^'The means by which the initial bulk load are done will depend on the particular X.500 product in use.

20
2.6.6 Remove Entry

In order to delete an entry from the DIB, the user employs the Remove Entry service of the

Directory. As with the Add Entry service, this service may only be applied to leaf entries of the

DIT - it is not possible to delete a non-leaf entry, leaving a number of prior subordinates dangling.

All that is required in order to delete an entry is the entry's DN. If the entry exists, is a leaf entry,

and the user has sufficient security access rights (see sec. 2.8 for information on DIT Security

policy), then the entry will be deleted.

2.6.7 Modify Entry

Information held in the Directory can be updated through use of the Modify Entry service. This

service may be applied to any entry in the DEB, subject to access control considerations (see sec. 2.8 for information on DIT Security policy), £ind permits multiple simuIt2ineous modifications to be made. The user must specify the following:

• The DN of the entry to be modified;

• The set of modifications to be made to the entry, which may comprise any number of the

following modification types:

— Add an attribute; — Delete an attribute; — Add one or more values to an existing attribute; — Delete one or more values from an existing attribute.

Note that the replacement of vedues in an attribute can be achieved by a combination of delete

value £ind add vjilue instructions in the same request. In fact, most user interfaces shotild hide this

entirely from the user and simply offer a Replace Value? option.

2.6.8 Modify DN

The Modify DN service is used to ch£inge the Distinguished Neime of a Directory entry. Since the

DN of an entry determines its position in the DIT, this service may be used either to change the

position of an entry in the DIT, or simply to change the RDN of the entry, leaving its position in

the DIT unaff"ected.

Two simple exeimples of the use of the Modify DN operation might be a name change:

/0=Accotmts

might become

/0=Accoimts and Finzmces

21
or a structural reorganization:

/0=GMC/Location=Detroit/0=Accounts

might become

/ 0=GMC/Location=Louisville/0=Accounts.

In order to employ this service, the following information is necessary:

• The original DN of the entry;

• The new RDN to be given to the entry, if the Distinguished Name is being changed;

• Whether the old RDN should be deleted; and

• The DN of the entry's new superior entry, if the entry is to be moved in the Directory

Information Tree.

Note that security and schema nile enforcement are carried out by the Directory, so that if the

renaming or repositioning of the entry woidd be in violation of these considerations, the operation

will not be cfirried out (see sees. 2.5 £ind 2.8).

2.6.9 Common Arguments

Each Directory operation carries with it a parameter set known as Common Arguments. The

elements making up the Common Arguments specify various elements of the operation request

which are relatively stable throughout the duration of a Directory interface session. They are

referred to as Common Arguments because they are common to all operations. Some of the

more important elements of the Common Arguments, from the user's point of view, are listed

here:

• Service Controls. The Service Controls element is itself a set of parameters which allow

the user to specify, for instance, whether information from a replicated copy of an entry will

suffice in lieu of information tfkken directly from the master copy; whether chaining between

DSAs is preferred or prohibited;^^ the priority of the request; the time limit within which

completion of the operation is required; the size limit of any operation response, and so on.

• Security Parameters. This element contains any security-related information connected

with the request.

• Requestor. This is the Distinguished Name of the originator of the Directory operation.

^*See Reference [4], Clause 7.3 for more on Common Arguments,

^'^see Section 2.7 for more on chaining.

22
2.7 Distributed Operation

So far in this text, mention has been made several times of the fact that the Directory is made up

of several Directory Systems Agents (DSAs), each of which holds a portion of the overall Directory

Information Base.^^ This section deals with how the DSAs cooperate with one another in order to provide users with transparent access to the data stored in the Directory Information Base.

2.7.1 Relationship of DSAs to the Directory Information Tree

Each DSA represents an Administrative Authority, which extends over one or more ptirts of the

Directory Information Tree. The individual pwts of the DIT which fall under the authority of a DSA are referred to as Naming Contexts.

2.7.1.1 Naming Contexts

Naming Context B

<||||) Object Entry Subentry Alias Entry

Figure 2.9: An example DIT showing different Naming Contexts.

The DIT can be broken up into subtrees,^^ each of which begins with a particular entry as its root

and contains all the subordinate entries of that entry, down to a certain level. Such a chunk of the

DIT is referred to as a naming context, and represents the way the DIT is broken up for storage in

the various DSAs comprising the Directory. Figure 2.9 illustrates how a Directory Information Tree

may be broken up into various naming contexts. Note that the lower limit of a naming context

may be made up of leaf or non-leaf entries. If one of the lowest level entries is a non-leaf, this

^'There is a degenetate case where all the data aie stoied in a single DSA, in which case the Diiectoiy becomes a

centralized, as opposed to a distributed, database, and the information in this section is not relevant. ^^A subtree is simply a branch of the Directory Information Tree.

23
implies that it has at least one subordinate entry, which must be in another naming context. Such

a neiming context is referred to as a subordinate naming context as a result, with the previous

naming context being referred to as its superior naming context. In Figure 2.9, contexts B and

C are subordinate to context A, which is their superior. The DN of the root entry of the naming

context is called the Context Prefix.

2.7.1.2 Relationships Between Directory System Agents

Figure 2.10: An example DIT showing the mapping of different naming contexts into administrative

domains.

The relationships between DSAs, and thus, between the Administrative Management Domains

(ADMDs) they represent are dictated by the relationships between the ntiming contexts they administer. It should be noted that any given DSA may administer any number of ntiming contexts

from anywhere in the DIT, but the root entry of each nztming context will usually have a superior entry in another naming context, which in turn wiU often reside on another Directory System

Agent. In such a situation, eind for that particidar neiming context, the DSA/ADMD holding

the superior nsiming context is said to be the superior DSA/ADMD, while that holding the subordinate naming context is described as the subordinate Directory System Agent /Administrative

Management Dom£iin. Figure 2.10 shows an exfimple DIT broken up into five ADMDs (i.e., spread

across five DSAs). In this exeimple, it cfin be seen that ADMD 1 is superior to ADMD 2, ADMD

3 and ADMD 5; ADMD 2 is superior to ADMD 3; and ADMD 5 is superior to ADMD 4. The

superior ADMD to ADMD 1 is not shown.

^'This applies to all naming contexts except the so-called "first level" or "root" naming context, which has the

abstract root of the entire DIT as its root. See Clause 17.3 of [3] for further detail.

24
2.7.2 Knowledge

The DSAs making up the Directory are able to function as a single unit because each one has at

least a Tninimum amount of knowledge about DSAs which hold external naming contexts. The

absolute minimum amotmt of knowledge a DSA must possess is the address of a DSA which holds a naming context which is superior to all the naming contexts held by the DSA, and the addresses

of all DSAs which hold naming contexts subordinate to those held by the Directory System Agent.

Thus, if a DSA is presented with a request concerning a Directory entry, it knows that it c£in either

process the request itself, because it holds the entry in one of its own naming contexts, or that

the entry exists in a nsiming context subordinate to one it holds, in which case it can forwjird the

request to a DSA responsible for a subordinate naming context or, if it has no idea where the entry

might be, as a last resort it can forward the request to a DSA holding a naming context nearer the root of the DIT, in the knowledge that the hierarchical iirrangement of the DIT wUl eventueJly

direct the request to the correct Directory System Agent.

ISR to superior... SR to B for <b> SR to C for <o

NSSR to C for «i> A

ISR to A for <a> CR to C for <d> A

y^\^NatniDg Context DSA <a> Naming Context ID

ISR = Immediate Superior Reference; SR = Subordinate Reference; NSSR = Non-SpeciGc Subordinate Reference; CR = Cross Reference.

Figure 2.11: An example DSA configuration showing the knowledge references associated with the

DIT structure.

The types of knowledge described above are known &s Superior (Knowledge) References sjid Subordinate (Knowledge) References, respectively. Other types of knowledge reference exist, which may

be used to enhance the distributed operation of the Directory:

• Immediate Superior Reference. This is a knowledge reference to a DSA which holds a naming context immediately superior to one held by the DSA, and can be used when the

DSA recognizes that the DN of the target entry of an operation matches part of the context

prefix of a naming context it holds, but is shorter;

25
• Non-Specific Subordinate Reference. This is a reference to a DSA which holds a naming

context subordinate to one held by the DSA, the context prefix of which is not known by the

DSA (in contrast, in a subordinate reference the context prefix of the subordinate naming

context is known). This type of reference is used in the same way as a subordinate reference;

• Cross Reference. This is a reference which may point to a DSA holding a neiming context

anywhere in the DIT, and is used to optimize the time taken to pinpoint an entry. For

instance, if a DSA frequently receives requests pertaining to entries in a particulzir naming

context which is neither subordinate nor superior to a naming context it holds, it my be wise

to set up a cross reference to the DSA holding the naming context in question, so that the

requests may be forweirded there immediately.

Figure 2.11 shows some knowledge references which might be associated with the mapping of an

example DIT onto three Directory System Agents. The DSA A holds naming context A, «ind thus

must hold Immediate Subordinate References to DSAs B and C, since they hold nsiming contexts

B and C, respectively, each of which is immediately subordinate to naming context A. The DSA A

eJso holds an Immediate Superior Reference to an imknown superior (unknown only because it is not shown in the example), eind a Non-Specific Subordinate Reference to DSA C for naming context

D. Of the references held by DSA A, only the last one, the Non-Specific Subordinate Reference, is optional, and will have been included to increase the efficiency of DIT traversal.

The DSAs B find C each hold Immediate Superior References to DSA A, since DSA A holds the

superior naming context to neiming contexts B and C, respectively. The DSAs B and C also hold

cross references to each other. These Cross References are optionzd, but they may increase Directory

efficiency by enabling each of these DSAs to bypass DSA A and pass information requests directly to one another for entries residing in nsiming contexts they hold. For example, if DSA C receives a

request relating to an entry which lies in naming context B, using the Cross Reference it can pass

the request directly to DSA B, whereas the alternative would be to pass the request up to DSA A

and rely on its knowledge of naming context B's location in order to complete the request. Clearly

this latter alternative would tend to increase resource utilization, error rates and processing time

for the request. Note that, since DSA B does not have a Cross Reference to DSA C for naming

context D, any requests it receives for entries lying in n£iming context D will be passed up through

DSA A. This emphasizes that a Knowledge Reference of any kind refers to a naming context as well as the DSA which administers it.

2.7.3 Knowledge and Efficiency

The retrieval of Directory information may involve the intercoimection of several Directory System

Agents. In such a chain of systems, each DSA will do some processing before initiating a connection

to the next DSA, and this process can be expected to be time consxmiing. Just how time consuming

it is depends on the quality of the commxmications links between the systems, the quality of the

remote systems themselves, along with the X.500 products in use at the remote sites, and to a Izirge

degree on the optimization of the local DSA configuration. With appropriate knowledge references,

the number of DSA-DSA hops can be minimized, and the processing time for a distributed operation

thus reduced. The inclusion of such knowledge references is a crucial part of the configuration of

the local DSA £ind adds greatly to the system's intelligence.

26
2.8 Security

Security in the Directory requires two separate components: authentication of Directory users to

verify their identity, and access control procedures to prevent unauthorized access to Directory

information. While security is of paramotmt importeince in the Directory, just as in any other open

application, discussion of this topic can become lengthy find involved and, since security policy

is not a topic xmique to the Directory, it will be given only a perfunctory overview here. For an

excellent and detailed explwation of authentication practices, the reader is referred to Reference [9], £ind for a thorough stmmiary of the access control methods available to Directory administrators,

see Clause 15 of Reference [3].

2.8.1 User Authentication

The pmrpose of user authentication is to verify the identity of a Directory user, so that access

to Directory information can be granted or denied with a high level of confidence that the user requesting the access is in fact who she/he claims to be.

Two authentication schemes are described for the Directory, Simple Authentication and Strong

Authentication.

2.8.1.1 Simple Authentication

The simple authentication procedure involves passing a user's name, in the form of the DN of the

user's Directory entry, £ind a password to the Directory. The Directory checks for an entry with the

supplied DN and, if such an entry exists, compeires the supplied password against the value stored

in the UserPassword attribute of the entry. H the value matches, the user is authenticated. This

method offers a minimum security approach, since neither the user's name nor the password are encrypted or encoded in any way.

Simple authentication can be made somewhat more secure by using a one-way hashing function on

the user's n£ime and password supplied to the Directory. This function involves the user's name,

password, time stamp, and a collection of reindom ntunbers.

2.8.1.2 Strong Authentication

The strong authentication scheme adopted by the Directory stfindard relies on the use of a publickey crjrptosystem, in which each user possesses two keys, one public and one private, the latter of

which is known only to the user. Each of these keys may be used to encipher or decipher the user's authentication information, in a complementary fashion (i.e., if the information was enciphered

with the private key, it must be deciphered with the public key, and vice versa). If a user's public

key is held by the Directory, then it can be used to confirm the user's identity if the user submits

his/her authentication information encrypted using his/her private key.

27
2.8.2 Access Control

In order to control access to Directory information, the DIB is viewed as a collection of protected

items:

• Entries;

• Attributes;

• Attribute Values; and

• Names.

Each protected item has associated with it a set of permissions, representing the access rights of

users, groups of users, or the general public. These permissions are further broken down on the

basis of the Directory operations.

The permission categories associated with entries (and nsimes) are:

• Read. The entry contents may be read only if the entry is explicitly named in the operation;

• Browse. The entry contents may be accessed without the entry being explicitly named in

the operation;

• Add. An entry may be created;

• Remove. The entry may be deleted;

• Modify. The contents of the entry maybe modified, provided that appropriate permissions

exist on the attribute and attribute vidue level;

• Rename. The entry's RDN may be changed;

• Disclose On Error. The entry's name may be disclosed if an error occurs;

• Export. Permits the entry to be moved to a new location in the DIT, using the ModifyDN

operation (see sec. 2.6);

• Import. Permits an entry to be removed from another location and placed in the location

where the permission applies; and

• Return Distinguished Name. Allows the DN of the entry to be disclosed in £in operation

result.

The permissions associated with attributes and attribute vsJues are slightly different than those for

entries:

• Compeure. Attributes and values may be compared to supplied vcdues;

^'See Section 2.6 for a list of the Directory operations.

28
• Read. The attribute or value may be returned in response to a read or search operation;

• FilterMatch. The attribute or value may be used in the evaluation of a search filter (see

sec. 2.6);

• Add. Permits the addition of an attribute or value;

• Remove. Permits the removed of an attribute with till its values, or the removal of a single

attribute value; and

• Disclose On Error. Permits the presence of an attribute or attribute vjJue to be disclosed

in case of error.

For each permission category, each protected item has £in indication of which users or groups of users possess that permission (or whether the permission is publicly avedlable). Thus, when a

user requests a pfirticidar operation, the Directory locates the protected item(s) in question and

ascertains whether the user has permission before cfirrying out the operation. If not, then the

operation is not carried out and a security error may be returned, depending on the disclosure

permission for the protected item in question.

2.9 Operational Bindings

An Operational Binding is the formalization of £in agreement between two Directory Administrations

for their respective DSAs to provide services to, or receive services from, one ainother on an exclusive

basis. The operational binding framework is deliberately left very general, so that it can serve as the frfimework for many different kinds of operational binding agreements which can be envisioned

in the future. For the time being; however, the principed use for operational bindings is the setting

up, modification and termination of Shadowing Agreements (see sec. 2.10).

An operational binding has the following key components:

• The two DSAs between which the binding will exist. The binding may be symmetric, with

each DSA providing the same set of services and having the same role in the management of

the operationsd binding, or asymmetric, in which case each DSA will provide different services

(e.g., as in the Shadow Supplier and Shadow Consimier in the Directory Replication model)

jind may have differing roles in the meinagement of the operational binding;

• An agreement describing the services the DSAs will provide to one another. This agreement

is made between the Administrative Authorities responsible for the DSAs involved, perhaps

as a legal contract or inter-organizationad memo;

• The set of Directory operations to be used by the DSAs involved to carry out the services

defined by the operational binding. These operations embody the content of the operational

binding agreement into a form which is readily machine ihterpretable and can thus be used as the basis for protocol exchfmges between the two DSAs within the context of the operational

binding;

• Operations for the msinagement of the operational binding, providing for its establishment,

modification and termination; and

29
• An identifier for the operational binding which is unique between the two DSAs, such that

this identifier, plus the names of the DSAs, constitute a globally iinique identifier for the

operational binding.

The Directory Standard (Reference [1]) establishes a fourth protocol, the Directory Operational

Binding Management Protocol, or DOP, to furnish Directory operations for the management of

operational bindings. The protocol defLaes operations for the establishment, modification and

termination of an operational binding.

To illustrate how operational bindings £tre used in the setting up of replication agreements between

DSAs (see sec. 2.10) suppose, in Figure 2.11 of Section 2.7, that an agreement was made between

the Administrative authorities responsible for DSAs B and C stating that DSA B should keep

a shadow copy of naming context D, to be updated at set intervals. Further suppose that the

meinagement of the operational binding itself is to be symmetriced, i.e., either DSA may establish,

terminate or modify any instance of the binding.

The operationfJ binding agreement is specified using the OPERATIONAL-BINDING information object class, as defined in Clause 23.3.1 of Reference [3]. This specification is referenced

whenever a DSA performs a management operation on the operational binding. The shadowing

agreement is brought into effect when either DSA establishes £in instfince of the operationjd binding

specified for it. Once in effect, the operations of the Directory Information Shadowing Protocol

(DISP) are used to carry out the functions associated with the shadowing agreement, until the

operational binding specifying the shadowing agreement is either modified or terminated by either

Directory System Agent. Thus the DOP eind the DISP are used in concert in order to define a shadowing agreement and carry out the operations necessary to mfdntain it.

2.10 Replication

Replication is a mechanism used within the Directory whereby information stored in one pMt

of the Directory may also be stored elsewhere as one or more copies. While this mechanism

is of minimum visibility to the Directory user, it has the advantages that it increases efficiency

of information retrieval «uid decreases response time to operation requests by placing frequently

accessed information "closer" to the user.

For example, in a situation where a pairticul«ir DSA is either heavily utilized or in a remote location

(perhaps Europe or Asia) or both, it may be advsintageous to make a copy of the DIT subtree we

are interested in on the remote system and import it to our local Directory System Agent. This

reduces the load on the remote DSA and improves the Directory's performeince from our point of

view, because our access to the data is much faster.

Replication also provides an extra degree of reliability find robustness to the Directory in that, if one of the systems holding a copy of an entry becomes inoperable, the information may still be

retrieved from einother system.

Replication cairries with it some potential pitfalls as well as advantages, in that the replicated

information may not be up-to-date, and inconsistencies may exist between the replicated data and

the master copy. How long these inconsistencies persist will depend on the replication agreement

that has been set up between the DSAs concerned - the copies may be updated immediately upon

30
update to the master, or periodiciilly, perhaps daily, weekly, etc. However, the user eJways has the

option to request information directly from the master copy, making the most cxirrent version of

the information available if necessary.

2.10.1 Shadowing and Caching

The Directory Standeird describes two kinds of replication, namely Shadowing axid Caching. Caching

encompasses any non-standardized method for replicating data. For instance, a Directory User

Agent (DUA) may simply make a copy of every entry that passes through it, and submit that copy

in response to a query about the entry, rather thjin contact the Directory to request the information. It is easy to see how DSA products might also do this with regard to entry information stored

in remote Directory System Agents.

Shadowing, the steindard form of replication, sets up replication agreements between DSAs specifying which peirts of the DIT aie to be replicated, how often copies are to be updated, whether the

copies, in part or in whole, may be copied out to other DSAs, the address of the DSA holding the

master copy, and so on. These agreements are set up via Directory Operational Bindings, which

are discussed in Section 2.9.

2.10.1.1 Shadowed Information

The replicated Directory information is always in the form of a contiguous subtree taken from

within a single naming context on the master DSA, known as the Shadow Supplier. The unit

of replication'^^ in shadowing is termed Shadowed Information, which encompasses the replicated

information (referred to as the replicated area) as weU as information about its origin, extent, etc. The shadowed information has three components:

Figure 2.12: An example showing shadowing of a fragment of the Directory Information Tree.

For the formal speciiacation of the unit of replication, see Clause 9.2 of Reference [10].

31
• Prefix information. Information regcurding the root entry of the replicated subtree, known

as the replication base entry,

• Area information. Information about the Directory entries contained in the replicated

£irea; and

• Subordinate information. References to naming contexts subordinate to the replicated

£irea.

In Figure 2.12, DSA 2 acts as a Shadow Supplier to DSA 3, the Shadow Consimier. The DSA 3

now maintjiins its own local copy of the Shadowed Information.

2.10.2 Shadow Operational Services

The updating of shadowed information is accomplished via three Directory operations which constitute the Directory Information Shadowing Protocol, or DISP: Coordinate Shadow Update, Request

Shadow Update and Update Shadow. Through these services, shadowed information can be updated

at the instigation of either the shadow supplier or shadow consiuner.

• Coordinate Shadow Update. This service is used by the shadow supplier to indicate

which shadowed information it intends to update, £ind how. It is issued in response to a

Request Shadow Update operation or subsequently to £ui Update Shadow operation;

• Request Shadow Update. This service is issued by the shadow consimier (i.e., the DSA

holding replicated information) in order to request an update of the shadowed information;

and

• Update Shadow. This service is used by the shadow supplier to send out updated shadow

information to a shadow consumer. It is invoked only after one of the previous services.

Each exchange CMries information about the shadowing agreement to which it refers, the type of

update to be performed (complete, incremental or no cheinge), and so on.

32
Chapter 3

Functional Evaluation of X.500

3.1 Mandatory Functions

In order to be considered a candidate for proctirement, an X.500 product must satisfy the criteria

set out in this section. These criteria eire derived &om the International Standfirds Organization

(ISO) 9594 set of stsuidards (technicedly aligned with the CCITT X.500 series of recommendations),

Reference [1], the Industry/ Government Opens Systems Specification, Reference [11], and the NIST

Stable Implemention Agreements for Open Systems Interconnection Protocols, Reference [12].

Since the Directory is composed of two distinct components, the Directory System Agents and the

Directory User Agents (DSAs emd DUAs), requirements for each type of component are set out

separately. The DSAs are further subdivided into all DSAs, Shadow Supplier DSAs and Shadow

Consimier Directory System Agents.

For each component, the requirements fall into three categories: Statement Requirements, which

describe the properties and capabilities of a product which must be stated by vendors; Static Requirements, which describe invMifint, mandatory operational requirements placed on the the product; and Dynamic Requirements, which describe operationfil requirements placed on the product

which may change according to clrcTmist£inces.

3.1.1 Directory User Agents

3.1.1.1 Statement Requirements for Directory User Agents

The manufacturer of a DUA product must state the following:

Which of the Directory Access Protocol operations conformance is claimed for; The authentication capability for which conformeince is claimed (none, simple or strong);

Which of the following extensions the DUA is capable of initiating and for which conformance is cledmed:

1. subentries. If this service control is set, then Search and List operations shfill access only

subentries. If not set, these operations shall access only normal entries;

33
2. copyShallDo. This service control indicates that a query need not be chained if it can be

partly satisfied from a local copy of an entry;

3. attributeSizeLimit. This service control indicates the majumum permissible size of ein attribute for it to be returned in response to a query. If an attribute exceeds this size, it is omitted from the result, and a flag indicating that the entry result is incomplete is set;

4. extraAttributes. This component of the EntrylnformationSelectiontype (used in Read

and Search requests to specify which information should be returned) is used to specify

additional user or operational attributes to be included in the result;

5. modifyRightsRequest. This component of the Read argument is used to request the

return of the requestor's modiflcation rights to the entry and its attributes;

6. pagedResultsRequest. This component of the List argument specifies whether results of

the operation are to be returned page by page;

7. matchedValuesOnly. This component of the Search eirgument specifies that attribute

values which did not not match specificidly with values in the sezirch filter shall not be

returned;

8. extendedFilter. This component of the Search argument specifies an eilternative se£irch

filter for use by 1994-conformjint systems;

9. target System. This component of the Add Entry argimient specifies the DSA which shfill hold the new entry;

10. useAliasOnUpdate. This describes a bit in the criticalExtensions element of CommonArguments, the set of eirguments common to all operations. If this bit it set, and

the dontDereferenceAlias element of CommonArguments is not set, £dias entries will

be dereferenced during the commission of an Add Entry operation; find

11. newSuperior. In a ModifyDN operation eirgument, this component specifies the name of an object entry in the DIT which is to become the new superior entry of the entry subject to the ModifyDN operation.

3.1.1.2 Static Requirements for Directory User Agents

The Static Reqidrements for DUAs are as follows:

Support for the Bind and Unbind operations is required;

The DUA product must be able to the support the directoryAccessAC application-context, as defined in Clause 7 of Reference [6]. This sets out the protocols and abstract syntjixes to be used

during a Directory Access session;

The DUA product must be able to hetndle the following errors: Abandoned, AbandonFailed,

AttributeError and NameError;

The product must be capable of heindling the extensions to which conformance was cledmed in

Section 3.1.1.1, and in any case where the product functions as an IGOSS Administrative DUA

2^ See Section 2.6.9.

34
(i.e., a DUA capable of supporting all DAP operations), the following extensions must be supported:

extraAttributes, subentries, newSuperior and useAliasOnUpdate;

The product must support the character set requirements set out in Part 11, Clause 7.1.1 of Refer- ence [12], i.e., T.61 String, PrintableString, NumericString and UNIVERSAL STRING;

The product must support None and ID-only/Simple Uncorroborated modes of authentication.

In the former method, no verification of the user's ID is carried out at £iU, while ID-only is the

simple passing of a user ID, which is checked via a compare operation by the DSA against a list of

legitimate users; and

The product shall have the capability to perform the normalization of protocol elements containing

the UTC Time element according to the rule specified in Part 11, Clause A.4.1 of Reference [12]. This process consists of filling in the seconds field with "00" whenever this field has been omitted,

and converting the string to the "Z" form.

3.1.1.S Dynamic Requirements for Directory User Agents

The DUA product must satisfy the following Dynamic Requirements as set out in Reference [6]: The product must conform to the mapping onto used services defined in Clause 8 of Reference [6]. This mandates the mappings between the X.500 services and those of the supporting Open Systems

Interconnection (OSI) services (Association Control Service Element (ACSE), Remote Operation

Service Element (ROSE), Presentation, Session, and so on); and

The product must conform to the rules of extensibility procedures defined in Clause 7.5.1 of Refer- ence [6]. These rules deal with the interoperation of products adhering to different versions of the

Directory standetrd.

3.1.2 Directory System Agents

3.1.2.1 Statement Requirements for Directory System Agents

The manufactxirer must state the following with regard to a DSA product:

The Application Contexts for which conformance is cleiimed: directoryAccessAC, directorySystemAC and directoryOperationalBindingManagementAC. If knowledge of a DSA has

been disseminated to other DSAs, then it shall claim conformeince to the directorySystemAC.

Conformance must be claimed at the Application Context level and sh«iU not be claimed to individufil operations;

The operational binding types for which conformance is cl£iimed: shadowOperationalBindingID,

specificHierarchicalBindingID, and non-specificHierarchicalBindingID;

Whether the DSA is capable of acting as a first level Directory System Agent;

If conformance is claimed to the directorySystemAC, whether or not the chsdned mode of operation is supported;

The security level(s) for which conformeince is claimed (none, simple, strong);

35
The selected attribute types, as defined in Reference [7], £ind any other attribute types, for which

conformfince is claimed and whether, for attributes based on the syntax DirectoryString, conformance is claimed for the UNIVERSAL STRING choice;^^

The operational attribute tjrpes defined in Reference [3] and any other operationail attribute types

for which conformjince is claimed;

The selected object classes, as defined in Reference [8], and any other object classes, for which

conformance is claimed;

The extensions listed in Table 1 of Clause 7.3.1 of Reference [4] that the DSA is capable of responding to for which conformance is claimed;

Whether conformjince is claimed for the return of alias names;

Whether conformance is claimed for indicating that returned information is complete;

Whether conformance is claimed for modifying the object class attribute to add and/or remove

values identifying auxilieiry object classes;

Whether conformaince is clsiimed to Basic Access Control;

Whether the DSA is capable of administering the subschema for its portion of the Directory Information Tree; The selected name bindings, and any other name bindings, for which conformance is clsdmed; and

In accordance with Reference [12], the DSA manufacturer shall state to which of the following

conformfince classes the product belongs:

• 0: Centralized Directory System Agent. Supports only the directoryAccessAC; or

• 1: Distributed Directory System Agent. The DSA shjJl implement all operations in the

Application Service Elements forming pMt of the Application Contexts for which it claims

conformance. The DSA shaH support the directoryAccessAC and may optionally support

the directorySystemAC.

3.1.2.2 Statement Requirements for Shadow Supplier Directory System Agents

In addition to the general statements described above, the meinufacturer of a DSA product claiming

conformance as a shadow supplier must state the following:

The application contexts for which conformance is claimed as a shadow supplier: shadowSupplierlnitiatedAC, shadowConsumerlnitiatedAC, reliableShadowSupplierlnitiatedAC, and

reliableShadowConsumerlnitiatedAC; and

To which degree the UnitOfReplication is supported. Specifically, which (if ciny) of the following

optional features aie supported:

• Entry filtering on Object Class;

^^It is a static reqixirement that all selected attribute types as defined in Clause 5 of Reference [7] should be

supported.

36
• Selection/Exclusion of attributes via AttributeSelection;

• The inclusion of subordinate knowledge in the replicated area; or

• The inclusion of extended knowledge in addition to subordinate knowledge.

3.1.2.3 Statement Requirements for Shadow Consumer Directory System Agents

In addition to the general statements described above, the manufacturer of a DSA product cl aiming

conformance as a shadow consumer must state the following:

The application contexts for which conformance is claimed as a shadow consumer: shadowSupplierlnitiatedAC, shadowConsumerlnitiatedAC, reliableShadowSupplierlnitiatedAC, and

reliableShadowConsumerlnitiatedAC;

Whether the DSA can act as a secondary shadow supplier; £ind

Whether the DSA supports shadowing of overlapping units of replication.

3.1.2.4 Static Requirements for Directory System Agents

In addition to the applicable Statement Requirements, every DSA package must satisfy the following

Static Requirements:

It must have the capability to support the application contexts for which conformance is claimed:

aU DSAs shall support directoryAccessAC or directorySystemAC or both;

It must have the capability to support the information framework defined by its abstract syntsix in

Reference [3];

It must conform to minimal knowledge requirements defined in Reference [3], i.e., each non-first

level DSA sheJl maintain a single superior reference; each DSA that is the master DSA for a naming

context shall maintain subordinate or non-specific subordinate references to DSAs holding naming

contexts immediately subordinate to that naming context;

If conformance is cledmed as a first-level DSA, the product must conform to the requirements for

support of the root context; The DSA must have the capability to support the attribute types for which conformance is claimed,

as defined by their abstract syntaxes, eind in any case shall support the selected attribute types

defined in Reference [7] find their associated attribute syntaxes;

It must have the capability to support the object classes for which conformaince is claimed, and in

any case the DSA shall support all selected object classes defined in Reference [8]; The DSA shaU support all matching rules defined in Clause 7 of Reference [7]; The product must conform to the extensions for which conformance was claimed;

If the capability to administer subschema, as defined in Reference [3], is dfdmed, the DSA shaR be

able to do this administration;

37
The DSA shall support collective attributes, and must have the capability to perform the related

procedures, as outlined in Reference [4]; The DSA shall support hierarchical attributes, and must have the capability to perform related

procedures, as outlined in Reference [4]; The DSA must have the capability to support the operational attribute types for which conformance

is claimed;

If conformeince is claimed to Basic Access Control, the DSA must have the capability to hold Access

Control Information ( ACI) items conforming to the definitions of Basic Access Control;

The DSA shall support Simplified Access Control (SAC). A class 2 subtree specification, as described in Part 11, Clause 8.10 of Reference [12] shall be supported;

The DSA shall support operational attributes associated with the supported access control scheme(s),

and the createTimestamp, modifyTimestamp, creatorsName and modifiersName at- tributes;

The DSA shall support the UserPassword attribute, described in Reference [9]; A DSA which supports any kind of strong authentication sheJl support the strongAuthenticationUser £ind certiflcationAuthority attributes, as defined in Reference [8]; A DSA supporting any form of strong authentication shall support the following attribute types

defined in Reference [9]: UserCertificate, CACertificate, CrossCertificatePair,CertificateRevocationList and AuthorityRevocationList;

The DSA shall be configurable to allow new attribute types to be defined by the DSA administrator.

Extensibility of supported attribute types shall include the following features:

• New t3rpes may be defined in terms of syntaxes defined in Clause 6 of Reference [7]; and

• New types may be defined in terms of a new syntax where:

1. The S3mtax is one of: Integer, Null, Boolean, Enumerated, Bit String, Octet

String, Object Identifier, Distinguished Name, Case Exact String, Case Ignore String, Numeric String, Printable String, UTC Time or Telephone Number;

2. The new syntax is an ASN.l structured type (i.e., SET, SEQUENCE, SET OF,

SEQUENCE OF £ind CHOICE), possibly including tags, where each component

uses one of the syntax forms listed in the previous item; and

3. The matching rule associated with a locally defined type may be defined using any of

the niles described in Clause 7 of Reference [7].

The DSA shall be configurable to allow new object classes to be defined by the DSA administrator.

Extensibility of supported object classes shsdl include the following features:

• New object classes may be defined to be either abstract, structural or auxilieiry;

• A new object class may be a subclass of £iny class described in Reference [8] or it may be a

subclass of a locally defined class; and

38
• A new object class may be defined in terms of any combination of attribute types described

in Reference [8] and locally defined attribute types.

The DSA shall be configtirable to allow the DSA administrator to define the complete set of

edlowed name bindings. Each of the name bindings described in Clause 7 of Reference [7] shall be

implemented;

The DSA shall adhere to the pragmatic constraints specified in Part 11, Clause 7 of Reference [12]; and

The DSA shall adhere to requirements in Part 11, Annex A of Reference [12] regarding the Maintenance of Attribute Syntaxes.

Distributed DSAs only. The following requirements apply only to Distributed DSAs, as defined

in Section 3.1.2.1. The DSA must be able to carry out name resolution and search continuation for an alias whose

dereference points to an entry held outside the DSA, as described in Peirt 11, Clause 9.1.5 of

Reference [12];

The DSA must be able to carry out simple authentication of a user whose entry is outside the

authenticating DSA as described in Faxt 11 of Reference [12], Clause 9.1.7; The DSA must adhere to requirements regarding the handling of the Tracelnformation attribute, as specified in Part 11, Clause 9.2.2 of Reference [12]; The DSA must adhere to the requirement regarding propagation of signed arguments specified in

Part 11 Clause 9.2.3 of Reference [12];

The DSA must adhere to the reqtiirement regarding referrals and chaining specified in Part 11

Clause 9.2.4 of Reference [12], with the following proviso:

• the conditions under which a distributed DSA does not act on a referral include the following:

- The returnToDUA element of DSAReferral indicates the referral is not to be acted

on; or — Administrative limitations or service policies prevent the DSA &om acting on the referral.

The DSA must adhere to imderlying services requirements specified in Peirt 11, Clause 10 of Ref- erence [12];

The DSA shall be capable of supporting the structure £ind naming rules defined in Reference [8], Annex B;

The DSA shall be able to support all superclasses of supported object classes; The DSA shall be able to support the storage and use of attribute type information, as defined in

the Reference [7], including their use in naming and access to entries;

The DSA shall support the encoding, decoding and matching of edl the attributes in the Naming

Prefixes of every naming context they hold (see Reference [5], Clause 9);

39
The attributes and attribute sets in Reference [7], associated with the object classes listed below

are required. The storage and use of the object classes below is also required:

Top, DSA, Alias, Country, Locality, Application Process, Organization,

Organizational Unit, Application£ntity,Device, Group of Names,

OrganizationalPerson, OrganizationalRole, ResidentialPerson

An object class may not be defined as a subclass of itself; The DSA must support all character sets and/or other nameforms defined in Reference [7], including

T.61, PrintableString etnd NumericString;

It is a minimnTn requirement that invoke Application Protocol Data Units (APDUs) and return

result APDUs shall be accepted unless their size exceeds 2**18 - 1 (262,143) octets;

At minimum, 8 nested Filter parameters will be supported, with a toted limit of 32 Filterltems;

All distributed DSAs shall be capable of acting as a holder and a propagator of Directory information;

The DSA shall support the Versions component of the Bind argtunent;

The DSA shall support the Reference [12] Directory Common Application Directory Profile;

The DSA shiJl be able to hold eind use the following reference types:

• superior: Non-first level DSAs shall have precisely one. First level DSAs have none;

• subordinate: Meindatory;

• cross: Memdatory; and

• non-specific subordinate: Optional.

A first level DSA shall be able to hold and use the root context'^^ and shsM hold as master at least one naming context immediately subordinate to the root of the Directory Information Tree;

If the DSA supports the directorySystemAC it must be able to accept a chained request and

generate a referred;

In order to perform simple authentication of a user whose entry potentizilly resides on another DSA,

a DSA must be able to invoke DSA Compare and Read operations, and must thus support the

directorySystemAC;^^ and

If the propagation of a Search operation involves request decomposition, the tracelnformation

argument of the origineil Seeirch request sheiU not be reset, rather the full tracelnformation for the

overaiU Search to the point where one or more new Search requests are generated shsJl be included

in the new Search requests;

^'I.e. a first-level DSA shall act as if it holds the (hypothetical) root of the Directory Information Tree.

^*In order to perform simple authentication of a user whose entry potentially resides on another Directory System

Agent.

40
Centralized DSAs only. The following requirements apply only to CentraJized DSAs, as defined

in Section 3.1.2.1. The DSA must not implement shadowing.

3.1.2.5 Static Requirements for Shadow Supplier and Consumer Directory System

Agents

In addition to the generzJ statement requirements, the statement reqiiirements for Shadow Supplier

DSAs, the statement requirements for Shadow Consumer DSAs and the general static requirements,

Shadow Supplier £ind Consumer DSA packages must satisfy the following static reqtiirements:

A DSA shedl, at a minimum, support either the shadowSupplierlnitiatedAC or the shadowConsumerlnitiatedAC. If the DSA supports the shadowSupplierlnitiatedAC, it may optionally support the reliableShadowSupplierlnitiatedAC. If the DSA supports the shadowConsumerlnitiatedAC, it may optioneilly support the reliableShadowConsumerlnitiatedAC;

Each shadow supplier DSA shaH maintain a consxrmer reference for each shadow consumer DSA

that it supplies with a replicated area; Each shadow consvmier DSA shall maintain a supplier reference for each shadow supplier DSA that

supplies it with a replicated eirea; The DSA must support the modifyXimeStamp and createTimeStamp operational attributes;

The DSA must provide support for the copyShallDo service control;

The DSA must implement the Directory Information Shadowing Protocol (DISP) as described in Reference [12] Pfirt 11, Clause 8.11.^^ A class 2 unit of replication, as described in

Reference [12] Part 11, Clause 8.11.3, shaill be supported;

AU DSAs implementing the DISP shall be capable of acting as both shadow supplier and consimier

as defined in Reference [10], Clause 3 and shaH meet conformance requirements stated in Reference

[6], Clauses 9.3 and 9.4; The DSA shall also support minimmn shadowing requirements:

• Support for both directoryShadowConsumerAC and directoryShadowSupplierAC;

• Support for an updateMode whose mode choice includes a specification of schedulingParameters; and

• Support for schedulingParameters specifications which specify a periodic strategy.

The product supplier shall state which Unit of Replication conform£ince class is supported:

• 0: Basic Unit OfReplicat ion. The DSA shall be capable of shadowing a imit of replication

with the following characteristics:

1. The eirea includes a class 0 subtree as defined in Reference [12]; and

^'See also Section 2.10.

41
2. The area includes a specified knowledgeType (e.g., master, copy or both).

• 1: Intermediate UnitOfReplication. The Directory System Agent shaR fully support Basic

UnitOfReplication and shall also be capable of shadowing a unit of replication with the

following characteristics:

1. The area includes a class 1 subtree as defined in Part 11, Clause 8.10 of Reference [12]; and

2. The knowledge includes an extendedKnowledge element with value TRUE.

• 2: Mfiximal UnitOfReplication. The DSA shall fully support class 1 and shall be capable

of shadowing a xmit of replication whose specification uses AttributeSelection (including

selection on class). The DSA shall be capable of supporting overlapping replicated areas as described in Reference [10], Clause 9.2.5.

3.1.2.6 Dynamic Requirements for all Directory System Agents

All DSAs must satisfy the following dynamic requirements:

Conform to mapping onto used services defined in Clause 8 of Reference [6]; Conform to procedures for distributed operation of the Directory related to referrals, as defined in

Reference [5];

If conformance is claimed to the directoryAccessAC application context, conform to the procedures of Reference [5] as they relate to the referral mode of the Directory Access Protocol;

If conformance is claimed to the directorySystemAC application context, conform to the referral

mode of interaction, as defined in Reference [5]; K conform£ince is claimed to the chained mode of interaction, conform to the chained mode of

interaction, as defined in Reference [5]; Conform to the rules of extensibility defined in Clause 7.5.2 of Reference [6];

If conformance is claimed to Basic Access Control, have the capability of protecting information

within the DSA in accordance with the procedures for Basic Access Control;

If conformance is claimed to the shadowOperationalBindingID, conform to the procedtires of

Reference [10] and Reference [3] as they relate to the Directory Access Protocol;

J£ conform£ince is claimed to the specificHierarchicalBindingID, conform to the procedures of

Reference [5] and Reference [3] as they relate to specific hierarchical operational bindings;

If conformzince is claimed to the non-specificHierarchicalBindingID, conform to the procedures

of Reference [3] and Reference [5] as they relate to non-specific hierarchical operational bindings;

and

The DSA shall adhere to requirements to support Session Version 2 as described in Part 11, Clause

10.2 of Reference [12].

42
3.1.2.7 Dynamic Requirements for Shadow Supplier and Shadow Consumer Directory System Agents

All Shadow Supplier and Shadow Consumer DSAs must satisfy the following dynamic requirement:

Conform to the procedures of Reference [10] as they relate to the Directory Information Shadowing Protocol.

3.2 Non-Standard Functions

Section 3.1 describes the features £ind capabilities which an X.500 Directory product must have in

order to satisfy current U.S. federal government procurement guidelines. However, these features

£ind capabilities, though essential, provide only the bare skeleton of functiontility required for an

efficient and usable Directory system.

This section sets out to explore some non-mandatory, sometimes even non-standeird features

which can enhance the performance and usability of the Directory as an information storage and

retrieviil tool. As in Section 3.1, Directory User Agents and Directory System Agents will be treated

separately, except in the criticfil area of interoperability, to which a specific section is dedicated.

3.2.1 Interoperability

Interoperability between two Directory components means that they should be able to exchange

Directory operation requests, results £ind errors without error and with a mutual interpretation of

the various p£urameters and their values which appear in the protocol exchanges. Interoperabihty

between two instances of the same product is usueilly taken for granted, so the term usujilly applies to the inter-working of two or more implementations from different vendors, or two or more

different implementations from the same vendor. While it may seem self-evident at first that two

implementations of the same standard should inevitably work together, experience has shown that

this is rarely the case, at least not initieJly. Despite the C£ireful leinguage of the steindfirds themselves

and the work put into the production of various sets of Implementors' Agreements'^ and standards

profiles, ambigtuties often exist, and different interpretations on the part of software production

staff of different vendors invariably occur.

Various guides to X.500 product interoperability exist: the OSINET Stable Interoperability Tests docimient. Reference [14], gives the results of interoperability testing performed between different

X.500 products in a controlled environment. At the time of writing, the Joint Interoperability

Test Command (JITC) of the Defense Information Systems Agency (DISA) of the Department

of Defense (DoD) is also performing X.500 conformance and interoperability tests £ind recording

the results in a publicly accessible register. If the product(s) under consideration is (are) not

included in these sources, then the manufacturer shotdd be considted as to whether the product

will interoperate with all the other systems xmder consideration, and should be held accotmtable

to any clfdms made.

Interoperability between different components of an organization's Directory system is always highly

^'Non-standard in the sense that the features lie outside the scope of the Standard.

^^See, for example, Reference [12].

43
Vendor A

Vendor B

/ The X.500 Directory

Directory Access Protocol

Kim. Vendor C "^^ ^ Directory System Protocol

Figure 3.1: Interoperability in the X.500 Directory.

44
desirable, but there are two situations in which it becomes critical: when policy or circumstEuices

dictate that the Directory will be made up of heterogeneous components (i.e., components from

different manufacturers; different products from the same manufacturer; different releases of the same product line from the same manufacturer; and so on); and when policy or circumstances

dictate that the organizationzil Directory must communicate with other X.500 instfiUations outside

the organization, which in aU probability will use software and/or hardware which differs in some way from that in use locjilly.^®

All DUAs should be able to interoperate with any DSA component in the orgfinization's locsJ

Directory. All DSAs should be capable of interoperating with all DUAs and all DSAs in the

organization. Figure 3.1 gives a schematic rendition of this idea.

3.2.2 Directory User Agents

Many of the features considered in this section apply to the humein user interface to the DUA, as opposed to the protocol engine component, but the two components £ire treated together here since

the Directory Standfird regards the user interface as £in integral part of the DUA (see Reference [3], Clause 6.2, Note 3). Beeiring in mind the potentially huge range of possibilities for the presentation

and mauiptdation of Directory information, it is only possible to discuss the most generail principles

here, find, even so, possibilities may be missed.

Six general principles, which can be roughly grouped into three pairs, will be used as the framework

for exploring the reedization of the DUA's potential. Configurability find Ease of Integration enable

the product to be tailored to best suit the user's requirements while creating minimfJ disturbance to the established user environment. Accessibility of the information held in the Directory find Clarity

in the presentation of this information are vital if the service is to be of genuine use, providing

ease of access to needed information. FinfJly, Ease of Operation and Informativeness deal with the

need for the product to enhance rather than impede the user's access to information, providing an

easily imderstood interface with detailed and informative help pages at each step.

3.2.2.1 Ease of Configuration

One quality which is highly desirable for all features of the DUA is that they be easy to configure.

In addition, reconfigtiration of any featxire should cause a minimimi of disturbance to the system.

For exfimple, no rebooting or restfirting of the softwfire should be necessary in order to reconfigure a feature: the operation of the DUA should be essentially imdisturbed. Also, the reconfiguration

should go into effect immediately fifter it is complete, and be applied to subsequent operations.

However, resTilts of finy Directory operations initiated prior to the reconfigiiration may need to be

treated in accordance with the configuration in place when the corresponding operation request was issued.

Additionally, it should be possible to configure each feature from outside the DUA itself (i.e., when

the DUA is not r\mning, or as the enactment of a system-wide configuration policy) by editing some

configuration file, using either a reguleir text editor or a tool specialized for the task (preferably

both), which is judged to be the best suited to the local user community.

^'As well as differences between the X.500 products themselves, there may be differences in the underljring communications software. Such differences are not addressed here.

45
Examples of features that it should be possible to configure in accordance with the principles laid

out above include:

• Common Arguments. The Common Arguments^^ associated with each Directory Operation are often relatively constant for the duration of a session, and as such may be inserted

into each operation automatically by the DUA, without the need for the user to enter them

individually. They should be easy to configure and easily modified. For exaimple, the system

Common Arguments Editor

serviceControls

securityParameters V-. NUUrequestor •;'.NULL \

Service Controls Editor

options L4,S,6

priority medum

timeLimit (sees) 120

sizeLimit NULL

scopeOfReferral country

attri buteSi zeLi mit NULL

Figure 3.2: An example of a menu-based editor for Common Arguments.

might provide a default Common Argxma.ents configuration file for each user, which is easily

modified at any time, either during a session by using a specialized tool such as an editable

pop-up menu, or outside sessions by simply editing the file with a normal text editor or special

tool provided for the purpose. Figure 3.2 shows a simple example of a tool for editing the

Common Argiunents pMameter.

• Local Caching Capability. It is possible for a DUA to cache Directory information by

simply storing any information it receives from a Directory System Agent. Such caching is outside the scope of the Standjird, and it is not possible to set up an agreement between DUA

and DSA to ensure updates to the cached information, etc., but local caching can nevertheless

prove to be a useful tool and can help increase retrieval speed for the user while decreasing

network treiffic cind DSA workload. Local caching algorithms c£ui vaiy from the most basic

(e.g., store aU information received for a designated time period, indexing by distinguished

name) to the more elaborate. For exeimple, if a certain entry is accessed more thein a threshold

niunber of times dtiring a session, the DUA may be configured to send out ajx independent

Read operation to obtain all possible information from the entry in question, sind use the

cached information to satisfy subsequent queries about the entry. In this latter case, the

DUA is acting "in the background," independently of the user, to obteun information that it

is assumed the user is likely to need.

See Section 2.6 for more on Common Arguments.

46
• Specification of Nonstandard Schema Elements. It is regarded as essentieil that the user or administrator of a DUA be able to define nonstandard schema elements designed to accommodate locfJ requirements. For the DUA, these elements are attribute types, object

classes and DIT content rules. Ideally, these can be specified either with a regular text editor,

using specified formats, or by using specialized tools provided with the DUA software. The

definition mecheinisms shoidd incorporate the notions of attribute hierarchies, object class (midtiple) inheritfince, and so on. Any tools provided will likely be windows-based for clarity

of information presentation.

• Default DSA Specification. It should be possible for a user to specify a "default" DSA

with which to bind when initiating a Directory session, possibly along with a list of backup

DSAs to contact, in order of preference, if the preferred DSA is imavailable for some reason. This avoids the need for the user to specify a particular DSA on each bind attempt, and thus

saves time and effort, while furthering the notion that the user is connecting to the Directory

as a whole, as opposed to a single server.

Alternatively, a list of possible DSAs to contact, labelled with user-friendly names, coidd

be displayed, enabling the user to simply click on the desired name in order to bind to the

Directory.

• Default "Home Position". Such a feature would enable the user to configure £in entry in

the Directory which would be the default position at which all operations would be targeted.

For instance, this may be the user's own entry, or the naming context prefix for a naming

context in which a user or application carries out most processing. Optionally, this entry

could be read and displayed when the user binds to the Directory.

• "Hot list" of Commonly Accessed Entries. Similar to the default home position, this

feature would enable the user to configure a list of commonly accessed entries or entry dis- tinguished name prefixes, which coidd be brought up on a pop-up menu and easily selected

with a mouse, saving the typing of often long Distinguished Ncimes.

• Full or Abbreviated Attribute Names. The DUA should be easily configurable for the

input and display of full length (e.g., "Organizational Unit") or abbreviated attribute names

(e.g., «0U").

• Confirmation Request. Before the submission of each operation request to the Directory,

the user may be prompted by the DUA interface as to whether the request is ready for

submission. The default condition could be set as a toggle.

This is only a selection of features which can and should be easily configurable by the user. In

the sections that follow, other features exeunined in different contexts wiU also be seen to be clear

c£indidates for user configuration.

3.2.2.2 Ease of Integration

An X.500 DUA product shoidd be easily integrable into the user's existing computing environment,

introducing the minimum of additional complexity and presenting an interface which is easily

understood and based on cleeir, open principles. Above all, any DUA package should be known in

advance to be capable of interoperating with £iny DSA package in the organization. Some ways in

which a product may achieve these gosds include:

47
• User Interface. The user interface of the DUA should be able to nin under a variety

of widely used, de facto or de jure standard operating system packages, such as the veirious

windowing environments that are currently available. For clarity of presentation, it is desirable

that the DUA use some kind of windowing system, the point here being that it should have

the capability to fit easily into whatever system is currently in use at the user site.

• X.400 Integration. The principal use of the Directory, at least initially, is envisioned to be

as a name to address lookup facility for X.400-based electronic mail systems. With this in

mind, it is seen as highly desirable that the DUA provide a programmatic interface or API to such systems. The Directory standard contains various definitions which allow for the storage

of X.400 information, eind X.400-based systems should be equipped to query the Directory

for this Information. See also the next item.

• Standard Application Programming Interface. The progrtimmatic interface to the

DUA should be based on the Portable Operating System Interface (POSIX) /Institute of

Electriceil and Electronic Engineers (IEEE) API for Directory operations, Reference [13], or some other widely accepted standard. This enables applications developers at the user site to develop applications aroimd a standardized set of function calls in order to Directory-enable

their software. It also should minimize the Jimount of developer effort expended if Directory

products Me switched, thereby empowering the user community with the ability to select X.500 products on the basis of other, more significant features.

• Variety of Platforms. The product should be available to run on a variety of hardware

and softweire platforms. In pjirticular, from the user's point of view, it should be available to nm on all platforms in use at the user's site at the time of purchase.

• Communications Architecture. The product should be able to accommodate the var- ious types of communications zirchitecture in place at the user site, including pure Open

Systems Interconnection (OSI), mixed OSI-Transmission Control Protocol/Internet Protocol (TCP/IP) (i.e., Request For Comments (RFC) 1006, Reference [15]), or whatever other

communications architecture may be present.

3.2.2.3 Accessibility of Data

The purpose of the DUA is to obtain information from the Directory eind present it to the user. The

DUA product should do as much as possible to enhance the accessibility of Directory information;

for ex£imple, by msdcing it easier for the user to compose the Directory operations necessary for the

effective retrieval of the desired information. Some exeimples of how this might be done are given

below:

• Handling of Referrals.^° When a referred is received by the DUA, several courses of action

are open to it. The referred information, or just the fact that a referral has been received

in connection with a particular operation, might simply be passed on to the user. This

information could be accompanied by £in option for the user to select whether to proceed with

or terminate the operation. Alternatively, the DUA could pursue the referral automatically,

possibly flagging the user that it has done so - both these options shoidd be configurable by

'°See Section 2.6 for an explanation of Referrals.

48
the user. In the simplest case, the referral may just be discarded and the operation logged as unsuccessful.

t Automatic Bind. The DUA might automaticedly bind to a defaidt DSA on start-up, en- abling the user to begin work immediately.^^ This feature should be configTirable.

• FoUowup List Operation. The DUA might issue a List operation automatically £ifter every

Read operation to show the subordinates of the entry on which the operation was performed.

This information in turn might be used to create a d3mamic graphic representation of the

DIT in the area in which work is being performed. This feature should be configurable.

• Tree Build. The user may wish to see a graphical representation of the DIT at the point

at which he/she is working. This might be achieved by the provision of a utility in the

DUA which, through the automatic issuance of a succession of List requests, cam obtain the

information necessary to build a graphical representation of the requested DIT fragment. The

user might specify the number of levels of the DIT to be diagrammed, relative to a given target

entry, both above tind below that entry. To take this level of accessibility to the next logicsd

step, Directory operations should be tfirgetable at entries in the displayed DIT fragment by

clicking on the displayed entry using the mouse or other pointing device. A defaiilt value

shoidd be configtirable for the number of levels to be displayed, and a system-wide default

may obteiin. Access controls may prevent a full picture from being displayed.

3.2.2.4 Clarity of Presentation

In order to optimize the useftdness of Directory information to the Directory user, the X.500

product user interface should display all information with the greatest possible cl£irity. For all practical purposes at the present time, a windows based approach is the most desirable means for

the display of information. This enables different information objects or groupings of objects to be

displayed as separate entities, drag and drop/cut and paste features, point £Uid click functionality,

eind so on, minimizing the amoimt of time spent by the user on such tedious tasks as typing

Distingtushed Names and repeating operations with slightly different parjimeters. Some features

which might aid in the cleirity of presentation of information follow:

• Pop-up Displays. Each information item (for example, the contents of a Directory entry,

the result of a Read operation) is displayed as a list of items in a pop-up window. Each item

consists of the attribute type and vadue(s). When there is more thein one value associated

with £in attribute, or the attribute has a complex syntax, then the entire yalue or value set

is displayed in a new window by clicking on the initisd item. This process is recursive for

complex elements.

• Highlighting of Distinguished Values. Distinguished attribute values might be highlighted or otherwise indicated so that the entry's Relative Distingxushed Name can easily be

read.

'^Usually such an automatic bind will grant the user only public access rights in the Directory. The user will need to be re-authenticated if greater access rights are required. The point here is that the DUA is "ready to go"

immediately on start-up.

49
3.2.2.6 Ease of Operation

Ideally, when using the Directory, information recovery is optimized against the effort expended

by the user. In other words, the user should be able to recover the maximum information for

the minimum time and effort. To this end, the User Interface should include tools to assist in

the composition of Directory operation argtunents, so that these argimients can be assembled as quickly and easily, and with as few errors as possible. One example of such a tool is the Common

Arguments editor mentioned in Section 3.2.2.1. Additional examples of important areas to be

addressed by such tools are:

e Search Filter Editor. The avedlability of a tool to enable the user to quickly and accurately

build a search filter is highly desirable, since it is through the Search operation that most

Directory interrogation is likely to take place. Such a tool might permit the user to specify

the filter in a way similsir to a Structured Query Language (SQL) SELECT commemd, or

it might allow the user to biiild the filter in a display window, using cut find pastes from

Search Filter Editor

Attribute Menu

Country Name

Organizatioa

Locality Telephone X.400 Address Common Name

Surname X

Operator Menu

EQUAl^ AND

OR NOT

>= <= SUJBSTRING . .

ANY

INITIAL TERMINAL

[Filter Construction Panel )

(surname EQUALS "Lester" AND Organization SUBSTRING "Agriculture" )

Figure 3.3: An example of a windows-based Search Filter Editor.

other windows. These windows would include a pop-up menu of aveiilable attribute tjrpes,

where selecting a type inserts the type into the filter imder construction; a similfir, smaller,

pop-up menu containing the logiceJ connectors for the search filter; and a display window

which shows the filter at its present stage of construction (see fig. 3.3). In this way, the user needs only to type the attribute vjilues s /he wishes to use as limiting criteria in the Search

Jirgtiment. The tool as described is very general purpose, but this may not always be the

optimal approach - see "Operation Template Editor" below.

• Search Scope. The Search operation is the most powerful interrogation operation available to the user, but it is £ilso the most resource intensive and often the most time-consimiing. The

provision of a tool to enable the user easily to limit the scope of the seeirch Cein help to optimize

resource usage as well as to get residts back to the user more quickly. One method of achieving

this might be to provide a mechanism enabling the user to compose a single Search request

50
and have it directed at multiple, small, naming contexts where the user feels the likelihood of a hit will be greatest. Thus, for example, if a user wishes to locate an individual who works

in the federal government, and is fairly certidn that the person in question works for the

United States Department of Agriculture (USDA) or the Environmental Protection Agency

(EPA), the tool would send off two essentially identical requests to search the USDA and

EPA domains, instead of searching the whole of the U.S. Government domain. This produces

a much quicker response time at little extra effort expenditure on the pait of the user. While

this example might seem trite, the power of such a tool woiild be much more evident if the number of agencies concerned were larger, or government contractor orgtinizations were

involved, or the search scope in each instance were more restricted (for exftmple "personnel

office").

• Entry Modification Editor. Whenever the user indicates an intention to modify an entry,

the interface might automatically retrieve the contents of the entry using a Read operation,

and display them in an editable window. The user can then make any desired modifications

to the contents of the entry with the editor, the modifications fire automaticfiUy converted

into a Modify Entry request and shipped off to the Directory.

• Operation Template Editor. In many situations, exposure of the DUA user to the fuU

potentied of a DUA is neither necessary nor desirable. In such cases, it may be desirable to provide the user with a custom DUA which provides operation templates; for exfimple, a template which offers a name seairch facility, such as that shown in Figure 3.4, in which the

Name Search

Name:. H9J?^s

Organization: .P®pt : . .9.^ . C??!!i?erce

Locality:..*.

Results: . . .H.qbbs , Frank B

.

Hobbs , Thomas G

.

Figure 3.4: An example of an operation template for a Name-based Search operation.

user needs to supply only a common name and possibly one or more of a restricted nimiber

of other paxameters, such as organization naime, locality, an.d so on. The provision of such

simplified operation templates will be tailored to the needs of the particular orgsmization,

and templates will be designed to accommodate those operations most commonly rtqiured by

users. In psirticular, such templates can isolate the user completely from exposure to Directory

Distinguished Names^'^ by relying heavily on the Search operation to locate entries and using

See Section 2.5 for moie on Distinguished Names.

51
the information contained in the SesiTch result as input to Read operations if the need arises,

without the need for user input. The provision of a tool to enable the creation of such

operation templates for the DUA is highly desirable.

3.2.2.6 Inforxnativeness

Surrounding the core functionality of the interface, which enables the user to gfdn quick and efhcient access to Directory information, should be a large catalog of information about the interface itself,

it's functionality, the Directory attributes, object classes, and operations that it supports, find so

on. Ideally, a naive user will be able to start the package up and obtsdn meaningful information

from the Directory with a minimum of difficulty and without cause to move away from his/her

workstation. Some features to look for in this regjird «ire listed below:

• On-line Help. Extensive on-line help should be available. The help facility should give

clear and concise explanations of any item pointed to on the screen, in addition to offering a writable text window for the entry of help requests. The help facility should have the

capability to address topics pertedning to the user interface itself, such that its operation

is fuUy explainable, as well as to address X.500 topics insofar as they pertain to the user

interface (for exeimple; attributes, operations, object classes, etc.).

• Explanation of Errors. The interface should have the capability to present clear, detailed,

plain Icinguage explanations of any errors that occtir during operation, including errors related

/ \

I Enquiry Failed

J

Your request to READ the entry with Common Name

"Hobbs, Frank B." was unsuccessful because you

do not have the necessary security priveleges to

access the contents of the entry.

For more information about security procedures and

local security policy select here: jcoNmuE)

\ }

Figure 3.5: An example of a plain language error notification.

to the Directory, communications or interface. The provision of multiple-level, branched, menu-driven explemations would be a great asset, providing terse, high-level explanations for

expert users as well as detailed explanations for the novice user, and a range in between.

Figure 3.5 shows an example of such an error notification.

52
3.2.3 Directory System Agents

As with DUAs, the range of non-standard features which might be associated with a DSA product

is likely to be very large, and we can only hope to give some general pointers as to what the user, or more likely, the system administrator, should investigate.

There are a ntunber of broad subject categories to address when discussing the functioneJity of

DSAs, which may be summarized as follows: Configurability of the product ensures that the operator can tailor the operation of the package to best fit the administrative policy for the Directory which

has been set up by his/her organization; Operator Tools enable the operator to administer the

DSA as efficiently as possible; An SQL or other interface to a conventional Database Management

System (DBMS) means that the DSA package cein operate in combination with a regular DBMS

package.

3.2.3.1 Configurability

As with DUAs, all aspects of the operation of the DSA should be as fully configurable as possible.

For each feature, a clear, easy-to-use tool should exist, again preferably windows-based, to enable

the operator/administrator to configrire the DSA in accordsince with policy requirements quickly

and with as few errors or problems as possible, or there should be cleax information available as to which files should be edited in order to bring about the desired configuration. Extensive help

facilities should also exist (see sec. 3.2.2.6).

A selection of aspects of DSA operation for which configurability is crucial is listed below:

• Security Configiuration. The X.500 (1994) specifies powerfiil sectarity features which

allow strong authentication using public key cryptosystems and access control to information on various levels, including Administrative Area, Entry, Attribute and Attribute Viilue. All

aspects of £in orgainization's security policy shoidd be easily configurable on each of its DSAs,

either through the use of a specialized tool or through simple editing of plain text configuration

fUes.34

• Schema Configuration. The DSA package should enable full implementation of the organization's X.500 schema, allowing for the definition of non-Standeird attribute types, object

classes, matching rules, DIT content rules, DIT structure rules and name forms,"*^ as well as supporting those defined in the Standfird, Reference [1].

3.2.3.2 Operator Tools

Each DSA is a node which holds a part of the global Directory Information Base. As such, it should

be regarded as an essential information server and assigned a commensurate nimiber of staff^^ to

"see Section 2.8 and Reference [10] for discussions of X.500 Security features.

** Since these files contain detailed information on security policy, they should themselves be carefully protected. ''See Section 2.5 and Reference [3] for discussions of X.500 Schema elements. "Clearly this number is at the discretion of the owner organization and depends on the scale and operational status of the server in question. A small academic server may require a part time individual {lom time to time, while a DSA

holding a large part of a highly active corporate or governmental DIB may require round-the-clock supervision.

53
administer secxirity and schema policies, to set up and monitor replication agreements, to load the

data initially, making sure it complies with schema and security requirements, to perform backup

and restoration of Directory data, and generally to supervise the DSA's operation, to respond to any problems that might arise and provide general user services.

In order to assist the DSA administrator(s) in the efficient performance of these tasks, the DSA

package should provide a collection of clearly documented tools enabling the administrator to attend

to the tasks with a minimum of effort. Again, it is envisioned that a windows-based interface will

be most suitable at this time. Some examples of administrator functions and how they might be

carried out are included below:

• Schema Design. A large scale X.500 deployment, either within an orgfinization or spanning

multiple organizations, will be made up of a number of Directory Management Domains,

DIT Domains and Administrative Areas, each with its own policies on schema, security and

administration. The DSA operator's toolkit should contain tools to simplify the definition of

new schema elements by; for exeimple, allowing the operator to specify an existing schema

element from which a new schema element is to be derived and allowing her/him to add or subtract elements, name the new element, modify the inheritfince hierarchies to which the

element belongs and so on, in an editable window.

• Administration and Maintenance. As with any database, the DSA package requires a set of tools to carry out fundamental maintenance functions, such as backing up £ind restoring the

DIB as necesseiry, printing out portions of the DIB, reviewing access control policy, cleaning

up inactive DIB sections, and so on. However, because the Directory is distributed, other

administrative functions are also required, such as the configuration of knowledge references,^^

management of operational bindings (including shadowing agreements and so on.

• Bulk Data Load. When the DIB segment held by a given DSA is initially populated or when the DSA needs to be reloaded from back-up for some reason (equipment failure, security

breach or other imforeseen circumstance), a method of loading, the entire DIB segment quickly

from a bulk data file may be required. The Standard, Reference [1], does not specify how

this should be done, so it is left to the vendor. At the very least, the DSA package should

be equipped with some facility which will take bulk data from some sort of file and load it into the DIB in a format suitable for the DSA to read. The tool might filso contain functions

enabling the operator to selectively load or reload parts of the database, and might present the

operator with an easy-to-interpret interface, perhaps giving a schematic of the DIT contained

in the back-up file, allowing the operator to select which sections to load by clicking on em

entry in the diagram.

For initial population of the DIB, a Directory Synchronization package will almost certainly

be required. Such a device enables the DIB administrator to create a mapping utility to map

from any existing Directory facility into a format suitable for the DSA, and thus facilitates

the transition from a pre-existing, proprietary directory or database facility to one based on

r X.500.

The actueil mechanism of getting the data into the DIB may be proprietary/internal, in which

case the DIB will be populated from a back-up file on the same system as the DSA in a vendorspecific maimer; or the mechimism may use a specialized DUA to popidate the DIB using

'^See Sections 2.4 and 2.3 for discussions of inheritance of characteristics in schema elements. "See Section 2.5 for moie information on knowledge references. '^See Section 2.10 for information on shadowing agreements.

54
multiple X.500 Add Entry operations.*^ The proprietary method is likely to be quickest,

particxilarly if the DSA and the back-up are collocated on the same machine. The use of a

specialized DUA, however, permits the loading of the DSA across a network, £ind thus the

maintenance of a back-up database at a separate location from the Directory System Agent.

It should be borne in mind, though, that if the DIB is large, such an operation may have a

significant impact on network performance for other network users.

• Activity Reporting Package. It is highly desirable for the DSA package to include an

activity reporting feature to enable the operator to easily review vfirious usage statistics,

such as frequency of contact by other DSAs or by DUAs, frequency of access to various parts

of the DIT, security warnings, and so on. The ability to display such information in a readily

interpretable form (e.g., graphiczdly) is highly desirable. Access to this information can assist

the DSA operator in configuring his/her DSA to nm most efficiently (e.g., by medntedning

most-accessed information in core memory instead of on disc) snd can fiid in the management

of operational bindings and replication agreements between Directory System Agents.

3.2.3.3 Relational Database Management System Interface

One approach to the database management aspects of DSAs has been to implement the DSA as a front-end package to £in existing Database Management System (DBMS) or a Relational DBMS

(RDBMS). Typically, fin RDBMS using Standard Query Language (SQL) is most suitable for this

tjrpe of product, since the DSA product can then be run as an application using a variety of

RDBMS products supporting the Structured Query Language.*^ Figure 3.6 shows a schematic

representation of such an firreingement.

DSA Front-End

(SQL Interface)

RDBMS

Database

Figure 3.6: Schematic representation of a DSA front-ending to a conventional Relational Database

Management System.

The DSA front-end adapts the relationail structure of the RDBMS to mimic the hierarchiceJ struc- ture of the Directory Information Tree. The operator uses the management tools associated with

the RDBMS to manage the DIB, edthough some activity statistics will still need to be provided by

the DSA application (e.g., frequency of contact with other DSAs, security warnings, etc.).

*°See Section 2.6 for information on the X.500 Add Entry operation.

*^At least in theory!

55
Such a product configuration is desirable because it promotes £in open jirchitectiire, allowing the

customer to choose between DSA and DBMS applications which best suit her/his needs. In particular, the customer may purchase a DSA application to match an installed DBMS package without

duplicating functioniJity.

56
Chapter 4

Performance Evaluation of X.500

Products

This chapter provides gtiideliaes for the evaluation of the perform£ince of an X.500 product. Performance in terms of the Directory is assessed from two perspectives, and a testing methodology

for measuring aspects of X.500 product performance is outlined.

4.1 Aspects of Directory Product Performance

Performsmce in terms of the Directory can be viewed from two perspectives, which might be termed

hard and soft. The hard aspects of Directory performance are those quaintities which cam readily be measiired,

such as the time required by a DSA to process a given operation under controlled or laboratory

conditions. These measurements can be used as indicators of how the DSA might perform under real

world conditions (though the compeirative complexity and impredictability of a real world situation

preclude the use of these measurements as predictors). Measurements of hard performance axe couched in terms of tasks completed per unit time, i.e., the unit of measurement is essentially

temporal.

The soft aspects of Directory performance refer to more nebulous, less readily measurable properties

of the product, which contribute indirectly to the hard performance of any given DSA, or may

contribute to the performance of the Directory as a whole, but not necessarily to that of any

particulsir DSA or operation. Such qualities might include the "effectiveness" of a user interface

and the "intelligence" of a Directory System Agent.

Note: In the sections that follow, whenever a measurement is specified, the implicit assumption is that the specified operation can be completed (i.e., the target entry exists and contains the necessary

information) such that the only subject at issue is the time taken to complete an operation which

is known in advance to be possible. Also, these measrirements are designed for use under controlled

conditions. CompMisons between the products of different vendors thus rely on differences in

response times for a predefined operation on a predefined DIT, held in different systems of the same type.

57
4.1.1 Hard Aspects of Directory Performance

These are aspects of X.500 product performance that can easily be measured in terms of the amount

of time required for completion.

4.1.1.1 Directory User Agent User Interfaces

• Operation Request Processing Time. For each operation, the time taken between the

user's indication that he/she is ready to send a predefined (and syntactically correct) re- quest (usually by hitting the Return key or selecting the requisite button in a windowing

environment) and the subsequent output of a DAP operation by the Directory User Agent.

• Error Detection. The time taken for the DUA to report the presence of a predefined set of errors inserted into an operation request.

• Operation Response Processing Time. For each operation, the time taken between the

receipt of a predefined operation response over the DAP by the DUA find the display of the

i encoded information on the user's display device.*"^

• Operation Error/Referral Processing Time. For each^^ operation, the time taken between the receipt of «in operation error or referral over the DAP by the DUA find the display

of the encoded information on the user's display device.

• Automatic Processing of Referrals. When a DUA has the capability to automatically

process DAP referrals, then for a predefined set of referrals, the time between the receipt of a referral over the DAP find the output of a new operation request over the Directory Access

Protocol.

• Startup Time. The time tfiken between the invocation of the DUA progrfim and the availability of the DUA services to the user.

4.1.1.2 Directory User Agent Programmatic Interfaces

Since the DUA Programmatic Interface usufilly forms an integrfJ part of the DUA User Interface,

in that it provides the protocol-related services of the DUA, some of the measurements given

for the User Interface apply equally to the Progrfimmatic Interface or Application Programming

Interface. The comments related to Error Detection find Automatic Processing of Referrals

fJso apply to the Application Programming Interface. Two additional measurements of note for

the API are the time between invocation of the API find output of a DAP operation, for each DAP

operation; find, again for each operation, the time between receipt of a DAP result or error find the

presentation of this information to the invoking entity.

a normal working environment it is not necessarily desirable to display the information immediately as the

user's display may already be in use, but for our purposes here the time to display is an appropriate measurement.

*'0r a representative.

58
4.1. l.S Directory System Agents

• The DAP Resolution of Request. For each operation, the time between the receipt of a DAP request and the output of a DAP response. In this instance, the DSA is known to hold

the target entry of the operation request and the ttirget entry is known to hold the requested

information.

• The DSP Resolution of Request. For each operation, the time between the receipt of a DSP request and the output of a DSP response. In this instzince, the DSA is known to hold

the target entry of the operation request and the target entry is known to hold the requested

information.

• The DAP and DSP Production of Referral. For each operation, the time between the

receipt of a DAP or DSP request and the output of a DAP or DSP referral.**

• The DAP and DSP Display of Error. For each operation, the time between the receipt

of a DAP or DSP request eind the output of a DAP or DSP error. For each operation, time

to display each possible error should be measured. Clearly, this measurement requires the

deliberate submission of erroneous operation requests. The standard lists which errors are permissible for each operation (see Reference [4]).

• The DAP or DSP Chaining of Request. For each operation, the time between the

receipt of an operation request which the DSA is unable to satisfy and the output of a single

chained operation request.

• Chaining of Requests - Search Request Decomposition. When Seairch Request

Decomposition*^ occurs as part of the processing of a Search operation, two measurements

are of interest:

- The time between the receipt of a Search operation request APDU (DAP or DSP)

and the output of the fined Secirch request operation APDU resulting from the request

decomposition, and - The time between the receipt of the fined operation result, error or referral APDU re- sulting from the requests issued as a result of request decomposition and the output of a result, error or referral APDU to the original requestor.

The former measures how quickly the DSA can parse a Search request and forward the

components to the appropriate DSAs, while the latter measures how quickly the results can be reassembled eind forweirded to the original requestor.

• Structure of Directory Information Tree. Some DSA products are more sensitive to the structure of the DIT than others. Some perform better with a broad, flat DIT (few levels in the hierarchy, but many entries at each level) while others excel within the confines of a

deep, narrow tree (many levels in the hierarchy with comparatively few entries at each level).

**Tlii8 measuiement could be split into a set of measuiements, depending on the type of knowledge reference used

to generate the referral. ^'This measurenaent could be split into a set of measurements, depending on the type of reference used to generate

the chained request.

*'l.e., the breaking up of a Search operation request into multiple domain-specific requests and the forwarding

of these requests to multiple subordinate Directory System Agents. A Search request ia thus propagated down the Directory Information Tree. See Reference [4] and Reference [5] for more detaUs.

59
A product can be evaluated for performance in this regtird by selecting a set of operations

and ninning them against DSAs set up under the two configurations.

• Performance Under Load Conditions. The best test of a DSA product under load

conditions is to see it run in an operational environment, but in such environments it is impossible to st£ind£irdize measurements of the performance of one product against another,

though the experience of the staff involved with the installation is invaluable. In order to test the performance of a DSA product under load conditions (i.e., where multiple operations are being processed simultaneously) in a standard way, a DUA should be set up to fire out multiple

operation requests at a DSA or collection of Directory System Agents. The operation requests

may come from a batch fUe and be pre-encoded, in order to speed delivery. The operations

should be ttiilored towards the configuration being tested. The measure of performance here

again is time - the speed with which the DSA configuration resolves the set of simultfineous

requests it receives.

• Steurt-up Time. The length of time after which a DSA becomes available following a system

failure, re-initialization, madntenance, etc.

4.1.2 Soft Aspects of Directory Performance

These are features or qualities of a Directory product which, while not as easily measurable as the hard aspects described above, may contribute significantly to the speed and efficiency of the

Directory and hence to the productivity of its users.

• Efficiency of User Interface. The notion of efficiency is difficult to define Ln terms of a

Directory user interface, but if we take a holistic approach, we are able to derive a measurable

qujintity from the definition. Thus, we define the efficiency of the user interface to be the

time between the initial formtdation in the user's mind of what information to seek, and the

user's comprehension of the result of the corresponding operation.^^ This includes the time

taken to bring up and fill out the most appropriate interface screen, as well as the time taken

for retries if the results returned indicate that an inappropriate request was sent, and so on.

Since the user interface is the mediator between the user eind the Directory, it foUows that

the more qmckly the user can process an information request through the DUA, the more

efficient the user interface is.

• Intelligent Featiures. These aie features whose presence is like to enheince the efficiency

of information management in the Directory. They aire not directly measurable, but their

presence or absence may be noted.

- Automatic Shadowing. Where possible, DSAs can automatically set up shadowing agreements if heavy use of a subtree is detected. By shadowing the information, the consumer DSA reduces access time and network congestion. — Automatic Cross-Referencing. If heavy use of a remote DSA for which no knowledge

reference exists is detected, a DSA might automatically add a cross reference to the

remote DSA to its knowledge base.

^^This definition assumes that all othei factors, such as DUA operation processing time, DSA operation processing

time and the time for the request and result APDUs to travel between the DUA and DSA, are constant. If they are

not, then they must be factored out.

60
— Caching of an Entry by a Directory User Agent. If a DUA detects that heavy use is being made of a psirticular entry, it may automatically issue a Read request, cache the

result, and use the cached information to satisfy further queries. In this instemce, the

benefits in terms of access time need to be weighed agjiinst the loss of confidence in the

accuracy of the information, since no standard replication agreement exists. This option

should be subject to pre-authorization by the user. — Automatic Resolution of Referrals. This is a stfindard feature which saves the user from

the task of re-initiating an operation if it was not possible to chain it within the Directory. — Shielding User from Distinguished Names. To increase the efficiency of the user interface, as discussed above, the user should be shielded from Directory Distinguished Naimes.

This can be done through use of the Search and List operations, showing only the Relative

Distinguished Names and «Jlowing the user to select on them in order to initiate other

operations. In this way, the Distinguished Names of entries fire held purely internally to the user interface.

4.2 Performance Evaluation Methodology

The Performance EvcJuation Methodology for X.500 Directory products will be detaiiled in a fu- ture publication which will describe the methodology and report on its practicfil application in a

laboratory environment.

In broad terms, as discussed above, the evaluation of a product will involve the incorporation of

timers around the softwfire units comprising the Directory product and the measurement of the

time taken to perform stfindard tasks under controlled conditions.

61
Bibliography

ITU-T Recommendation X.500 Series (1994) — ISO/EEC 9594,1-9:1994, Information Technology - Open Systems Interconnection - The Directory

ITU-T Recommendation X.500 (1994) — ISO/EEC 9594-1:1994, Information Technology - Open Systems Interconnection - The Directory: Overview of Concepts, Models and Services

ITU-T Recommendation X.501 (1994) — ISO/IEC 9594-2:1994, Information Technology - Open Systems Interconnection - The Directory: Models

ITU-T Recommendation X.511 (1994) — ISO/IEC 9594-3:1994, Information Technology - Open Systems Interconnection - The Directory: Abstract Service Definition

ITU-T Recommendation X.518 (1994) — ISO/IEC 9594-4:1994, Information Technology - Open Systems Interconnection - The Directory: Procedures for Distributed Operation

ITU-T Recommendation X.519 (1994) — ISO/IEC 9594-5:1994, Information Technology - Open Systems Interconnection - The Directory: Protocol Specifications

ITU-T Recommendation X.520 (1994) — ISO/IEC 9594-6:1994, Information Technology - Open Systems Interconnection - The Directory: Selected Attribute Types

ITU-T Recommendation X.521 (1994) — ISO/IEC 9594-7:1994, Information Technology - Open Systems Interconnection - The Directory: Selected Object Classes

ITU-T Recommendation X.509 (1994) — ISO/IEC 9594-8:1994, Information Technology - Open Systems Interconnection - The Directory: Authentication Framework

ITU-T Recommendation X.525 (1994) — ISO/EEC 9594-9:1994, Information Technology - Open Systems Interconnection - The Directory: Replication

IGOSS-Industry/Government Open Systems Specification, National Institute of Standards and

Technology Special Publication 500-217, May 1994.

Stable Implementation Agreements for Open Systems Interconnection Protocols, Version 7, Edition 1, December 1993, National Institute of Standards and Technology Special Publication

500-214.

IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 17: Directory Services Application Program Interface (API), Institute of Electrical and

Electronics Engineers Standard 1003.17.

62
[14] OSINET X.500 Directory Services Stable Interoperability Tests, Version 1.0, Edition 1.0, June

8, 1993."*^

[15] Rose, Marshtdl. T. and Cass, Dwight, E., ISO Transport Services on top of the TCP. Request

for Comments 1006, DDN Network Information Center, SRI International, May, 1987.

*'This document is available through the Corporation for Open Systems, 8260 Willow Oaks Corporate Drive, Suite

700, Fairfax, VA 22031

63

ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SYSTEMS TECHNOLOGY

Superintendent of Documents

Government Printing Office

Washington, DC 20402

Dear Sir:

Please add my name to the armouncement list of new publications to be issued in the series: National Institute of Standards and Technology Special Publication 500-.

Name

Company

Address

City State Zip Code

(Notirication key N-503)

Technical Publications

Periodical

Journal of Research of the National Institute of Standards and Technology—Reports NIST research and development in those disciplines of the physical and engineering sciences in which the Institute is active. These include physics, chemistry, engineering, mathematics, and computer sciences. Papers cover a broad range of subjects, with major emphasis on measurement methodology and the basic technology

underlying standardization. Also included from time to time are survey articles on topics closely related to the Institute's technical and scientific programs. Issued six times a year.

Nonperiodicals

Monographs—Major contributions to the technical literature on various subjects related to the

Institute's scientific and technical activities. Handbooks—Recommended codes of engineering and industrial practice (including safety codes) devel- oped in cooperation with interested industries, professional organizations, and regulatory bodies. Special Publications—Include proceedings of conferences sponsored by NIST, NIST annual reports, and

other special publications appropriate to this grouping such as wall charts, pocket cards, and bibliographies.

National Standard Reference Data Series—Provides quantitative data on the physical and chemical

properties of materials, compiled from the world's literature and critically evaluated. Developed under a worldwide program coordinated by NIST under the authority of the National Standard Data Act (Public

Law 90-396). NOTE: The Journal of Physical and Chemical Reference Data (JPCRD) is published

bimonthly for NIST by the American Chemical Society (ACS) and the American Institute of Physics (AIP).

Subscriptions, reprints, and supplements are available from ACS, 1155 Sixteenth St., NW, Washington, DC

20056.

Building Science Series—Disseminates technical information developed at the Institute on building

materials, components, systems, and whole structures. The series presents research results, test methods, and

performance criteria related to the structural and environmental functions and the durability and safety

characteristics of building elements and systems.

Technical Notes—Studies or reports which are complete in themselves but restrictive in their treatment of

a subject. Analogous to monographs but not so comprehensive in scope or definitive in treatment of the subject area. Often serve as a vehicle for final reports of work performed at NIST under the sponsorship of

other government agencies.

Voluntary Product Standards—Developed under procedures published by the Department of Commerce

in Part 10, Title 15, of the Code of Federal Regulations. The standards establish nationally recognized

requirements for products, and provide all concerned interests with a basis for common understanding of

the characteristics of the products. NIST administers this program in support of the efforts of private-sector

standardizing organizations.

Order the following NIST publications—FIPS and NISTIRs—from the National Technical Information

Service, Springfield, VA 22161.

Federal Information Processing Standards Publications (TIPS PUB)—Publications in this series

collectively constitute the Federal Information Processing Standards Register. The Register serves as the

official source of information in the Federal Government regarding standards issued by NIST pursuant to the Federal Property and Administrative Services Act of 1949 as amended. Public Law 89-306 (79 Stat. 1127), and as implemented by Executive Order 11717 (38 FR 12315, dated May 11, 1973) and Part 6 of

Title 15 CFR (Code of Federal Regulations).

NIST Interagency Reports (NISTIR)—A special series of interim or final reports on work performed by

NIST for outside sponsors (both government and nongovernment). In general, initial distribution is handled

by the sponsor; public distribution is by the National Technical Information Service, Springfield, VA 22161,

in paper copy or microfiche form.
e

s

o

"oc

JSo

uH

oc

2

e

a. 3

—J W5 C U

-2 •£ Z O

tn u

It