Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_i/draft-ietf-ids-x500-intro-dir-00.txt

Text File | 1995-10-18 | 111KB | 2,397 lines

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:              [phone]
    Facsimile Telephone Number:    [phone]
    Mail:                          [e-mail]

    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 [phone]      [e-mail]
    Manchester Computing Centre
      2 L M Smith   [phone]    [e-mail]
      3 P E Smith   [phone]    [e-mail]
    University of Brighton
    Arch and Build Research Unit
      4 B.SMITH                         [e-mail]
       ..
       ..
       ..
       ..
      1229 E Smit [phone]
    School of Economic Studies - Dover Street Building
      1230 G Smith [phone]
    Whitworth Art Gallery
      1231 Alistair Smith [phone] 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 [e-mail]
    (subscribe through [e-mail], 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=[e-mail]');
    - 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 [e-mail] (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 [e-mail]).

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: [phone]
   EMail: [e-mail]


   Erik Huizer
   SURFnet bv
   PO Box 19035
   3501 DA Utrecht
   The Netherlands

   Phone: [phone]
   EMail: [e-mail]


   Mark Jacobs
   Stratix Consultancy bv
   Triport 1, Evert vd Beekstraat
   1118 ZP Amsterdam
   The Netherlands

   Phone: [phone]
   EMail: [e-mail]


   Evelijn Jeunink
   University of Utrecht
   Faculty of Law
   Nobelstraat 2
   3512 EN Utrecht
   The Netherlands

   Phone: [phone]
   EMail: [e-mail]


   Ton Verschuren
   SURFnet bv
   PO Box 19035
   3501 DA Utrecht
   The Netherlands

   Phone: [phone]
   EMail: [e-mail]









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:[e-mail]

    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:[e-mail]

    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:[e-mail]

    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]