INTERNET-DRAFT Peter Jurg
Erik Huizer
SURFnet bv
Mark Jacobs
Stratix Consultancy bv
Evelijn Jeunink
University of Utrecht
Ton Verschuren
SURFnet bv
October 1995
Introducing a Directory Service
Filename: draft-ietf-ids-x500-intro-dir-00.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
This Internet Draft expires 1 March 1996.
Abstract
This report provides a 'manual' for establishing an electronic White
Pages Directory Service within an organisation and for connecting
it to a wide-area Directory infrastructure. It is based on the
experiences from the SURFnet Directory Services pilot project. The
wide-area service is of importance to all users of e-mail services
who want to find e-mail addresses of other e-mail users (worldwide!)
or any other address information such as telephone and fax
numbers.
Establishing a White Pages Directory Service within an organisation
includes a technical, legal and data management component. As the
amount of work involved in the technical component can be reduced
by using standard equipment and by good support from the provider
of the wide-area Directory infrastructure, the legal and data
management issues require more attention. Legal aspects include
formal registration of the service, informing all registered persons
about the service and data protection.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 1]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
Data management concerns all issues that are related to collection,
publication and maintenance of the data. Experience gained in the
SURFnet project demonstrates that continuity in data management is
only feasible if the procedures for these activities are integrated
in existing procedures for paper or other electronic directories.
It also helps if there is a strong commitment from the higher
management to participate in a wide-area Directory Service.
Contents
1 Introduction
2 Introduction to Internet Directory Services
1. X.500 basics
2. Basics of Whois++ and index servers
3. Towards an integrated Directory Service
3 Legal issues
1. The EU directives on data protection
2. Information towards the registered people
3. Providing a purpose and regulations for the registration
4. Accuracy of the data
5. Protection of the data
4 Infrastructure
1. A well-maintained infrastructure
2. An easy-to-install-and-operate DSA
3. Multi-vendor DSA products
4. Directory User Agent (DUA) Interfaces
5 Data management and Operation of a Directory Service
1. Data management issues
2. Security issues
3. Towards the operational phase of the X.500 Directory Service
6 Main conclusions of the SURFnet Directory Services pilot
7 Recommendations for participants
1. General
2. Technical
3. Legal
4. Data management
8 References
9 Glossary
10 Security considerations
11 Authors' Addresses
Appendix A: DUA interfaces
1 Introduction
This report aims to offer an introduction to everyone faced with
building a Directory Service for an organisation. It describes the
results of the SURFnet Directory Services pilot project. As such,
it serves as an introduction to the various aspects of building a
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 2]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
Directory Service: Technical, Legal and Organisational.
1.1 Introduction to Directory Services
Effective e-mail communication can benefit from the existence of an
adequate global electronic White Pages service (i.e., a directory
service offering data on people) to enable network users to retrieve
the addresses of communication partners in a user-friendly way. As
the number of people connected to computer networks increases (and
it does so continuously, at least doubling each year!), it becomes
more difficult to track down people's electronic (mail) addresses.
Hence, in order to make global communication over computer networks
work, a global, electronic White Pages service is indispensable.
Such a service could also easily contain telephone and fax numbers
and postal addresses. Furthermore, electronic White Pages may prove
to be useful for specific local purposes, e.g., for replacing paper
directories or improving the quality of personnel administration.
Although several efforts are being made to develop a less
complicated approach, currently the most suitable technical solution
for the integration of a globally-distributed electronic White Pages
and a database for local purposes, is X.500 [1] (see chapter 2).
After some initial technical piloting with X.500, in 1992 SURFnet
decided to start a Directory Services pilot with the main goal of
establishing an operational X.500 Directory Service in SURFnet [2]
and join the international infrastructure based on X.500 technology
called 'Paradise' (Piloting An inteRnationAl DIrectory SErvice)
[3].
Paradise contains about 1.5 million entries of individuals and 3,000
of organisations. Worldwide, 35 countries are involved. Paradise was
an EC project until April 1994. Now its operational tasks are
continued by DANTE. The goal of Paradise and related national
initiatives is to stimulate and extend the use of the X.500 White
Pages service. Within Paradise, attention is paid to technical and
organisational aspects. The Paradise infrastructure is mainly based
on the Internet Protocol. The specific issues that are related to
the use of the Internet Protocol for X.500 can be found in [4].
This document supersedes a previous publication with the title
'Building a Directory Service' which is the final report of the test
phase of the SURFnet Directory project [5]. It contains the
experiences gained in three different pilots that were carried out
in the SURFnet project to achieve a broad introduction of X.500
Directory Services in the Dutch R&D community. Besides setting up
an X.500 infrastructure (and integrating it in the Paradise
infrastructure) and a study of the legal issues involved in setting
up a Directory Service, the project included technical and data
management pilots at 10 universities and the creation of a central
X.500 server that allows small and medium-sized organisations in
SURFnet to put up a Directory Service. The latter was a joint pilot
of SURFnet and the Dutch Ministry of Home Affairs, which benefits
both organisations.
Please note that many issues that are discussed in this report are
not specific to X.500, but are independent of the type of Directory
Service used.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 3]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
1.2 Structure of this document
The first two chapters of this report provide the basic theoretical
knowledge a new site should have. Chapter 2 briefly describes the
X.500 protocol and some alternative Directory Services, while
chapter 3 gives a summary of the legal issues involved in setting
up a White Pages service.
Chapters 4 and 5 describe setting up an X.500 White Pages service in
practice. Chapter 4 describes the SURFnet Directory Service
infrastructure as it was created in the project, and presents an
overview of tested and available products for X.500 Directory
Services. Chapter 5 deals with the organisational issues encountered
in the pilot. In chapter 6 some conclusions are presented and
finally, in chapter 7, recommendations are made for new sites that
want to start deploying a Directory Service.
2 Introduction to Internet Directory Services
This chapter introduces the basics of the protocols that can be used
for setting up a White and Yellow Pages Directory Service on the
Internet.
A White or Yellow pages Directory Service on the Internet (and
connected networks) of any value should evidently have the
possibility of being maintained in a distributed way. Currently, the
X.500 protocol is the only solution available for such a Directory
Service. However, in the Internet community, work is continuing to
develop other solutions, offering functionality partly similar to
X.500 and partly complementary. This chapter discusses the basics
of the X.500 protocol and its service aspects. Then it briefly
discusses the basics of the newly-defined protocols (Whois++ and
index servers) and how these protocols can contribute to an
integrated Directory Service on the Internet that includes X.500,
Whois++ and still other services.
A concise introduction to the X.500 protocol can be found in [6].
Other useful references are [7] and [8]. The Whois++ and index
server techniques are still under construction. Currently,
there are draft documents available by Peter Deutsch and Chris
Weider that are expected to become RFCs early in 1995. In [9] a
description of the functionality is given together with some
pointers to more information. The Whois++ service is discussed in
a more general context in [10] and [11].
2.1 X.500 basics
X.500 is a standard for a Directory Service by the International
Telecommunications Union (ITU). The same standard is also published
by the ISO/IEC. The latest version of the standard is from 1993 [1].
However, most of the current implementations still follow the 1988
version of the standard.
X.500 (1988) and X.500 (1993) differ in many aspects. The three most
important differences are mentioned below (knowledge references,
replication and access control). However, they remain compatible
in the most important aspects, those of interconnection and
interworking.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 4]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
2.1.1 The Directory model
X.500 uses a distributed approach to realize a global Directory
Service. The idea is that local (communication oriented) information
of an organisation is maintained locally in one or more so-called
Directory System Agents (DSAs). Note that 'local' is a flexible
expression here: it is possible that one DSA keeps information of
more than one organisation. The opposite is also possible: Directory
data of one large organisation can reside in multiple DSAs, which
is still considered local from a service-provision point of view.
A DSA is essentially a database:
- in which the information is stored in a structure according to
the X.500 information model (see section 2.1.2);
- that has the ability, where necessary, to exchange data with
other DSAs through use of the Directory System Protocol (DSP) of
the X.500 recommendation set.
All DSAs in an X.500 Directory Service are interconnected according
to a predefined model, the Directory Information Tree (DIT). The DIT
is a virtual hierarchical data structure. In the White Pages
application it consists of a 'root', below which 'countries' are
defined. Below the countries (usually) 'organisations' are defined,
and below an organisation 'individuals', or additionally,
'organisational units', are defined (see the simplified illustration
below where only three countries and no organisational units are
presented).
The DIT is a representation of the global Directory.
root o
/|\
/ | \
/ | \
countries uk de fr
/ | /\ |\
/ | / \ | \
organisations a b c d e f
| | | | | |
persons .. .. ... .... ...
Each DSA holds part of the global Directory and is able to find
out, through the hierarchical DIT structure, which DSA holds a
certain part of the Directory. This is done by means of 'knowledge
references'. Some implementors have chosen to use an alternative
approach for the X.500 (1988) version of this concept (since they
thought it was not appropriate), which resulted in
interoperability problems between DSA implementations by different
vendors (see section 4.3). The 1993 version of the standard should
solve these problems.
2.1.2 The information model
The X.500 standard defines the information model used in the
Directory Service. All information in the Directory is stored in
'entries', each of which belongs to at least one so-called 'object
class'. In the White Pages application of X.500 object classes are
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 5]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
defined, such as 'country', 'organisation', 'organisational unit'
and 'person'.
The actual information in an entry is determined by so-called
'attributes' which are contained in that entry. The object classes
to which an entry belongs define which types of attributes an
entry may use and hence, what information is specific for entries
belonging to that object class. The object class 'person' for
example, allows attribute types like 'common name', 'telephone
number', and 'e-mail address' to be used and the object class
'organisation' allows for attribute types like 'organisation name'
and 'business category'. Depending on its type, an attribute can
take one or more values.
At least one attribute value of the entry is used to specify a
name for an entry. The entry of a person is usually named after
the value of the attribute type 'common name'.
An example of an entry belonging to the object class 'person' is:
Attribute type Attribute value
Object Class: top person
Common Name: Peter Jurg P. Jurg
Surname: Jurg
Postal Address: SURFnet Postbus 19035
NL-3501 DA Utrecht
Telephone Number: +31 30 305305
Facsimile Telephone Number: +31 30 305329
Mail: jurg@surfnet.nl
The names that occur in the DIT are simply the names of entries.
Hence, the entry shown in figure 2.1 occurs in the DIT as the node
'Peter Jurg' below the node of the organisation 'SURFnet'.
The name of an entry must be unique at the level in the sub-tree
of the DIT to which the entry belongs. So if there are two people
called Peter Jurg at SURFnet, they must have a different first
value for the attribute type Common Name in their entries.
For further details on naming and information structure, the
reader is referred to [12].
2.1.3 Service aspects of X.500
The standard does not describe how to distribute different parts
of the Directory amongst DSAs. The information corresponding to a
single node of the DIT (i.e., an entry for a country, organisation
or person) cannot be distributed over several DSAs, however the
information below and above that node in the DIT can reside on
different DSAs. In practice, a large organisation will maintain
one or more DSAs that hold its part of the Directory. Smaller
organisations may share a DSA with other organisations. The
distribution amongst the DSAs is totally transparent to the users
of the Directory.
Replication
An indispensable principle in a distributed Directory Service is
the notion of replication. If information of one DSA can be
replicated in another it reduces access time and improves the
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 6]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
quality of service (a DSA may be down, but the information it
contains is still available). However, the 1988 standard does not
provide a mechanism for this. The Quipu implementation of a (1988)
DSA provides a proprietary mechanism for several types of
replication which is used in the Paradise infrastructure
(documented in [13] and [14] ). See also section 4.3.
Directory User Agents
A user of the Directory can be a person or a computer. A user
accesses the Directory through a so-called Directory User Agent
(DUA). The DUA automatically contacts a nearby DSA by means of
which the user can search or browse through the DIT and retrieve
corresponding information. A DUA provides a standardized piece
of functionality that can be implemented in all sorts of user
interfaces. Therefore, users may access the Directory through
dedicated DUA interfaces or e-mail applications, for example.
Currently, most DUA interfaces to be used by people are
stand-alone applications, but it is expected that in the near
future many DUA interfaces will be integrated with other
applications. DUA interfaces for the White Pages service are
available for virtually all types of workstations (DOS, Macintosh
OS, Unix). For an overview of X.500 available software see
[15] or future updates. A shortlist of DUA interfaces
is provided in appendix A.
Access control mechanism
Owing to its access control possibilities, X.500 can be used
simultaneously for making available address information to the
outside world and for specific private Directory Service
applications restricted within an organisation. Whereas the
definitions of the DIT, object classes and attribute types of the
public White Pages information within an organisation have to
conform to those of the rest of world, the internal applications
may use their own DIT structure and their own definitions of
object classes and attributes (the values being only visible
within (a part of) the organisation). Nevertheless, one local
infrastructure can be used for both the public and private part
of the directory service. In order to make some information
visible within a (part of an) organisation only, access control
is used, which in practice may require some extra management.
Access control is only available in the 1993 version of the
standard. A proprietary mechanism is provided in the Quipu
implementation of the 1988 version.
Searching the Directory
X.500 offers the possibility to carry out searches at any level or
in any sub-tree of the DIT. In order to carry out a search, an
attribute type together with a value have to be specified. The
Directory then searches for all entries that contain an attribute
of that type with the given value. For example, in an organisation
one can search for all persons having a particular common name, or
all organisations within a country that have telecommunications as
their business category. It is up to the organisations that
maintain the DSA's to decide who may perform which searches and
also how many levels deep a search may be. Searches can be done
on the basis of an exact or approximate match.
Problem: Yellow Pages
Apart from the benefits mentioned previously, X.500 inevitably
also suffers from some drawbacks, of which the most important is
the lack of a clear definition for a Yellow Pages Service.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 7]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
There are two obvious ways to set up a Yellow Pages Service in
X.500, but neither is encouraged. One way would simply be to use
the searching possibilities of X.500 as described above. However,
generally such searches would propagate through many DSAs, hence
taking up much of the performance of the network and the DSAs
themselves. Such searches, which are called 'distributed
searches', are generally not encouraged. In the Netherlands they
are not even allowed. Here is the output of a distributed
search in the UK (an X.500 search for common name 'Smith' in the UK
yields a list with 1231 hits and propagates through
all UK DSAs):
Initiating searches to 143
organisations................................
Waiting for results (control-C to abandon outstanding searches)...
Liverpool John Moores University
COMPUTER SERVICES
1 MARK SMITH +44 51-231-2112 M.E.Smith@livjm.ac.uk
Manchester Computing Centre
2 L M Smith +44 161 275 6053 L.M.Smith@mcc.ac.uk
3 P E Smith +44 161 275 6084 P.E.Smith@mcc.ac.uk
University of Brighton
Arch and Build Research Unit
4 B.SMITH B.J.Smith@bton.ac.uk
..
..
..
..
1229 E Smit +44 161 275 2758
School of Economic Studies - Dover Street Building
1230 G Smith +44 161 275 4839
Whitworth Art Gallery
1231 Alistair Smith +44 161 273 6541 x31
A second way to build a Yellow Pages Service in X.500 would be by
means of a special DIT structure, for example a special branch at
some place in the DIT called YP, below which different business
categories or scientific branches could be found. However, the DIT
is already a problem as it is, since it suffers from the fact that
the world is not a clear hierarchical structure. It seems to be
very difficult in practice to agree upon the DIT structure between
different countries, service providers and/or participating
organisations. The standard provides the framework for the DIT,
but does not specify the actual structure. The problem is that any
user who wants to retrieve information from the Directory Service
or any algorithm which helps the user in doing this, needs to know
about the DIT structure. So if there is no uniform DIT structure,
users may encounter difficulties in finding the information they
seek. This fact, although it may seem very appealing at first,
also makes it very difficult to build a Yellow Pages Service by
using the DIT.
A possible solution for Yellow Pages could be to have index
servers that hold indexed information of the publicly available
entries in all DSAs. As an example one could think of a Dutch
index server which holds all organisation names with their
business category and a pointer to the DSA that actually holds the
address information of each organisation. One could search this
one index server for a certain business category and retrieve the
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 8]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
names and pointers of the organisations within this business
category. Subsequently, by using the pointers, the addresses of
one or more of these organisations can be retrieved. This service
will certainly reduce the number of distributed searches and still
allow Yellow Pages-like functionality.
Such a solution could be provided by the index service that is
originally defined for Whois++. There are also some ideas within
the Internet to set up DSA-based index servers.
2.2 Basics of Whois++ and index servers
2.2.1 The Whois++ information model
The original Whois model [16] defines a Directory
Service with a single database. Whois++ extends this service so
that it can reside on several databases, linked together by the
Whois++ index service.
The Whois++ information model is similar to the X.500 information
model. A Whois++ database contains a series of individual records
(compare the 'entries' in X.500), that hold the actual information
(compare the 'attributes' in X.500). The records are divided into
several types, e.g. 'Person' or 'Domain'. For each type a
different set of attributes is defined that a record may hold.
Such a set of attributes is called a 'template' and is the
equivalent of an object class in X.500. Two examples of records
of the type 'person' are:
Template: Person Template: Person
First-Name: Peter First-Name: Albert
Last-Name: Jurg Last-Name: Jurg
Favourite-Drink: Milk Favourite-Drink: Belgian beer
And of the type 'domain':
Template: Domain
Domain-Name: stratix.nl
Contact-Name: Mark Jacobs
Several other types, templates and attributes can be defined.
2.2.2 Whois++ index service (the directory model)
The Whois++ directory model is essentially different from X.500.
It does not define a hierarchical name structure like the X.500
DIT. Instead, it defines a space of index servers, the 'index
server mesh'. For each Whois++ server there is at least one index
server in the mesh that contains information about the contents of
that server in a specific format. The formatted information is
called a 'centroid' and comprises the templates and attributes
that are used within the Whois++ server, and contains a list of
the values that occur (in any record) for each attribute. As an
example we show what the centroid would be for a server holding
the three records above:
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 9]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
Template: Person
First-Name: Peter
Albert
Last-Name: Jurg
Favourite-Drink: Milk
Belgian beer
Template: Domain
Domain Name: stratix.nl
Contact Name: Mark
Jacobs
For each centroid, an index server has a pointer to the Whois++
server from which it originates, thus providing an index of the
information of the Whois++ server.
Index servers can again be indexed by other index servers, hence
bringing some hierarchy to the index server mesh. However, this
hierarchy need not necessarily end up in a tree structure with one
top-level index server. In addition, crosslinks between index
servers can be made wherever needed. (Since cross-links may lead
to loops if a client follows the referrals given by index servers,
a client is responsible for loop detecting.)
2.2.3 Service aspects of Whois++
Whois++ and the index service are totally search based. Browsing
through the directory is only possible if a client uses searches
to build lists of data. Since index servers can be built to hold
only particular types of records (organisations, persons,
physicists), Whois++ is particulary suitable for Yellow Pages
services. It can avoid large distributed searches.
Whois++ will have optional access control and replication.
2.3 Towards an integrated Directory Service
The idea of an integrated Directory Service is proposed in [11]. It
is best defined as a Meta-Directory Service that integrates existing
Directory Services such as X.500, Whois++, finger, etc.
Some work being undertaken in this area on the Internet. The IETF has
been working on a paper that defines the requirements and possible
options for such a service, which will be published as an RFC early
in 1995. Mike Schwartz has been implementing most of the ideas in
his Netfind application (a brief description can be found in [10]).
A simple ASCII-based protocol (called SOLO) for querying Directory
Servers and for constructing indexes is also under development in
the IETF. Finally, a team of implementors has agreed to run a pilot
with index servers (using the centroids indexing approach, see
section 2.1) and various Directory protocols in 1995.
3 Legal issues
This chapter discusses the legal issues involved in setting up a
Directory Service. It points out the restrictions that have to be
dealt with. For the deployment of an X.500 Directory Service, an
optimum has to be found between the extensive (technical)
possibilities of X.500 as described in the previous chapters and the
legal restrictions described in this chapter.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 10]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
When a Directory Service includes the registration of personal data
it has to obey the rules as laid down in legislation on privacy
issues. Such legislation is intended to protect the privacy of
registered persons. Many countries around the world have introduced
privacy laws, although the consistency of legislation between
different nations is still lacking. However, the basic rules of most
privacy legislation do not differ too much.
In order to get an idea of the restrictions implied by privacy
legislation, we focus here on two directives of the European Union
(EU) that are intended to 'standardise' legislation on privacy
issues and provide a minimum level of protection. The Dutch law 'Wet
PersoonsRegistraties (WPR)' complies with the EU-directives. Hence,
the discussion here is entirely applicable to the Dutch situation
and probably applicable to the situation in other countries.
3.1 The EU directives on data protection
The EU has issued two directives concerning data protection, known
as SYN287 and SYN288 [17]. SYN287 is a general directive on which
we will focus here. SYN288 is more specific and intended only for
public digital communication networks, in particular ISDN.
The EU directive SYN287 assumes that the actual registration of the
data is functioning out of sight and beyond the control of the
person whose data are registered. The person in control of the
registration, i.e., the controller, is exclusively responsible for
the processing of the data. Processing means any operation or set
of operations performed on personal data, including collecting,
recording, storing, adapting, altering, consulting, using,
comparing, erasing, deleting. The registered person has the right
of obtaining information about the processing of his/her data. The
controller has responsibilities to meet the rights of the registered
person and has the responsibility to ensure that registered data are
protected against misuse, etc.
Another important rule in the directive is that one purpose of the
registration has to be defined by the controller. This purpose
implies which data can be made available by the controller.
Since it is possible in X.500 (and some other) Directory Services for
the registered person to manage parts of his/her own registration,
it would appear that the idea of a controller and registered person
do not strictly apply to such a networked Directory Service.
In the directive, the controller is not defined as the person who
maintains the data, but rather as the organisation or person who
facilitates the service. This implies that the responsibilities of
the controller, as implied by the law, apply to the system managers
and operators of all types of Directory Services (including X.500).
In the following sections we will describe these responsibilities
in more detail.
3.2 Information towards the registered people
The controller of the
data in a Directory Service has to inform the registered persons when
their data are first inserted and has to inform a registered person
about the processing of his/her data upon request. Generally, Directory
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 11]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
Services make it easy for a registered person to stay informed about
the registration, without interference by the controller.
3.3 Providing a purpose and regulations for the registration
The controller has to define a purpose for the registration. Personal
data may only be collected for specified, explicit and legitimate
purposes and used in a way compatible with those purposes. The
personal data must be relevant, adequate, and not excessive in
relation to the purpose. The EU directives require that a
supervisory authority be notified of the registration. In most
countries a regulation (or code of conduct) for the registration
made by an organisation or a group of organisations can be submitted
for approval to this national supervisory authority. Some, mostly
public, organisations are obliged to draw up a code of conduct
concerning the processing of personal data. The purpose of the
Directory Service can be described as: to facilitate and promote
easy communication and acquaintance amongst users on the network
by means of providing personal data via the network. The question
can be posed if this description is explicit enough. If it is, the
next question will be which data, related to the purpose, may be
collected. If we look at figure 3.1 below, the Favourite Drink and
the Photograph attributes are questionable. The Dutch supervisory
authority for approving registrations has advised not to incorporate
those attributes in the Dutch service. If the purpose of a Directory
Service is described as 'to facilitate communication', only
addressing attributes would be allowed, such as e-mail address,
postal address, title, telephone and fax.
More restrictive rules apply to sensitive data: data revealing racial
or ethnic origin, political opinions, religious beliefs,
philosophical or ethical persuasion or trade-union membership, and
data concerning health or sexual life. The directive generally
prohibits the processing of this type of data, though there are some
exceptions to the rule. It is clear, however, that sensitive data
should be excluded from Directory Services. The admission of
sensitive data exceeds the purpose and objective of the Directory
Service.
Problems might occur if the Directory Service allows the data
subjects to modify their own data. The data subject might enter
sensitive information in a free format field like the description
field. It could be argued that this is one of the exceptions to the
rule, since the subject has supplied the data under circumstances
where it must have been clear that it would be registered. However,
to ensure that the system manager is not held responsible by law,
it is recommended that data subjects are only able to alter their
own data in a controlled way.
3.4 Accuracy of the data
Ensuring the integrity of the data in the Directory Service is not
only essential for its usefulness, it is also the legal obligation
of the controller.
On the one hand, one could argue that the possibility for the
subjects of the Directory to modify their own data is a guarantee
for the accuracy of the data, provided there are sufficient
authorization and authentication procedures. On the other hand, this
self-management of the data carries the risk that inaccurate or
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 12]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
incomplete data are entered in the Directory, intentionally or by
mistake, and are not corrected. Clear descriptions of the demanded
data, if possible, imperative formats, and up-date procedures will
contribute to the accuracy.
3.5 Protection of the data
The controller must take appropriate technical and organisational
measures to protect the data against accidental or unlawful
destruction, and accidental loss, and against unauthorized
alteration or disclosure, or any other unauthorized form of
processing. There should be a suitable level of security with
respect to integrity, the nature of the data and the potential risks
involved. The local protection of data is left to the implementors
of the Directory Service applications. This means that a good
Directory Services implementation provides tools to protect against
destruction, falsification and loss of personal data.
By definition, a Directory Service has a high degree of accessibility,
which makes it difficult to prevent unintended use of data for
direct-mail, junk-mail and other forms of unwanted mail. Many
potential Directory subjects have expressed fears that they will
be inundated with massive sales campaigns, requests for information
or abusive messages [18]. Establishing and maintaining rules to
prevent this can never be fully successful.
Most implementations of Directory Services do not leave much room for
technological barriers against misuse of data. However, a Directory
Services application can be implemented in such a way that the
resulting entries from one organisation per search or per user is
limited to a small number. This will, of course, also affect the
legitimate user who tries to find colleagues on the basis of scarce
pointers. Nevertheless, in order to prevent the misuse of data, it
is recommended to restrict the search possibilities of the Directory
Service.
4 Infrastructure
Since the purpose of the SURFnet pilot was to facilitate a broad
introduction of Directory Services in the Dutch R&D community, it
was necessary to set up a Dutch infrastructure that allows newcomers
to join in a relatively easy way. To achieve this, the following
infrastructural aspects had to be investigated and, if possible,
established in the pilot:
- a well-maintained X.500 infrastructure, integrated in the Paradise
infrastructure, facilitating easy data maintenance and access
procedures;
- an open infrastructure, supporting a multi-vendor environment;
- at least one easy-to-install-and-operate DSA product should be
available;
- a selection of good DUA interfaces should be available (both for
maintaining data and for querying the X.500 Directory Service).
The sections below describe how these aspects were covered in the
project. For further reading, [19] is recommended.
4.1 A well-maintained infrastructure
In the pilot, the following infrastructural services were established
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 13]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
by SURFnet which are essential for making data available in the
global DIT:
- access to the root-of-the-world node in the DIT, which is offered
by Paradise, has been established, hence providing the integration
in the global DIT;
- a so-called master-DSA for the Netherlands has
been set up, representing the top-level node in the DIT for the
Netherlands. Apart from country-level information, this DSA also
replicates the root of the DIT as well as data from master DSAs of
most other countries;
- a so-called central DSA service has been implemented, through
which small and medium-sized organisations have the possibility
of making their Directory information available in
the Dutch section of Paradise DIT, without having to install their
own DSA. A character-based public access DUA interface was
installed as part of the central DSA service.
Besides these infrastructural services, a team of DSA managers was
created. These are the operational managers of Dutch DSAs who
communicate through the distribution list dsa-man@nic.surfnet.nl
(subscribe through listserv@nic.surfnet.nl, also available as
newsgroup nl.surfnet.dsa-man). This group meets regularly to discuss
and monitor the SURFnet DIT structure, schedule management, quality
of the service (e.g., performance), etc. With respect to the quality
of the service, it can be noted that a so-called probe is running
from one of the sites, which periodically tests whether the Dutch
organisational DSAs are up and running. The probe software was
provided by Nexor Ltd. Finally, to assist new organisations in
getting their DSA up and running, the necessary information (EDB
files, a Quipu specific format; see section 4.2) of the root and
c=NL is available via ftp.
Early in 1995, ten Dutch universities were connected to the
infrastructure (also see chapter 5).
4.2 An easy-to-install-and-operate
DSA SURFnet uses the NeXor XT-Quipu DSA. This DSA has been tested
successfully with respect to ease of installation and configuration.
It is recommended that short-term participants in the SURFnet
Directory Service use DSAs running the NeXor XT-Quipu software. To
accommodate this, SURFnet and SURFdiensten (a company that effects
software licenses for the Dutch educational community) have
negotiated a support contract for this software with NeXor.
The operation of the currently available DSAs is still not a trivial
task. While awaiting new software for DSAs (e.g., according to the
1993 version of the X.500 standard) that is easier to manage,
SURFnet relies on the team of DSA managers to support new
participants. In 1994, SURFnet organized a course on NeXor XT-Quipu
DSA management for the team of DSA managers, particularly the
newcomers.
4.3 Multi-vendor DSA products
Where the Dutch X.500 infrastructure currently consists of Quipu
DSAs, the Paradise infrastructure also contains other DSAs. A
thorough interworking test in the Paradise pilot, including Quipu
and two other DSAs, was carried out at INRIA (the French Research
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 14]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
Institute in Computer Science). A report of this test is available
[20]. We cite some of the conclusions from this report:
- the replication and knowledge information add-ons to X.500, as
defined in RFC1276 [14], which are used in the Quipu implementation
(also see section 2.1.3) are efficient, but do not allow good
interworking of Quipu with other implementations in practice;
- effective, broad deployment of X.500-based services will impose
conformance to the '93 version of the standard. This will alleviate
most of the interoperability and interworking problems that have
been encountered so far, largely because key factors, such as
knowledge representation and the replication mechanism, are now
specified;
- a set of requirements on the "opening" of any X.500 service
(comparable to the Internet hosts requirements) should be
established, which includes for example:
- no server exists without at least one back-up with a
separate network access;
- no first-level server exists without a one-level copy of
its subordinate entries;
- distribution of a naming context (knowledge information)
should include that same one-level replication in order
to make all one-level searches extremely efficient;
- a set of requirements on acceptable and recommended
behaviour is established to provide a framework for
designers and developers of DUA interfaces to avoid
poorly-designed DUA interfaces breaking down the whole
service.
4.4 Directory User Agent (DUA) Interfaces
Currently, there are two types of user interfaces available for
accessing the Directory:
- DUA interfaces for data managers;
- DUA interfaces for end users.
4.4.1 DUA interfaces for data managers
Examples of DUA interfaces for data managers (for maintaining
Directory data) are IDM (Interactive Data Manager) and BLT
(BulkLoadTool) as developed by University College London for the
Paradise project. IDM can be tailored to fit all kinds of needs and
is good for use by inexperienced data managers. However, IDM has
some limitations, one of them being its interactive nature. BLT is
particularly suitable for:
- initial loads. After the initial bulk load, the Directory data
can be managed interactively, e.g., by using IDM;
- remote execution of update procedures within relatively
large organisations and/or organisations with a high rate of
change;
- combining data from different sources.
However, BLT asks for a well-defined format and well-defined update
procedures and has a relative lack of robustness: it is easily
thwarted by input that does not follow its strict syntax rules.
Also, error messages are often presented in places where an
inexperienced user would not expect them, this often not being the
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 15]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
place where the error occurs. (In this, the BLT very much resembles
compilers of the old days.)
4.4.2 DUA interfaces for end users
A summary of available standalone and integrated DUA interfaces for
end users and test results of some of these can be found in Appendix
A. During the project, eight DUA interfaces for end users were
tested. A list of requirements was put together to support the tests
of DUA interfaces. The most important requirements are listed
here:
- DUA interfaces for end-user workstations should support one of the
available lightweight Directory Access Protocols. Currently these
are:
- the standardized Lightweight Directory Access Protocol (LDAP;
see [21] and [22]), which offers almost the same functionality
as the Directory Access Protocol (DAP, the full OSI standard
for accessing the Directory), but it does not have the
overhead of the various OSI layers and it only runs on top of
TCP/IP;
- the Simple Object LOok-up protocol (SOLO; work in progress,
see section 2.4). that also runs on top of TCP/IP.
Implementing such a product on a Macintosh or PC requires
far less effort than implementing the full OSI stack together
with DAP.
- Installation and configuration of a DUA interface should be simple,
and good documentation should be available;
- A DUA interface should present the information in a user-friendly
way. E.g., not present all attribute types (the attribute type
object Class is of no use to the general user) or OIDs (Object
IDentifiers that uniquely determine object classes and attribute
types) or plainly present the information it receives back from the
DSA (such as 'rfc822Mailbox=Peter.Jurg@SURFnet.nl');
- A DUA interface should offer the possibility to use User-Friendly
Naming (UFN, defined in [23]) in order to find the entries of
people. A UFN for the entry of 'Peter Jurg' in X.500 (see section
2.1) would be 'jurg,surfnet,nl'. A DUA interface should accept this
as input and use a particular algorithm to find the entries that
belong to it;
- A DUA interface should support some basic functionality, such as:
- browse (list);
- search on different types of attributes;
- bind/authentication (modification of entries).
The fact that many attractive user interfaces already exist that meet
these requirements is mostly thanks to LDAP, and the instant
availability of LDAP libraries for Unix, DOS and Macintosh platforms
(courtesy University of Michigan).
In the SURFnet project an effort was made to establish integration of
DUA functionality in popular e-mail client software. The results
were not available during the project, but will become available
early in 1995. The current, or soon to be available, implementations
are listed in appendix A.
4.4.3 Centrally provided access services within SURFnet
One interface, Directory Enquiry (DE) as developed by University
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 16]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
College London for the Paradise project, was selected as the best
interface for 'dumb' terminals. The interface was translated into
Dutch, and installed as the SURFnet public Directory user interface.
This interface is now available to all users who do not have a local
DUA interface installed. Access to the public DUA interface is open
for telnet (TCP/IP).
Two interfaces that are available through the SURFnet Information
server are the gopher (URL: gopher://ldap.surfnet.nl:7777) and WWW
(URL: http://ldap.surfnet.nl:8888) gateways to X.500. The WWW
gateway can handle the 'labeledURL' attribute (this is a
non-standard attribute type which will be changed to a 'labeledURI'
attribute type) that enables connecting back from X.500 to WWW.
These gateways can be accessed by means of standard gopher- and
WWW-client software. Although the functionality of the gateways does
not meet the functionality of DE, both gateways have become popular
during the project, as they integrate X.500 with the frequently-used
navigation/information services on the Internet. Moreover, the
SURFnet public DUA (DE) was also inserted in the Gopher menu at the
SURFnet Information server.
To allow for the use of LDAP based DUA interfaces, SURFnet installed
an LDAP server. LDAP DUA interfaces used within SURFnet can connect
to this server (ldap.surfnet.nl) and the server translates the LDAP
queries into X.500 DAP queries. In 1995, as soon as the SOLO
protocol and server have been fully developed, SURFnet will also
install a SOLO server with similar functionality.
5 Data management and Operation of a Directory Service
This chapter describes the main results of the experiences with
respect to data management of the participants in the SURFnet
Directory Services pilot project (sections 5.1 and 5.2) and the
experiences of SURFnet with respect to the operation of a large
Directory Service (section 5.3).
At the start of the project, a difference was assumed between large,
medium-sized and small organisations. Hence, each of these
organisation classes was involved in the data management pilot
project.
The experience gained in data management in the Directory Service was
collected from contributions of 10 universities, 5 government
departments, 8 medium-sized organisations and 4 small organisations
(up to 25 persons).
Although basically the project was directed towards the use of X.500,
the experiences of the data-management pilot are largely independent
of the underlying technology. Therefore, the results and conclusions
in this chapter may be equally valid for Directory Services of
different nature (e.g. Whois++).
5.1 Data-management issues
The SURFnet project proved that organising data management requires
a considerable effort. However, if data-maintenance procedures for
a Directory Service are embedded in existing operations of data
within an organisation, the extra effort for operations is minimal.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 17]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
This section points out how to set up data management for a
Directory Service in effective way.
In order to get a good start with organizing data management and to
obtain an incentive for the cooperation of various departments in
large organisations, a management commitment was required from all
participating organisations.
5.1.1 The necessity of a high-quality Directory Service
The value of a Directory Service from the user's point of view (and
therefore also from the participating organisation's point of view)
mainly depends on quality:
- the quality of network and communication services that include
availability, accessibility, performance and robustness of the
Directory Service (these are discussed in some detail in chapter 4).
- the quality of the information offered by the Directory Service,
including the following parameters:
- availability (e.g. number of hits per 1000 queries); - accuracy
(e.g. number of error-free Directory records in a sample of 100);
- completeness (e.g. number of complete records in a sample of 100
Directory records, 'complete' to be defined);
- information richness (e.g. number of useful attributes per entry).
If standards are set for the quality of information parameters, this
will enable the impartial measurement of informational quality
contributions by individual organisations to Directory Services
operations. Publication of statistics on this subject may encourage
competition between organisations, thereby improving the Quality
of Directory Service (QODS) as a whole. Various technically
different solutions for Directory Services should be compared as
well as various services based on the same technology (e.g. Paradise
vs. other X.500 implementations).
A high-level QODS, to be achieved by quality standards and healthy
competition, will broaden the support for both the use of Directory
Services and the effort to contribute to them.
5.1.2 No need for new administrative procedures
For the acceptance of a Directory Service within an organisation it
is of vital importance that as little structural overhead as
possible is used for the maintenance of the Directory data. This can
be achieved by embedding the maintenance of Directory information
within existing procedures for the maintenance of personnel (and
student) databases. An even better solution is the implementation
of an automated Directory update process based on data from existing
source databases. The creation of completely new administrative
procedures for datamanagement is strongly discouraged, as these
carry the risk of not being executed properly, resulting in a
degradation of the Directory information quality.
5.1.3 Spreading the load caused by management activity
Data management and maintenance of the QODS proved to be important
activities. As the number of Directory contributors grows, these
activities may develop a significant traffic volume and processing
load. This should never hinder the performance of the Directory for
people or processes executing information searches. Searching and
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 18]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
browsing activities should have priority over data management.
Moreover, simultaneous data management activities of several
organisations must not interfere with each another, both with
respect to the information contents and the performance of the
Directory Service. One way or another, methods have to be found with
which spread the network traffic and DSA processing load caused by
organisations carrying out their data management jobs. Particularly
in multi-user DSAs, such as the Dutch central DSA for example, this
is mainly a matter of allocating well-chosen timeslots for data
management to contributing organisations.
5.1.4 Continuity in datamanagement: a matter of organisation
As stated above, continuity in data management has to be created by
effectively combining existing procedures and databases of personnel
and relation-management processes. However, these processes are
highly dependent on the size of the organisation. We will therefore
take a closer look at how things work within organisations of
various sizes.
Large organisations: coordination and commitment Universities,
administrative agencies and other large institutions usually consist
of a number of more or less autonomous units: faculties,
departments, etc. Each unit may have its own staff and/or student
administration system where Directory data can be derived from.
Additional information, such as room numbers, phone numbers, e-mail
addresses, etc., may be supplied by other systems, centralized,
departmental or application-specific (e.g. the telephone directory
application). In cases where Directory data are extracted from
various data sources, the cooperation of the managers of these
sources must be gained. Also, some coordination effort must be made
to synchronize the databases and to establish an efficient process
for the periodical data collection from various sources, maximizing
the actuality of the data. Multi-party cooperation may be enabled
by a written management commitment from the Board level of an
institution (this was required in the SURFnet project before
participation was granted). However, as reported by some
universities, enthusiasm, a good understanding of the importance
of Directory Services and, particularly the possible benefits for
existing management efforts, have a much greater impact on the
willingness for cooperation. Management commitment, although
necessary for the legal basis of the participation of an
organisation in Directory Services, should not be used to enforce
cooperation in an early stage of the project.
Medium-sized organisations: commitment and enthusiasm In organisations
with no more than a few hundred people (employees, students, etc.)
the foremost problem is generally not cooperation of several data
managers and coordination of their activities. Often, the data
source for the Directory Service is in one or a few administrative
systems, managed either by one IS manager or by a small IS
department with employees who are organised to cooperate. A major
problem in this type of organisation is time, or priority. As the
systems department is responsible for all IS activities, generally
a great deal of time is spent on day-to-day management activities,
such as user support and trouble-shooting, and time for development
activities is scarce. Furthermore, the remaining resources for IS
development are rather spent on applications related to the
company's primary processes than on organisation supportive
applications such as Directory Services. As the IS manager or IS
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 19]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
department is quite autonomous within medium-sized organisations,
commitment to Directory Services has to be generated within this
department. An enthusiastic 'project champion' is necessary to
continuously push the organisation through the project activities.
This employee must have a sound understanding of the value of
Directory Services for the organisation, knowledge of the
organisational issues and the ability to convince sceptic people
within the organisation of the importance of allocating resources
to Directory Services. Special attention is also needed for
Directory maintenance.
Small organisations: how to implement continuity? Continuity is also a
key issue within small organisations, as the frequency of data
management activities within such organisations generally is far too
low to maintain the skills needed for updating. Usually, there is
no link between the Directory data and some personnel management
system or any other kind of database. The Directory data are simply
fed manually into the Directory (in the Dutch data management pilot
this is the central DSA provided by SURFnet). This involves a
serious risk of a one-time action to fill the Directory, which is
then not maintained afterwards. Since small organisations almost
always make use of an external database (DSA), a possible solution
to this problem may be to have the updates done by the system
manager of that system. The small organisation can provide the
system manager with the necessary information by fax or e-mail. The
SURFnet central DSA service provides such a service.
5.2 Security issues
Operation of a Directory Service includes some security threats.
These will be discussed in this section. Both the protection of
confidential information in the Directory and the robustness against
faulty actions of (inexperienced) data managers are items of
interest. However, during the data management pilot project, no
potential security threats from end users have been traced or
otherwise disclosed.
5.2.1 Risks involved in actions of non-experienced data managers
As data managers are more privileged than other users of Directory
Services, they are able to influence to some extent the operation
of the systems the service has been built on. In particular, data
managers who do uploads in a central DSA that holds information of
many organisations may cause a major malfunction of the service.
In the SURFnet project the robustness of the central DSA against
uploading errors emerged as an item of interest when the
introduction of the Bulkload tool (BLT, see section 4.4.1) for data
managers was discussed. At least one case has been identified where
the central DSA crashed upon entering a defective set of
organisational data into the central DSA. Since then prevention of
such a situation has been part of the instruction for remote
BLT-users.
In general, the problem of malfunctional uploads can be prevented by
training data managers, implementing procedural checks, back-out
procedures, and so on. Of course, Directory data collection will
never affect the data in the source systems. Therefore, the data
manager may invoke the selection and delivery process within the
contributing systems, but he must not be authorized to make changes
in those databases.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 20]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
5.2.2 Protecting information (systems) of contributing organisations
There are no possibilities to gain access to corporate information
systems of participating organisations from the X.500 Directory
Services infrastructure. Directory data are generally stored in
different systems from the corporate administrative systems.
Periodically, Directory data are retrieved from corporate systems
into an intermediate file on a local system of the contributing
organisation. After a merge of various such files into a
bulkloadtool formatted file and a final check, the connection is
made to either the local DSA of the institution or the central DSA
and the file is sent over for bulkload processing.
By downloading the actual Directory information and comparing it with
the original BLT-formatted file, a check for unauthorised
modification of the latter file (which is only a theoretical
possibility) can be executed.
5.2.3 Protecting the privacy of registered people
Chapter 3 discusses the implications of privacy laws with respect
to data management. Special attention is needed when internally
visible data in an organisation should differ from externally
visible data. In that case, a thorough authentication mechanism
should prevent users from outside being able to view the internally
available data. A pragmatic approach to achieve this would be to
install a gopher or WWW gateway (see section 4.4) that is only
available to (a group of) users inside the organisation and uses
authentication to display the data that is meant for these users
only. Such a solution obviates the need for every individual user
in the organisation for a userid/password combination for accessing
this data.
Attention must also be paid to data replication. According to the
European law (see chapter 3), the system manager of a database (DSA)
is responsible for the privacy aspects of data that are held in the
database, as well as data that are replicated from another
database!
Generally, the data subjects of a Directory Service have to be
informed about the presence of their data in the Directory.
Publication of this fact in media that are available to all data
subjects is sufficient. However, one must ensure that this is indeed
the case!
5.3 Towards the operational phase of the X.500 Directory Service
This section discusses the possibilities to set up an
economically-sound Directory Service. This is not a trivial task,
as the established Directory Service in this project is a product
of joint work, based to a large extent on voluntarily contributed
effort. Who is responsible for the service? Who has the right and
means to enforce participants to continuously supply high volumes
of correct and current data? Who will pay for the service, and how
much...? Some questions that will be discussed in the sections
below.
5.3.1 Quality of service management
In general, every organisation that participates in a distributed
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 21]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
Directory Service such as X.500, is responsible for its own part
of the data and its own database in the whole service. Only the
structure of the X.500 DIT (see section 2.1.2) may reside under the
responsibility of a central organisation in a country (see also
section 5.3.4). Other issues, such as the quality of the service
as a whole, can only be the responsibility of a union of
participants. Hence, the quality of a Directory Service demands the
close cooperation of all participating organisations.
In the SURFnet Directory Service, SURFnet assumes responsibility for
the central part of the service, i.e., the structure of the DIT, the
international connectivity, the (top level) master DSA, the central
DSA and some centrally managed DUA interfaces and an LDAP server.
The quality of the remaining part of the service is guaranteed by
two different user groups and a special advisory board. The user
groups are a data managers group and the DSA managers group referred
to in section 4.3. The advisory board (consisting of a small number
of Directory Services experts from the participating organisations)
will advise SURFnet on the minimum service quality requirements that
have to be met by all participating organisations in the SURFnet
service in order to run an acceptable service. This recommendation
will be discussed in the user groups and will be revised if their
response requires it. SURFnet will ensure that the requirements that
are agreed upon are met by all participants.
The issues concerning the quality of service that must be tackled are
summarized in section 5.1.1. A branch in the DIT of organisations
that does not meet the requirements (which might well be the case
for organisations that are just starting) could be marked as
'experimental'.
5.3.2 When will organisations join the service?
As soon as the service has a good quality (in particular with respect
to completeness and available user interfaces), new organisations
will certainly be interested to join. However, before the 'critical
mass' has been reached, special incentive projects (such as SURFnet
Directory Services pilot project) are required.
However, other motivations may also play a role. Organisations may
also use a Directory Service for internal purposes (perhaps using
data that is only available inside the organisation). For example,
the Directory Service may replace a paper telephone directory and
save costs. Or its introduction may be used to revise or improve the
internal administrative procedures. The latter was the outcome for
almost all large organisations within the group of participants in
the SURFnet project. In many cases the administrative procedures
were improved 'on the fly'.
5.3.3 A financially self supporting Directory Service
Transforming the X.500 Directory Service from the project stage into
an operational service raises the issue of how to generate the
revenues needed to cover operational costs. Who is going to pay for
investments in the DSA infrastructure, who is going to pay the data
management costs?
In a White Pages Directory Service there are generally three parties
involved: the users who want access to the Directory, the
information providers who maintain the Directory information in DSAs
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 22]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
and the wide-area network service providers who maintain a
(national, regional, etc.) infrastructure that interconnects the
DSAs and may provide basic access services (ldap server, etc.; see
section 4.1).
Current charging models for information services show two types of
charging:
- a straightforward approach in which users pay directly
for the use of the service on a volume-dependent basis;
- an approach where the information providers pay for all the costs,
since they view the service as marketing platform.
The first approach is difficult to apply to a Directory Service as
described here, since such a service has a distributed and
international character. It requires elaborate accounting and
administrative tools that can distinguish between the retrieval of
address entries of different organisations, national traffic and
international traffic, etc. Owing to the complexity of this approach
in the case of a Directory Service, volume-based tariffs are not
considered with respect to the Directory Service within SURFnet.
An example of the second approach is the World Wide Web (WWW) on the
Internet. In order to make information available via WWW, many
information providers pay for connection costs (of their servers)
and for their own efforts to maintain the information. The users pay
for basic access to the Internet, but no additional costs for the
use of WWW. Of course, information providers view upon WWW as a
marketing platform. They assume that eventually users repay their
efforts by buying other products or services from them. However, a
marketing value cannot be assumed for a White Pages information
service, particularly where it concerns information of
non-commercial organisations. Hence this approach will probably not
be used for the SURFnet Directory Service.
Another model could be to regard the Directory Service as an
infrastructural service, which is an integral part of other services
such as e-mail or information services and that will improve the
quality of these services. In this approach the network provider can
charge all its customers for the infrastructural costs by
integrating the charges for the service in the tariffs of e.g. an
e-mail service. However, the question remains who will pay for the
data management costs incurred by the information providers. Again,
if the information providers are non-commercial organisations, it
will be clear that they will not be eager to pay these costs
themselves. And if the users have to pay for it, we are back to
(partial) volume-based charging which does not seem feasible. One
solution to overcoming these problems arose during the SURFnet
pilot: stimulate participation in the Directory Service by offering
a discount on the general license for e-mail, information and other
services to organisations that make their address information
available via the Directory Service. This model has to be further
elaborated.
5.3.4 For further study
In this section, some elements are mentioned that have not yet been
thoroughly addressed. These aspects are regarded as being important
for the future success of the Service and hence are recommended for
further study in 1995.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 23]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
Applications beyond the White Pages Service The concept of X.500
Directory Services is appropriate for development of many services
beyond the currently implemented White Pages Service (WPS). For
instance, at one of the universities maps are added to department
records to show external users of the X.500 Directory Service the
way to get to the location (the forthcoming integration with the
World Wide Web will improve the quality of such a service).
Elsewhere, the X.500 infrastructure of a university is used as a
basic register for local elections at the university. Students make
use of the Directory to view their individual test results.
Most of these applications, in particular those making use of
internal data of an institution outside the Directory data, require
a local DSA system. Organisations using the central DSA system do
not have the possibility to submit other data than the
communication-related set defined in the White Pages Service.
Other applications that are considered useful in the X.500
infrastructure are:
- Yellow Pages Service, which allows searching
with attributes such as 'scientific field of interest', 'job
description', 'business activity', etc. Also see section 2.3;
- two-way link to the World Wide Web, both for searching Directory
Data from the Web and for creating a Directory of WWW Home Pages.
Discussions on a special attribute for this (labelled URI) are now
ongoing in the Internet;
- distribution of public encryption keys
(e.g., in PGP and PEM). Publication of this key in the Directory
eliminates mail exchanges with the key owner or his mail
administrator and accelerates the process of acquiring the key;
- routing of X.400 mail. MTAs may use the Directory to look up
routing information for messages submitted to them;
- distribution of EDI identifiers.
Measuring end-user experiences Only recently the project reached a
point where an investigation of the experiences of end users has
become meaningful. As mentioned before, within the university
community, the hit-rate was increasing dramatically by the end of
1994. These users have to gain some experience with the X.500
Directory Service before a questionnaire can be sent to them.
Therefore, this aspect will be studied in 1995, with special
interest for user-friendliness, user perception of quality of
service and measurements of service usage.
Directory Structure evolution In 1995, the SURFnet Directory Service
will merge with other national Directory Services. Since SURFnet
uses a very simple Directory Structure (DIT and attribute
prescriptions) which is ideal for only a small number of
participants, this means that a new, national Directory Structure
is needed in 1995. A small working party is now defining this
structure. It is thought necessary to add a branch to the DIT in
which private (i.e. non-organisational) persons can be linked to
their administrative community (e.g. municipality), their province
or state, and their country. This branch will be added below the
country level and will use the locality attribute as classification
method. The proposed DIT looks like:
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 24]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
nl
/\
/ \
/ \
provinces organisations of
national importance
/\
/ \
/ \
cities organisations of
provincial importance
|
|
organisations
and inhabitants
Organisational entries at any level of the DIT can have an alias
elsewhere. Hence, the entry of an organisation of national
importance can have an alias under each city where it has a point
of presence. The Dutch Naming and Addressing Authority should
control the standardization process of the Structure. Unfortunately,
the position of this authority in the Dutch government is not
covered yet. This function could be placed either within the
Ministry of Transportation and Public works (Telecommunications and
Post Department) or within the Ministry of Economic Affairs (Dutch
Standards Institute).
6 Main conclusions of the SURFnet Directory Services pilot
The SURFnet Directory Services pilot project has evolved into an
operational service with a reasonable quality of service. It
contains the entries of personnel and students of 10 universities
and 11 other educational and research organisations. The
participation achieved in the pilot seems to have exceeded the
required 'critical mass'. Other organisations within the SURFnet
target group (and outside it) are now interested in joining the
Directory. The main technical difficulties have been overcome by
establishing a well-maintained infrastructure and by focusing on one
DSA product for the time being.
The major concern for the near future is the economic model for the
service. At this time (early 1995), SURFnet does not charge for
joining the service (either by using a private DSA or by using the
central DSA). Based on the relative success of the current service,
a model has to be found in which joining the Directory Service will
not be charged in itself, but will be included as part of a larger
set of services.
Another concern is the further development of user interfaces.
Although there are some rather good DUA interfaces at this time,
there is still a lack of interfaces that are integrated in other
application such as e-mail clients. However, the first beta-versions
of new e-mail clients with integrated DUAs are now available.
Both the service and the data quality are decisive for the user
satisfaction of any Directory Service. Hence, quality of service
definitions for Directory information, availability ('hit rate'),
accuracy ('error rate'), completeness and information richness are
indispensable. These have to evolve continuously according to the
feedback of a user group.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 25]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
7 Recommendations for participants
The experience with building a Directory Service as described in the
previous chapters has shown that it is feasible to build an
operational Directory Service in which different types of
organisations participate. However, there are still many obstacles
that any organisation starting with Directory Services has to
overcome; technical, as well as legal and organisational. The
following recommendations are made to allow as much as possible for
the removal of these obstacles, and to make it as easy as possible
for organisations to build their own Directory Service and join the
SURFnet Directory Service.
7.1 General
Establishing a Directory Service requires a systematic
approach. This type of service is complex with regard to the
combination of different aspects (technical, administrative,
organisational, legal) and demands the involvement of people
originating from different disciplines.
As a primary requirement, prepare the contribution of your
organisation with great care. Don't be too eager to load the
Directory. Keep in mind that data on people are involved. Take
sufficient time to prepare all necessary actions before actually
feeding personal information into the Directory.
Information on working practices, available DSA and DUA software,
legal aspects, etc. is available at the SURFnet infoserver (URL:
gopher://gopher.nic.surfnet.nl/11/SURFnet.dir.dutch/Projecten/X500).
Furthermore, practical issues are discussed and exchanged over the
distribution list snetx500@nic.surfnet.nl (a Dutch Listserv list).
7.2 Technical
Use the DSA software as recommended by SURFnet (see section 4.2),
available through SURFdiensten bv, and use the SURFnet supplied
default configurations.
Use the DUA interfaces that are recommended by SURFnet (see section
4.4 and appendix A). For user access, small organisations can use
the centrally provided interfaces and LDAP server and large
organisations can set up their own access services.
A basic principle in Quipu X.500 is the principle that information in
one DSA is replicated in other DSAs. This reduces access time and
improves the quality of service (a DSA may be down, but the
information it contains is still available). When an organisation
is planning to run its own DSA, a certain level of replication in
the technical set-up has to be negotiated with other DSA-owners.
In order to obtain a good technical quality of service (performance
and user friendliness) the responsible system manager within your
organisation must join the SURFnet X.500 DSA managers group (send
e-mail to DSA-man@nic.surfnet.nl).
7.3 Legal
The legal registration of the Directory Service of your organisation
(as presented to the outside world) needs a clearly-defined purpose.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 26]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
Define this purpose in such a way that no legal constraints are
placed upon the information you want to make available. Remember
that offering only attributes for communication purposes eliminates
the legal obligation to register your contribution at the
Registration Chamber.
Inform persons who are to be included in the Directory well before
actually inserting their data. Draw up regulations concerning
additions, changes, deletions, and publicize these. Respect the
legal rights of individuals:
- to view the information stored about themselves;
- to demand restoration of faulty data on their person;
- to refuse being included in the Directory.
Use the SURF brochure 'De grenzen van het Paradijs' [24] to inform
yourself and others about the privacy and legal issues involved in
setting up a Directory Service in the Netherlands.
7.4 Data management
Determine the motivations for setting up a Directory Service within
your organisation, e.g.:
- replacing a paper telephone directory, paper e-mail address lists
and the like;
- making e-mail addresses easily available and up-to-date;
- improving personnel administration;
- etc.
Look for useful elements in the Directory that are not otherwise
obtainable to stimulate the use of the Directory, e.g., favourite
drink, scientific field of interest (in a university or research
environment), room number, private telephone number (for internal
use only!).
The primary motivation for setting up a Directory Service is the
provision of useful information that applies locally. Additional
benefits from participating in the SURFnet Directory Service, with
access to other Directory information on organisations all over the
world, should not be the main motivation to build and maintain a
Directory Service.
Achieve an executive level commitment to start a Directory Service.
This will make it much easier to get cooperation from people within
the organisation that are to be involved in setting up a Directory
Service.
Decide on the kind of data the Directory should contain and how it
should be structured. Follow the Internet and SURFnet
recommendations for structuring the data (according to the X.500
standard). See [4] and [12].
Define criteria for the quality of the data in the Directory, like
timeliness, update frequency, correctness, etc. Communicate these
criteria throughout the organisation and commit contributing
entities to the defined quality levels.
Use existing databases within the organisation to retrieve the data
you want to be part of the Directory, to the greatest extent
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 27]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
possible. Involve the people who maintain that data and make sure
to get a formal written commitment from them to use their data
source in the Directory. Rely on these people, since they have the
experience in management and control of local, available data.
Setting up a Directory Service not only requires a technical
solution, but mainly the solution of an administrative problem. A
balanced representation of the different disciplines involved in
setting up a Directory Service stimulates the quality and progress
of the tasks to be carried out.
8 References
[1] ITU (1993), The Directory - overview of concepts, models and
service. International Telecommunications Union, X.500 series
of Recommendations.
[2] Huizer, E (1992), Proposal for a X.500 Directory Services
Project, SURFnet EH/911533.
[3] Paradise (1991-1994), Paradise International Reports,
University College London, April 1991 - April 1994.
[4] Kille, S, et al (1993), A Strategic Plan for Deploying an
Internet X.500 Directory Service, RFC1430
[5] Huizer, E (1993), Building a Directory Service, Final Report
test phase SURFnet X.500 pilot project, SURFnet
[6] Chadwick, D (1994), Understanding the X.500 Directory, Chapman
& Hall, London
[7] Rose, M (1992), The little black book, Prentice Hall, Englewood
Cliffs (U.S.)
[8] Steedman, D (1993), The Directory standard and its application,
Technology Appraisals, Twickenham (U.K.)
[9] Weider, C, Feltstrom, P (1994), The Whois++ Directory Service,
Connexions, vol. 8, no. 12
[10] Foster, J (1994), A Status Report on Networked Information
Retrieval: Tools and Groups, RFC 1689
[11] Postel, J, Anderson, C (1994), White Pages meeting report,
RFC 1588
[12] Barker, P, Kille, S, Lenggenhager, T (1994), Naming and
Structuring Guidelines for X.500 Directory Pilots, RFC1617
[13] Kille, S (1991), Replication Requirements to provide an
Internet Directory using X.500, RFC1275.
[14] Kille, S (1991), Replication and Distributed Operations
extensions to provide an Internet Directory using X.500, RFC1276
[15] Getchell, and Sataluri (1994), A Revised Catalog of Available
X.500 Implementations, RFC 1632
[16] Harrenstien, Stahl, Feinler (1985), NICNAME/WHOIS, RFC954
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 28]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
[17] SYN287 (1992), Directive concerning the protection of
individuals in relation to the processing of personal data, The
council of the European Communities, Com(92)422 SYN287
[18] Hill, J (1992), The X.500 Directory Services: a discussion of
the concerns raised by the existence of a global Directory,
electronic networking, vol.2, no.1
[19] Barker, P (1994), Experiences in providing a White Pages
directory service based on the X.500 standard, Computer Networks
and ISDN Systems 26, pp. 1365-1374.
[20] Koechlin, B., Treca, K., Pays, P. (1994), Strangers in
Paradise, Proceedings INET'94/JENC5, 261
[21] Howes, T, et al. (1993), The X.500 string representation of
standard attribute syntaxes, RFC1488
[22] Yeong, W, et al. (1993), X.500 Lightweight Directory Access
Protocol, RFC1487
[23] Kille, S (1993), Using the OSI Directory to achieve User
Friendly Naming, RFC 1484
[24] Wijngaard (1994), A van de, De Grenzen van het Paradijs, ed.
A., SURF
9 Glossary
ACL Access Control List; a mechanism to restrict access to
data stored in an X.500 Directory Service.
Attribute Attributes belong to an entry in the Directory
Service, and contain information belonging to that
entry, e.g. surname=jurg (see section 2.1.1).
BLT BulkLoadTool; a tool to download an existing
database into a DSA.
cDSA See Central DSA
Central DSA A DSA that is shared by multiple organisations,
mostly SMOs, to make their data available in the
X.500 infrastructure. The DSA system is maintained
by a computing centre, the data is maintained by the
organisations that provide the data.
Centroid A type of index information used in the Whois++
standard and possibly used in an integrated
Directory Service.
DAP Directory Access Protocol; protocol used between a
DUA and a DSA, to access the Directory Information.
DE Directory Enquiry; an ascii-based DUA interface.
Directory Service An electronic database that contains information
on entities (e.g. people, services, organisations
etc.) and that is accessible over the network.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 29]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
DIT Directory Information Tree; the hierarchy of the
distributed database that makes up an X.500 service
(see section 2.1.2).
DS See Directory Service.
DSA Directory System Agent; system in an X.500
infrastructure that holds part of the Directory
Service data (see section 2.1.2).
DUA Directory User Agent; system in an X.500
infrastructure that is used to access the
information in the Directory Service.
Dutch Strange Anglo-Saxon word to indicate something or
someone from the Netherlands, or the language
spoken in the Netherlands.
E-mail Electronic mail.
Entry A Directory Service contains entries on people,
organisations, countries, etc. Entries belong to a
certain object class, and information on entries is
stored in attributes (see section 2.1.1).
EU European Union.
IDM Interactive Data Manager; a DUA interface that is
useful for maintaining a large set of data.
IP Internet Protocol; part of the popular TCP/IP suite
of protocols.
ISO International Organisation for Standardization.
Responsible for a wide range of standards,
including those relevant to networking. ISO is
responsible for the most popular networking
reference model and related standards: the OSI
reference model.
ITU International Telecommunication Union; (formerly
known as CCITT) a standards-making body for
telecommunication operators (PTTs). Responsible for
the OSI conformant X-series of recommendations (e.g.,
X.500, X.400 etc.).
Labelled URI Labelled Uniform Resource Identifier; see URL.
LDAP Lightweight Directory Access Protocol, an internet
standard [21] and [22] for a lightweight version of
DAP running over TCP/IP.
Master DSA A DSA that serves the entry for a country, and that
holds information on all DSAs available within that
country.
NeXor A commercial supplier that sells ISODE, Quipu and
PP based products.
NL The Netherlands.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 30]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
Object Class Entries in a Directory Service belong to an Object
Class to indicate their type and characteristics;
e.g., Object Class 'person' (see section 2.1.1).
OSI Open Standards Interconnection; an international
standardization program, facilitated by ISO and ITU to
develop standards for data networking.
Paradise A European Directory Services pilot and now
infrastructure in which SURFnet participates.
PEM Privacy Enhanced Mail; an Internet standard for
sending secure E-mail.
Quipu An implementation of the X.500(1988)
recommendations.
RFC Request For Comment, internet series of
publications.
RFC-1006 Internet standard that specifies how to run OSI
applications over TCP/IP.
SURFnet The academic and research network in the
Netherlands; URL:http://www.nic.surfnet.nl/surfnet/
surfnet.html.
TCP/IP Transmission Control Protocol and Internet Protocol,
the two best known Internet protocols, TCP
corresponds roughly to layer 4 of the OSI model
(the transport layer), IP corresponds to layer 3
(the network layer).
UFN User Friendly Naming; an internet standard for
identifying an entry in X.500 by a user friendly
name.
URL Uniform Resource Locator; an address for any
document on the Internet.
Whois++ An Internet directory services protocol; a possible
alternative for X.500.
WPS White Pages Service; a Directory Service that
contains (addressing) information on people and
organisations.
X.500 A series of recommendations as defined by the ITU,
that specify a Directory Services protocol.
10 Security Considerations
Security issues are not discussed in this memo.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 31]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
11 Authors' Addresses
Peter Jurg
SURFnet bv
PO Box 19035
3501 DA Utrecht
The Netherlands
Phone: +31 30 2305305
EMail: Peter.Jurg@SURFnet.nl
Erik Huizer
SURFnet bv
PO Box 19035
3501 DA Utrecht
The Netherlands
Phone: +31 30 2305305
EMail: Erik.Huizer@SURFnet.nl
Mark Jacobs
Stratix Consultancy bv
Triport 1, Evert vd Beekstraat
1118 ZP Amsterdam
The Netherlands
Phone: +31 020 4466555
EMail: mark.jacobs@stratix.nl
Evelijn Jeunink
University of Utrecht
Faculty of Law
Nobelstraat 2
3512 EN Utrecht
The Netherlands
Phone: +31 30 2537285
EMail: E.Jeunink@rgl.ruu.nl
Ton Verschuren
SURFnet bv
PO Box 19035
3501 DA Utrecht
The Netherlands
Phone: +31 30 2305305
EMail: Ton.Verschuren@SURFnet.nl
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 32]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
Appendix A: DUA interfaces
Date: January 5, 1995
This is a list of available DUA interfaces for interactive use of the
Directory via the Internet. The list is not complete, but should
provide new X.500 users with enough information to choose an
appropriate interface for accessing the Directory. The interfaces
in this list are end-user interfaces and not meant for data
management. Two types are distinguished: - standalone DUA interfaces
for end users; - DUA interfaces for end users integrated in other
applications.
All DUA software below use either DAP or LDAP on top of TCP/IP (using
RFC1006 in case of DAP) to access the Directory.
People who are interested in this information are recommended to read
Getchell (1994). The DUA interfaces that have been tested in the
SURFnet Directory Services project are marked with "(Test)". In such
cases, a brief summary of the test results is provided. The full
test reports will be available in html format through
www.nic.surfnet.nl (but probably only in Dutch).
A1 Standalone DUA interfaces
DE
A character-based Unix DUA interface that supports (from version 7.0)
both DAP (ISODE is needed) and LDAP. It supports authenticated
binding (even strong authentication), modifying and UFN.
URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software/x500/
unix-de/de-7.0.tar.Z
Freeware.
DOS-DE
This is the DOS version of Unix DE, which uses LDAP as access
protocol. It needs NCSA Telnet stack or SUN's PCNFS version 4.1 or
Novell's LAN Workplace for TCP/IP connectivity.
URL: ftp://info.nic.surfnet.nl/mirrorarchive/software/x500/
Freeware.
Max500 (Test)
Max500 is a DUA interface for Macintosh that uses LDAP as access
protocol. It supports UFN, authenticated binding and modifying.
Max500 also supports presentation of picture and sound attributes.
The latest version supports the labelled URL attribute and can use
some WWW clients as helper applications to connect to the URL that
is given in the value of this attribute. Max500 enables searching
and browsing.
URL:ftp://info.nic.surfnet.nl/mirrorarchive/software/x500/
Freeware.
Test results
Max500 has an attractive user interface, although the multiple
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 33]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
search options sometimes make it difficult to be used by
inexperienced users. It can run on almost any Macintosh
( >system 6.0.5).
Installation is easy, configuration is a little more difficult.
A disadvantage for use in Appletalk networks is that the
configuration preferences reside on the Mac that runs the
application. This means more work for system managers.
PCDUA
PCDUA is an LDAP based DUA interface for Windows. It uses Winsockets.
It supports no UFN, but authenticated binding and modifying is
possible.
URL:mailto:sales@nexor.co.uk
Commercial product.
PC-PAGES (Test)
PCPages is an LDAP based DUA interface for Windows. It uses
Winsockets. It supports UFN, but no authenticated binding (hence
no modifying).
URL:mailto:x.500@brunel.ac.uk
Commercial product.
Test results
PCPages has a rather elaborate installation procedure where .INI
files and OID tables have to be edited. However, the
documentation is good. PCPages also offers a user-friendly
interface. Searching and browsing is easy with PCPages.
Approximate searching could perform better. PCPages can be used
in combination with ECS Mail.
SLU
A character-based Unix DUA interface that supports DAP (ISODE is
needed).
URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software
/x500/slu/slu-1.1.tar.Z
SWIX (Test)
Swix is an LDAP-based DUA interface for Windows. It uses Winsockets.
It supports UFN, authenticated binding and modifying.
URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software
/x500/swix/swix21.exe
Freeware.
Test results
Swix is a relatively simple DUA interface with an easy
installation procedure and a good manual. It is recommended for
end-users. Swix cannot be linked to other programs (DDE) and the
representation of the entries could be better. Swix is good in
handling approximate searches, but the tested version had some
difficulties with multiple hits and did not perform too well when
searching was done with exact matches.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 34]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
UD
A simple character-based Unix DUA interface that comes with the LDAP
package and hence supports LDAP. It also supports UFN and
authenticated binding for modification of entries.
URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software
/x500/ldap/ldap-3.1.tar.Z
Freeware.
WDUA (Test)
WDUA is an LDAP based DUA interface for Windows. It uses Winsockets.
It supports UFN, authenticated binding and modifying.
URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software
/x500/wdua/wduainst.exe
Freeware
Test results
This DUA interface is recommended to data managers who have to
modify a relatively small number of entries. WDUA is a little too
complicated for ordinary users. One disadvantage is that it
cannot be linked to other Windows programs such as e-mail
clients, etc.
Some other DUA interfaces for Windows support such a feature
(DDE).
WINDUA
WINDUA is an LDAP-based DUA interface for Windows. It uses
Winsockets. It offers authenticated binding and modifying and it
supports a DDE server for links with other Windows applications.
URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software
/x500/windua/windua.zip
Freeware.
XT-DUA (Test)
XTDUA is an X-Windows DUA interface that supports authenticated
binding, modifying and UFN. It uses DAP/ISODE.
URL: mailto:sales@nexor.co.uk
Commercial software.
Test results
This DUA interface is recommended to data managers who have to
modify a relatively small number of entries. It is a little too
complicated for ordinary users. Some modifying functions are
somewhat too easy (one could easily delete all kinds of things).
It lacks a function to the same attribute in many simultaneous
entries.
XLU
XLU is a Motif and X-windows DUA interface that uses DAP/ISODE and
supports authenticated binding , modifying and UFN. It is the
'windows version of SLU'.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 35]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software/x500/xlu/
Freeware.
A2 Integrated DUA interfaces
gopher/X.500 gateway (Test)
This gateway provides a gopher interface to X.500 and runs on Unix
machines. The gateway uses LDAP as access protocol and provides a
browsing function and a one-level searching function. Authenticated
binding is not provided, but the latest version should support UFN.
URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software/x500/ldap/ (it
comes with the LDAP package)
Freeware
Test results
The gateway is easy to install, but must run on the same system
as the LDAP server (it uses some of the LDAP libraries). It uses
the inetdeamon which means that it does not have to run all the
time, but only when a request comes in. The interface is
particularly suited for inexperienced users, since it is simple,
but provides the basic functionality.
WWW/X.500 gateway (Test)
This gateway provides a WWW interface to X.500 and runs on Unix
machines. The gateway uses LDAP and provides a browsing function and
a one-level searching function. Authenticated binding (modifying)
is supported in a beta release. Display of attributes containing
pictures and sound is supported (if supported by the WWW client or
helper applications). The latest version also supports links from
the labeledURL attributes.
URL: ftp://isode.tu-chemnitz.de/pub/web500gw-1.5a.tar.Z
Freeware
Test results
The user documentation is not very good, but the gateway is not
too difficult to install. Filters for graphical format conversion
are provided. The interface offers a great functionality to a
large group of WWW users. However, searching sometimes leads to
strange results. Users have to gain some experience with the use
of the gateway.
Minuet with X.500 access (Test)
Minuet is a DOS client for WWW, gopher, e-mail, news and ftp. In a
beta-release an X.500 DUAS interface is also incorporated by means
of a SOLO implementation.
URL: ftp://boombox.micro.umn.edu/pub/pc/minuet/beta16/minuarc.exe
Shareware.
Test results
The software suffers from some typical beta-version drawbacks
(e.g., at every start-up the name of the SOLO server has to be
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 36]
INTERNET-DRAFT Introducing a Directory Service 16 October 1995
typed in). It only offers searching and not browsing (listing).
The results were rather poor, but this may be due to the use of
an experimental SOLO server in France (no SOLO servers outside of
France were available at that moment). Further tests are needed
with a LOCAL SOLO server.
Pegasus with X.500 access
Pegasus is an e-mail client for Internet and Novell networks that
runs on DOS, and Windows PCs and Macintoshes. In the first months
of 1995, it is expected that some Pegasus clients, starting with the
Windows client will have integrated X.500 access (LDAP). Not
available when this summary was compiled.
Freeware.
ATISmail with X.500 access
ATISmail is an e-mail client for Internet and Novell networks that
runs under Windows. It incorporates X.500 access by means of LDAP.
URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software
/simtel-win3/winsock/atisml04.zip
Shareware
CSO to X.500 gateway
A CSO server is a very popular non-distributed Directory Service for
which many clients (integrated in gopher or e-mail clients) are
available. The University of Utrecht wrote a small program that
translates between CSO and UD (see above). It enables LDAP access
to the X.500 Directory Service from CSO clients.
URL: ftp://info.nic.surfnet.nl/surfnet/projects
/x500/SURFnet-duas/ph-ud.tar.gz
Freeware.
Jurg, Huizer, Jacobs, Jeunink, Verschuren [Page 36]
