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]