idnits 2.17.1 draft-ietf-ids-x500-intro-dir-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 36 longer pages, the longest (page 2) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 43 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 215 has weird spacing: '...l under cons...' == Line 270 has weird spacing: '... uk de ...' == Line 1431 has weird spacing: '...ovinces org...' == Line 1436 has weird spacing: '... cities org...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 1995) is 10421 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 1430 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Downref: Normative reference to an Informational RFC: RFC 1689 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 1588 (ref. '11') ** Downref: Normative reference to an Informational RFC: RFC 1617 (ref. '12') ** Downref: Normative reference to an Informational RFC: RFC 1275 (ref. '13') ** Downref: Normative reference to an Historic RFC: RFC 1276 (ref. '14') ** Obsolete normative reference: RFC 1632 (ref. '15') (Obsoleted by RFC 2116) ** Obsolete normative reference: RFC 954 (ref. '16') (Obsoleted by RFC 3912) -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' ** Obsolete normative reference: RFC 1488 (ref. '21') (Obsoleted by RFC 1778) ** Obsolete normative reference: RFC 1487 (ref. '22') (Obsoleted by RFC 1777, RFC 3494) ** Obsolete normative reference: RFC 1484 (ref. '23') (Obsoleted by RFC 1781, RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '24' Summary: 20 errors (**), 0 flaws (~~), 7 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Peter Jurg 2 Erik Huizer 3 SURFnet bv 5 Mark Jacobs 6 Stratix Consultancy bv 8 Evelijn Jeunink 9 University of Utrecht 11 Ton Verschuren 12 SURFnet bv 14 October 1995 16 Introducing a Directory Service 17 Filename: draft-ietf-ids-x500-intro-dir-00.txt 19 Status of this Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 To learn the current status of any Internet-Draft, please check the 32 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 33 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 34 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 35 Rim). 37 This Internet Draft expires 1 March 1996. 39 Abstract 41 This report provides a 'manual' for establishing an electronic White 42 Pages Directory Service within an organisation and for connecting 43 it to a wide-area Directory infrastructure. It is based on the 44 experiences from the SURFnet Directory Services pilot project. The 45 wide-area service is of importance to all users of e-mail services 46 who want to find e-mail addresses of other e-mail users (worldwide!) 47 or any other address information such as telephone and fax 48 numbers. 50 Establishing a White Pages Directory Service within an organisation 51 includes a technical, legal and data management component. As the 52 amount of work involved in the technical component can be reduced 53 by using standard equipment and by good support from the provider 54 of the wide-area Directory infrastructure, the legal and data 55 management issues require more attention. Legal aspects include 57 formal registration of the service, informing all registered persons 58 about the service and data protection. 60 Data management concerns all issues that are related to collection, 61 publication and maintenance of the data. Experience gained in the 62 SURFnet project demonstrates that continuity in data management is 63 only feasible if the procedures for these activities are integrated 64 in existing procedures for paper or other electronic directories. 65 It also helps if there is a strong commitment from the higher 66 management to participate in a wide-area Directory Service. 68 Contents 70 1 Introduction 72 2 Introduction to Internet Directory Services 73 1. X.500 basics 74 2. Basics of Whois++ and index servers 75 3. Towards an integrated Directory Service 77 3 Legal issues 78 1. The EU directives on data protection 79 2. Information towards the registered people 80 3. Providing a purpose and regulations for the registration 81 4. Accuracy of the data 82 5. Protection of the data 84 4 Infrastructure 85 1. A well-maintained infrastructure 86 2. An easy-to-install-and-operate DSA 87 3. Multi-vendor DSA products 88 4. Directory User Agent (DUA) Interfaces 90 5 Data management and Operation of a Directory Service 91 1. Data management issues 92 2. Security issues 93 3. Towards the operational phase of the X.500 Directory Service 95 6 Main conclusions of the SURFnet Directory Services pilot 97 7 Recommendations for participants 98 1. General 99 2. Technical 100 3. Legal 101 4. Data management 103 8 References 105 9 Glossary 107 10 Security considerations 109 11 Authors' Addresses 111 Appendix A: DUA interfaces 113 1 Introduction 115 This report aims to offer an introduction to everyone faced with 116 building a Directory Service for an organisation. It describes the 117 results of the SURFnet Directory Services pilot project. As such, 118 it serves as an introduction to the various aspects of building a 119 Directory Service: Technical, Legal and Organisational. 121 1.1 Introduction to Directory Services 123 Effective e-mail communication can benefit from the existence of an 124 adequate global electronic White Pages service (i.e., a directory 125 service offering data on people) to enable network users to retrieve 126 the addresses of communication partners in a user-friendly way. As 127 the number of people connected to computer networks increases (and 128 it does so continuously, at least doubling each year!), it becomes 129 more difficult to track down people's electronic (mail) addresses. 130 Hence, in order to make global communication over computer networks 131 work, a global, electronic White Pages service is indispensable. 132 Such a service could also easily contain telephone and fax numbers 133 and postal addresses. Furthermore, electronic White Pages may prove 134 to be useful for specific local purposes, e.g., for replacing paper 135 directories or improving the quality of personnel administration. 136 Although several efforts are being made to develop a less 137 complicated approach, currently the most suitable technical solution 138 for the integration of a globally-distributed electronic White Pages 139 and a database for local purposes, is X.500 [1] (see chapter 2). 141 After some initial technical piloting with X.500, in 1992 SURFnet 142 decided to start a Directory Services pilot with the main goal of 143 establishing an operational X.500 Directory Service in SURFnet [2] 144 and join the international infrastructure based on X.500 technology 145 called 'Paradise' (Piloting An inteRnationAl DIrectory SErvice) 146 [3]. 148 Paradise contains about 1.5 million entries of individuals and 3,000 149 of organisations. Worldwide, 35 countries are involved. Paradise was 150 an EC project until April 1994. Now its operational tasks are 151 continued by DANTE. The goal of Paradise and related national 152 initiatives is to stimulate and extend the use of the X.500 White 153 Pages service. Within Paradise, attention is paid to technical and 154 organisational aspects. The Paradise infrastructure is mainly based 155 on the Internet Protocol. The specific issues that are related to 156 the use of the Internet Protocol for X.500 can be found in [4]. 158 This document supersedes a previous publication with the title 159 'Building a Directory Service' which is the final report of the test 160 phase of the SURFnet Directory project [5]. It contains the 161 experiences gained in three different pilots that were carried out 162 in the SURFnet project to achieve a broad introduction of X.500 163 Directory Services in the Dutch R&D community. Besides setting up 164 an X.500 infrastructure (and integrating it in the Paradise 165 infrastructure) and a study of the legal issues involved in setting 166 up a Directory Service, the project included technical and data 167 management pilots at 10 universities and the creation of a central 168 X.500 server that allows small and medium-sized organisations in 169 SURFnet to put up a Directory Service. The latter was a joint pilot 170 of SURFnet and the Dutch Ministry of Home Affairs, which benefits 171 both organisations. 173 Please note that many issues that are discussed in this report are 174 not specific to X.500, but are independent of the type of Directory 175 Service used. 177 1.2 Structure of this document 179 The first two chapters of this report provide the basic theoretical 180 knowledge a new site should have. Chapter 2 briefly describes the 181 X.500 protocol and some alternative Directory Services, while 182 chapter 3 gives a summary of the legal issues involved in setting 183 up a White Pages service. 185 Chapters 4 and 5 describe setting up an X.500 White Pages service in 186 practice. Chapter 4 describes the SURFnet Directory Service 187 infrastructure as it was created in the project, and presents an 188 overview of tested and available products for X.500 Directory 189 Services. Chapter 5 deals with the organisational issues encountered 190 in the pilot. In chapter 6 some conclusions are presented and 191 finally, in chapter 7, recommendations are made for new sites that 192 want to start deploying a Directory Service. 194 2 Introduction to Internet Directory Services 196 This chapter introduces the basics of the protocols that can be used 197 for setting up a White and Yellow Pages Directory Service on the 198 Internet. 200 A White or Yellow pages Directory Service on the Internet (and 201 connected networks) of any value should evidently have the 202 possibility of being maintained in a distributed way. Currently, the 203 X.500 protocol is the only solution available for such a Directory 204 Service. However, in the Internet community, work is continuing to 205 develop other solutions, offering functionality partly similar to 206 X.500 and partly complementary. This chapter discusses the basics 207 of the X.500 protocol and its service aspects. Then it briefly 208 discusses the basics of the newly-defined protocols (Whois++ and 209 index servers) and how these protocols can contribute to an 210 integrated Directory Service on the Internet that includes X.500, 211 Whois++ and still other services. 213 A concise introduction to the X.500 protocol can be found in [6]. 214 Other useful references are [7] and [8]. The Whois++ and index 215 server techniques are still under construction. Currently, 216 there are draft documents available by Peter Deutsch and Chris 217 Weider that are expected to become RFCs early in 1995. In [9] a 218 description of the functionality is given together with some 219 pointers to more information. The Whois++ service is discussed in 220 a more general context in [10] and [11]. 222 2.1 X.500 basics 224 X.500 is a standard for a Directory Service by the International 225 Telecommunications Union (ITU). The same standard is also published 226 by the ISO/IEC. The latest version of the standard is from 1993 [1]. 227 However, most of the current implementations still follow the 1988 228 version of the standard. 230 X.500 (1988) and X.500 (1993) differ in many aspects. The three most 231 important differences are mentioned below (knowledge references, 232 replication and access control). However, they remain compatible 233 in the most important aspects, those of interconnection and 234 interworking. 236 2.1.1 The Directory model 238 X.500 uses a distributed approach to realize a global Directory 239 Service. The idea is that local (communication oriented) information 240 of an organisation is maintained locally in one or more so-called 241 Directory System Agents (DSAs). Note that 'local' is a flexible 242 expression here: it is possible that one DSA keeps information of 243 more than one organisation. The opposite is also possible: Directory 244 data of one large organisation can reside in multiple DSAs, which 245 is still considered local from a service-provision point of view. 247 A DSA is essentially a database: 248 - in which the information is stored in a structure according to 249 the X.500 information model (see section 2.1.2); 250 - that has the ability, where necessary, to exchange data with 251 other DSAs through use of the Directory System Protocol (DSP) of 252 the X.500 recommendation set. 254 All DSAs in an X.500 Directory Service are interconnected according 255 to a predefined model, the Directory Information Tree (DIT). The DIT 256 is a virtual hierarchical data structure. In the White Pages 257 application it consists of a 'root', below which 'countries' are 258 defined. Below the countries (usually) 'organisations' are defined, 259 and below an organisation 'individuals', or additionally, 260 'organisational units', are defined (see the simplified illustration 261 below where only three countries and no organisational units are 262 presented). 264 The DIT is a representation of the global Directory. 266 root o 267 /|\ 268 / | \ 269 / | \ 270 countries uk de fr 271 / | /\ |\ 272 / | / \ | \ 273 organisations a b c d e f 274 | | | | | | 275 persons .. .. ... .... ... 277 Each DSA holds part of the global Directory and is able to find 278 out, through the hierarchical DIT structure, which DSA holds a 279 certain part of the Directory. This is done by means of 'knowledge 280 references'. Some implementors have chosen to use an alternative 281 approach for the X.500 (1988) version of this concept (since they 282 thought it was not appropriate), which resulted in 283 interoperability problems between DSA implementations by different 284 vendors (see section 4.3). The 1993 version of the standard should 285 solve these problems. 287 2.1.2 The information model 289 The X.500 standard defines the information model used in the 290 Directory Service. All information in the Directory is stored in 291 'entries', each of which belongs to at least one so-called 'object 292 class'. In the White Pages application of X.500 object classes are 293 defined, such as 'country', 'organisation', 'organisational unit' 294 and 'person'. 296 The actual information in an entry is determined by so-called 297 'attributes' which are contained in that entry. The object classes 298 to which an entry belongs define which types of attributes an 299 entry may use and hence, what information is specific for entries 300 belonging to that object class. The object class 'person' for 301 example, allows attribute types like 'common name', 'telephone 302 number', and 'e-mail address' to be used and the object class 303 'organisation' allows for attribute types like 'organisation name' 304 and 'business category'. Depending on its type, an attribute can 305 take one or more values. 307 At least one attribute value of the entry is used to specify a 308 name for an entry. The entry of a person is usually named after 309 the value of the attribute type 'common name'. 311 An example of an entry belonging to the object class 'person' is: 313 Attribute type Attribute value 315 Object Class: top person 316 Common Name: Peter Jurg P. Jurg 317 Surname: Jurg 318 Postal Address: SURFnet Postbus 19035 319 NL-3501 DA Utrecht 320 Telephone Number: +31 30 305305 321 Facsimile Telephone Number: +31 30 305329 322 Mail: jurg@surfnet.nl 324 The names that occur in the DIT are simply the names of entries. 325 Hence, the entry shown in figure 2.1 occurs in the DIT as the node 326 'Peter Jurg' below the node of the organisation 'SURFnet'. 328 The name of an entry must be unique at the level in the sub-tree 329 of the DIT to which the entry belongs. So if there are two people 330 called Peter Jurg at SURFnet, they must have a different first 331 value for the attribute type Common Name in their entries. 333 For further details on naming and information structure, the 334 reader is referred to [12]. 336 2.1.3 Service aspects of X.500 338 The standard does not describe how to distribute different parts 339 of the Directory amongst DSAs. The information corresponding to a 340 single node of the DIT (i.e., an entry for a country, organisation 341 or person) cannot be distributed over several DSAs, however the 342 information below and above that node in the DIT can reside on 343 different DSAs. In practice, a large organisation will maintain 344 one or more DSAs that hold its part of the Directory. Smaller 345 organisations may share a DSA with other organisations. The 346 distribution amongst the DSAs is totally transparent to the users 347 of the Directory. 349 Replication 350 An indispensable principle in a distributed Directory Service is 351 the notion of replication. If information of one DSA can be 352 replicated in another it reduces access time and improves the 353 quality of service (a DSA may be down, but the information it 354 contains is still available). However, the 1988 standard does not 355 provide a mechanism for this. The Quipu implementation of a (1988) 356 DSA provides a proprietary mechanism for several types of 357 replication which is used in the Paradise infrastructure 358 (documented in [13] and [14] ). See also section 4.3. 360 Directory User Agents 361 A user of the Directory can be a person or a computer. A user 362 accesses the Directory through a so-called Directory User Agent 363 (DUA). The DUA automatically contacts a nearby DSA by means of 364 which the user can search or browse through the DIT and retrieve 365 corresponding information. A DUA provides a standardized piece 366 of functionality that can be implemented in all sorts of user 367 interfaces. Therefore, users may access the Directory through 368 dedicated DUA interfaces or e-mail applications, for example. 369 Currently, most DUA interfaces to be used by people are 370 stand-alone applications, but it is expected that in the near 371 future many DUA interfaces will be integrated with other 372 applications. DUA interfaces for the White Pages service are 373 available for virtually all types of workstations (DOS, Macintosh 374 OS, Unix). For an overview of X.500 available software see 375 [15] or future updates. A shortlist of DUA interfaces 376 is provided in appendix A. 378 Access control mechanism 379 Owing to its access control possibilities, X.500 can be used 380 simultaneously for making available address information to the 381 outside world and for specific private Directory Service 382 applications restricted within an organisation. Whereas the 383 definitions of the DIT, object classes and attribute types of the 384 public White Pages information within an organisation have to 385 conform to those of the rest of world, the internal applications 386 may use their own DIT structure and their own definitions of 387 object classes and attributes (the values being only visible 388 within (a part of) the organisation). Nevertheless, one local 389 infrastructure can be used for both the public and private part 390 of the directory service. In order to make some information 391 visible within a (part of an) organisation only, access control 392 is used, which in practice may require some extra management. 393 Access control is only available in the 1993 version of the 394 standard. A proprietary mechanism is provided in the Quipu 395 implementation of the 1988 version. 397 Searching the Directory 398 X.500 offers the possibility to carry out searches at any level or 399 in any sub-tree of the DIT. In order to carry out a search, an 400 attribute type together with a value have to be specified. The 401 Directory then searches for all entries that contain an attribute 402 of that type with the given value. For example, in an organisation 403 one can search for all persons having a particular common name, or 404 all organisations within a country that have telecommunications as 405 their business category. It is up to the organisations that 406 maintain the DSA's to decide who may perform which searches and 407 also how many levels deep a search may be. Searches can be done 408 on the basis of an exact or approximate match. 410 Problem: Yellow Pages 411 Apart from the benefits mentioned previously, X.500 inevitably 412 also suffers from some drawbacks, of which the most important is 413 the lack of a clear definition for a Yellow Pages Service. 415 There are two obvious ways to set up a Yellow Pages Service in 416 X.500, but neither is encouraged. One way would simply be to use 417 the searching possibilities of X.500 as described above. However, 418 generally such searches would propagate through many DSAs, hence 419 taking up much of the performance of the network and the DSAs 420 themselves. Such searches, which are called 'distributed 421 searches', are generally not encouraged. In the Netherlands they 422 are not even allowed. Here is the output of a distributed 423 search in the UK (an X.500 search for common name 'Smith' in the UK 424 yields a list with 1231 hits and propagates through 425 all UK DSAs): 427 Initiating searches to 143 428 organisations................................ 429 Waiting for results (control-C to abandon outstanding searches)... 431 Liverpool John Moores University 432 COMPUTER SERVICES 433 1 MARK SMITH +44 51-231-2112 M.E.Smith@livjm.ac.uk 434 Manchester Computing Centre 435 2 L M Smith +44 161 275 6053 L.M.Smith@mcc.ac.uk 436 3 P E Smith +44 161 275 6084 P.E.Smith@mcc.ac.uk 437 University of Brighton 438 Arch and Build Research Unit 439 4 B.SMITH B.J.Smith@bton.ac.uk 440 .. 441 .. 442 .. 443 .. 444 1229 E Smit +44 161 275 2758 445 School of Economic Studies - Dover Street Building 446 1230 G Smith +44 161 275 4839 447 Whitworth Art Gallery 448 1231 Alistair Smith +44 161 273 6541 x31 450 A second way to build a Yellow Pages Service in X.500 would be by 451 means of a special DIT structure, for example a special branch at 452 some place in the DIT called YP, below which different business 453 categories or scientific branches could be found. However, the DIT 454 is already a problem as it is, since it suffers from the fact that 455 the world is not a clear hierarchical structure. It seems to be 456 very difficult in practice to agree upon the DIT structure between 457 different countries, service providers and/or participating 458 organisations. The standard provides the framework for the DIT, 459 but does not specify the actual structure. The problem is that any 460 user who wants to retrieve information from the Directory Service 461 or any algorithm which helps the user in doing this, needs to know 462 about the DIT structure. So if there is no uniform DIT structure, 463 users may encounter difficulties in finding the information they 464 seek. This fact, although it may seem very appealing at first, 465 also makes it very difficult to build a Yellow Pages Service by 466 using the DIT. 468 A possible solution for Yellow Pages could be to have index 469 servers that hold indexed information of the publicly available 470 entries in all DSAs. As an example one could think of a Dutch 471 index server which holds all organisation names with their 472 business category and a pointer to the DSA that actually holds the 473 address information of each organisation. One could search this 474 one index server for a certain business category and retrieve the 475 names and pointers of the organisations within this business 476 category. Subsequently, by using the pointers, the addresses of 477 one or more of these organisations can be retrieved. This service 478 will certainly reduce the number of distributed searches and still 479 allow Yellow Pages-like functionality. 481 Such a solution could be provided by the index service that is 482 originally defined for Whois++. There are also some ideas within 483 the Internet to set up DSA-based index servers. 485 2.2 Basics of Whois++ and index servers 487 2.2.1 The Whois++ information model 489 The original Whois model [16] defines a Directory 490 Service with a single database. Whois++ extends this service so 491 that it can reside on several databases, linked together by the 492 Whois++ index service. 494 The Whois++ information model is similar to the X.500 information 495 model. A Whois++ database contains a series of individual records 496 (compare the 'entries' in X.500), that hold the actual information 497 (compare the 'attributes' in X.500). The records are divided into 498 several types, e.g. 'Person' or 'Domain'. For each type a 499 different set of attributes is defined that a record may hold. 500 Such a set of attributes is called a 'template' and is the 501 equivalent of an object class in X.500. Two examples of records 502 of the type 'person' are: 504 Template: Person Template: Person 505 First-Name: Peter First-Name: Albert 506 Last-Name: Jurg Last-Name: Jurg 507 Favourite-Drink: Milk Favourite-Drink: Belgian beer 509 And of the type 'domain': 511 Template: Domain 512 Domain-Name: stratix.nl 513 Contact-Name: Mark Jacobs 515 Several other types, templates and attributes can be defined. 517 2.2.2 Whois++ index service (the directory model) 519 The Whois++ directory model is essentially different from X.500. 520 It does not define a hierarchical name structure like the X.500 521 DIT. Instead, it defines a space of index servers, the 'index 522 server mesh'. For each Whois++ server there is at least one index 523 server in the mesh that contains information about the contents of 524 that server in a specific format. The formatted information is 525 called a 'centroid' and comprises the templates and attributes 526 that are used within the Whois++ server, and contains a list of 527 the values that occur (in any record) for each attribute. As an 528 example we show what the centroid would be for a server holding 529 the three records above: 531 Template: Person 532 First-Name: Peter 533 Albert 534 Last-Name: Jurg 535 Favourite-Drink: Milk 536 Belgian beer 537 Template: Domain 538 Domain Name: stratix.nl 539 Contact Name: Mark 540 Jacobs 542 For each centroid, an index server has a pointer to the Whois++ 543 server from which it originates, thus providing an index of the 544 information of the Whois++ server. 546 Index servers can again be indexed by other index servers, hence 547 bringing some hierarchy to the index server mesh. However, this 548 hierarchy need not necessarily end up in a tree structure with one 549 top-level index server. In addition, crosslinks between index 550 servers can be made wherever needed. (Since cross-links may lead 551 to loops if a client follows the referrals given by index servers, 552 a client is responsible for loop detecting.) 554 2.2.3 Service aspects of Whois++ 556 Whois++ and the index service are totally search based. Browsing 557 through the directory is only possible if a client uses searches 558 to build lists of data. Since index servers can be built to hold 559 only particular types of records (organisations, persons, 560 physicists), Whois++ is particulary suitable for Yellow Pages 561 services. It can avoid large distributed searches. 563 Whois++ will have optional access control and replication. 565 2.3 Towards an integrated Directory Service 567 The idea of an integrated Directory Service is proposed in [11]. It 568 is best defined as a Meta-Directory Service that integrates existing 569 Directory Services such as X.500, Whois++, finger, etc. 571 Some work being undertaken in this area on the Internet. The IETF has 572 been working on a paper that defines the requirements and possible 573 options for such a service, which will be published as an RFC early 574 in 1995. Mike Schwartz has been implementing most of the ideas in 575 his Netfind application (a brief description can be found in [10]). 576 A simple ASCII-based protocol (called SOLO) for querying Directory 577 Servers and for constructing indexes is also under development in 578 the IETF. Finally, a team of implementors has agreed to run a pilot 579 with index servers (using the centroids indexing approach, see 580 section 2.1) and various Directory protocols in 1995. 582 3 Legal issues 584 This chapter discusses the legal issues involved in setting up a 585 Directory Service. It points out the restrictions that have to be 586 dealt with. For the deployment of an X.500 Directory Service, an 587 optimum has to be found between the extensive (technical) 588 possibilities of X.500 as described in the previous chapters and the 589 legal restrictions described in this chapter. 591 When a Directory Service includes the registration of personal data 592 it has to obey the rules as laid down in legislation on privacy 593 issues. Such legislation is intended to protect the privacy of 594 registered persons. Many countries around the world have introduced 595 privacy laws, although the consistency of legislation between 596 different nations is still lacking. However, the basic rules of most 597 privacy legislation do not differ too much. 599 In order to get an idea of the restrictions implied by privacy 600 legislation, we focus here on two directives of the European Union 601 (EU) that are intended to 'standardise' legislation on privacy 602 issues and provide a minimum level of protection. The Dutch law 'Wet 603 PersoonsRegistraties (WPR)' complies with the EU-directives. Hence, 604 the discussion here is entirely applicable to the Dutch situation 605 and probably applicable to the situation in other countries. 607 3.1 The EU directives on data protection 609 The EU has issued two directives concerning data protection, known 610 as SYN287 and SYN288 [17]. SYN287 is a general directive on which 611 we will focus here. SYN288 is more specific and intended only for 612 public digital communication networks, in particular ISDN. 614 The EU directive SYN287 assumes that the actual registration of the 615 data is functioning out of sight and beyond the control of the 616 person whose data are registered. The person in control of the 617 registration, i.e., the controller, is exclusively responsible for 618 the processing of the data. Processing means any operation or set 619 of operations performed on personal data, including collecting, 620 recording, storing, adapting, altering, consulting, using, 621 comparing, erasing, deleting. The registered person has the right 622 of obtaining information about the processing of his/her data. The 623 controller has responsibilities to meet the rights of the registered 624 person and has the responsibility to ensure that registered data are 625 protected against misuse, etc. 627 Another important rule in the directive is that one purpose of the 628 registration has to be defined by the controller. This purpose 629 implies which data can be made available by the controller. 631 Since it is possible in X.500 (and some other) Directory Services for 632 the registered person to manage parts of his/her own registration, 633 it would appear that the idea of a controller and registered person 634 do not strictly apply to such a networked Directory Service. 636 In the directive, the controller is not defined as the person who 637 maintains the data, but rather as the organisation or person who 638 facilitates the service. This implies that the responsibilities of 639 the controller, as implied by the law, apply to the system managers 640 and operators of all types of Directory Services (including X.500). 641 In the following sections we will describe these responsibilities 642 in more detail. 644 3.2 Information towards the registered people 646 The controller of the 647 data in a Directory Service has to inform the registered persons when 648 their data are first inserted and has to inform a registered person 649 about the processing of his/her data upon request. Generally, Directory 650 Services make it easy for a registered person to stay informed about 651 the registration, without interference by the controller. 653 3.3 Providing a purpose and regulations for the registration 655 The controller has to define a purpose for the registration. Personal 656 data may only be collected for specified, explicit and legitimate 657 purposes and used in a way compatible with those purposes. The 658 personal data must be relevant, adequate, and not excessive in 659 relation to the purpose. The EU directives require that a 660 supervisory authority be notified of the registration. In most 661 countries a regulation (or code of conduct) for the registration 662 made by an organisation or a group of organisations can be submitted 663 for approval to this national supervisory authority. Some, mostly 664 public, organisations are obliged to draw up a code of conduct 665 concerning the processing of personal data. The purpose of the 666 Directory Service can be described as: to facilitate and promote 667 easy communication and acquaintance amongst users on the network 668 by means of providing personal data via the network. The question 669 can be posed if this description is explicit enough. If it is, the 670 next question will be which data, related to the purpose, may be 671 collected. If we look at figure 3.1 below, the Favourite Drink and 672 the Photograph attributes are questionable. The Dutch supervisory 673 authority for approving registrations has advised not to incorporate 674 those attributes in the Dutch service. If the purpose of a Directory 675 Service is described as 'to facilitate communication', only 676 addressing attributes would be allowed, such as e-mail address, 677 postal address, title, telephone and fax. 679 More restrictive rules apply to sensitive data: data revealing racial 680 or ethnic origin, political opinions, religious beliefs, 681 philosophical or ethical persuasion or trade-union membership, and 682 data concerning health or sexual life. The directive generally 683 prohibits the processing of this type of data, though there are some 684 exceptions to the rule. It is clear, however, that sensitive data 685 should be excluded from Directory Services. The admission of 686 sensitive data exceeds the purpose and objective of the Directory 687 Service. 689 Problems might occur if the Directory Service allows the data 690 subjects to modify their own data. The data subject might enter 691 sensitive information in a free format field like the description 692 field. It could be argued that this is one of the exceptions to the 693 rule, since the subject has supplied the data under circumstances 694 where it must have been clear that it would be registered. However, 695 to ensure that the system manager is not held responsible by law, 696 it is recommended that data subjects are only able to alter their 697 own data in a controlled way. 699 3.4 Accuracy of the data 701 Ensuring the integrity of the data in the Directory Service is not 702 only essential for its usefulness, it is also the legal obligation 703 of the controller. 705 On the one hand, one could argue that the possibility for the 706 subjects of the Directory to modify their own data is a guarantee 707 for the accuracy of the data, provided there are sufficient 708 authorization and authentication procedures. On the other hand, this 709 self-management of the data carries the risk that inaccurate or 710 incomplete data are entered in the Directory, intentionally or by 711 mistake, and are not corrected. Clear descriptions of the demanded 712 data, if possible, imperative formats, and up-date procedures will 713 contribute to the accuracy. 715 3.5 Protection of the data 717 The controller must take appropriate technical and organisational 718 measures to protect the data against accidental or unlawful 719 destruction, and accidental loss, and against unauthorized 720 alteration or disclosure, or any other unauthorized form of 721 processing. There should be a suitable level of security with 722 respect to integrity, the nature of the data and the potential risks 723 involved. The local protection of data is left to the implementors 724 of the Directory Service applications. This means that a good 725 Directory Services implementation provides tools to protect against 726 destruction, falsification and loss of personal data. 728 By definition, a Directory Service has a high degree of accessibility, 729 which makes it difficult to prevent unintended use of data for 730 direct-mail, junk-mail and other forms of unwanted mail. Many 731 potential Directory subjects have expressed fears that they will 732 be inundated with massive sales campaigns, requests for information 733 or abusive messages [18]. Establishing and maintaining rules to 734 prevent this can never be fully successful. 736 Most implementations of Directory Services do not leave much room for 737 technological barriers against misuse of data. However, a Directory 738 Services application can be implemented in such a way that the 739 resulting entries from one organisation per search or per user is 740 limited to a small number. This will, of course, also affect the 741 legitimate user who tries to find colleagues on the basis of scarce 742 pointers. Nevertheless, in order to prevent the misuse of data, it 743 is recommended to restrict the search possibilities of the Directory 744 Service. 746 4 Infrastructure 748 Since the purpose of the SURFnet pilot was to facilitate a broad 749 introduction of Directory Services in the Dutch R&D community, it 750 was necessary to set up a Dutch infrastructure that allows newcomers 751 to join in a relatively easy way. To achieve this, the following 752 infrastructural aspects had to be investigated and, if possible, 753 established in the pilot: 755 - a well-maintained X.500 infrastructure, integrated in the Paradise 756 infrastructure, facilitating easy data maintenance and access 757 procedures; 758 - an open infrastructure, supporting a multi-vendor environment; 759 - at least one easy-to-install-and-operate DSA product should be 760 available; 761 - a selection of good DUA interfaces should be available (both for 762 maintaining data and for querying the X.500 Directory Service). 764 The sections below describe how these aspects were covered in the 765 project. For further reading, [19] is recommended. 767 4.1 A well-maintained infrastructure 769 In the pilot, the following infrastructural services were established 770 by SURFnet which are essential for making data available in the 771 global DIT: 773 - access to the root-of-the-world node in the DIT, which is offered 774 by Paradise, has been established, hence providing the integration 775 in the global DIT; 776 - a so-called master-DSA for the Netherlands has 777 been set up, representing the top-level node in the DIT for the 778 Netherlands. Apart from country-level information, this DSA also 779 replicates the root of the DIT as well as data from master DSAs of 780 most other countries; 781 - a so-called central DSA service has been implemented, through 782 which small and medium-sized organisations have the possibility 783 of making their Directory information available in 784 the Dutch section of Paradise DIT, without having to install their 785 own DSA. A character-based public access DUA interface was 786 installed as part of the central DSA service. 788 Besides these infrastructural services, a team of DSA managers was 789 created. These are the operational managers of Dutch DSAs who 790 communicate through the distribution list dsa-man@nic.surfnet.nl 791 (subscribe through listserv@nic.surfnet.nl, also available as 792 newsgroup nl.surfnet.dsa-man). This group meets regularly to discuss 793 and monitor the SURFnet DIT structure, schedule management, quality 794 of the service (e.g., performance), etc. With respect to the quality 795 of the service, it can be noted that a so-called probe is running 796 from one of the sites, which periodically tests whether the Dutch 797 organisational DSAs are up and running. The probe software was 798 provided by Nexor Ltd. Finally, to assist new organisations in 799 getting their DSA up and running, the necessary information (EDB 800 files, a Quipu specific format; see section 4.2) of the root and 801 c=NL is available via ftp. 803 Early in 1995, ten Dutch universities were connected to the 804 infrastructure (also see chapter 5). 806 4.2 An easy-to-install-and-operate 808 DSA SURFnet uses the NeXor XT-Quipu DSA. This DSA has been tested 809 successfully with respect to ease of installation and configuration. 810 It is recommended that short-term participants in the SURFnet 811 Directory Service use DSAs running the NeXor XT-Quipu software. To 812 accommodate this, SURFnet and SURFdiensten (a company that effects 813 software licenses for the Dutch educational community) have 814 negotiated a support contract for this software with NeXor. 816 The operation of the currently available DSAs is still not a trivial 817 task. While awaiting new software for DSAs (e.g., according to the 818 1993 version of the X.500 standard) that is easier to manage, 819 SURFnet relies on the team of DSA managers to support new 820 participants. In 1994, SURFnet organized a course on NeXor XT-Quipu 821 DSA management for the team of DSA managers, particularly the 822 newcomers. 824 4.3 Multi-vendor DSA products 826 Where the Dutch X.500 infrastructure currently consists of Quipu 827 DSAs, the Paradise infrastructure also contains other DSAs. A 828 thorough interworking test in the Paradise pilot, including Quipu 829 and two other DSAs, was carried out at INRIA (the French Research 830 Institute in Computer Science). A report of this test is available 831 [20]. We cite some of the conclusions from this report: 833 - the replication and knowledge information add-ons to X.500, as 834 defined in RFC1276 [14], which are used in the Quipu implementation 835 (also see section 2.1.3) are efficient, but do not allow good 836 interworking of Quipu with other implementations in practice; 837 - effective, broad deployment of X.500-based services will impose 838 conformance to the '93 version of the standard. This will alleviate 839 most of the interoperability and interworking problems that have 840 been encountered so far, largely because key factors, such as 841 knowledge representation and the replication mechanism, are now 842 specified; 843 - a set of requirements on the "opening" of any X.500 service 844 (comparable to the Internet hosts requirements) should be 845 established, which includes for example: 847 - no server exists without at least one back-up with a 848 separate network access; 849 - no first-level server exists without a one-level copy of 850 its subordinate entries; 851 - distribution of a naming context (knowledge information) 852 should include that same one-level replication in order 853 to make all one-level searches extremely efficient; 854 - a set of requirements on acceptable and recommended 855 behaviour is established to provide a framework for 856 designers and developers of DUA interfaces to avoid 857 poorly-designed DUA interfaces breaking down the whole 858 service. 860 4.4 Directory User Agent (DUA) Interfaces 862 Currently, there are two types of user interfaces available for 863 accessing the Directory: 865 - DUA interfaces for data managers; 866 - DUA interfaces for end users. 868 4.4.1 DUA interfaces for data managers 870 Examples of DUA interfaces for data managers (for maintaining 871 Directory data) are IDM (Interactive Data Manager) and BLT 872 (BulkLoadTool) as developed by University College London for the 873 Paradise project. IDM can be tailored to fit all kinds of needs and 874 is good for use by inexperienced data managers. However, IDM has 875 some limitations, one of them being its interactive nature. BLT is 876 particularly suitable for: 878 - initial loads. After the initial bulk load, the Directory data 879 can be managed interactively, e.g., by using IDM; 880 - remote execution of update procedures within relatively 881 large organisations and/or organisations with a high rate of 882 change; 883 - combining data from different sources. 885 However, BLT asks for a well-defined format and well-defined update 886 procedures and has a relative lack of robustness: it is easily 887 thwarted by input that does not follow its strict syntax rules. 888 Also, error messages are often presented in places where an 889 inexperienced user would not expect them, this often not being the 890 place where the error occurs. (In this, the BLT very much resembles 891 compilers of the old days.) 893 4.4.2 DUA interfaces for end users 895 A summary of available standalone and integrated DUA interfaces for 896 end users and test results of some of these can be found in Appendix 897 A. During the project, eight DUA interfaces for end users were 898 tested. A list of requirements was put together to support the tests 899 of DUA interfaces. The most important requirements are listed 900 here: 902 - DUA interfaces for end-user workstations should support one of the 903 available lightweight Directory Access Protocols. Currently these 904 are: 905 - the standardized Lightweight Directory Access Protocol (LDAP; 906 see [21] and [22]), which offers almost the same functionality 907 as the Directory Access Protocol (DAP, the full OSI standard 908 for accessing the Directory), but it does not have the 909 overhead of the various OSI layers and it only runs on top of 910 TCP/IP; 911 - the Simple Object LOok-up protocol (SOLO; work in progress, 912 see section 2.4). that also runs on top of TCP/IP. 913 Implementing such a product on a Macintosh or PC requires 914 far less effort than implementing the full OSI stack together 915 with DAP. 916 - Installation and configuration of a DUA interface should be simple, 917 and good documentation should be available; 918 - A DUA interface should present the information in a user-friendly 919 way. E.g., not present all attribute types (the attribute type 920 object Class is of no use to the general user) or OIDs (Object 921 IDentifiers that uniquely determine object classes and attribute 922 types) or plainly present the information it receives back from the 923 DSA (such as 'rfc822Mailbox=Peter.Jurg@SURFnet.nl'); 924 - A DUA interface should offer the possibility to use User-Friendly 925 Naming (UFN, defined in [23]) in order to find the entries of 926 people. A UFN for the entry of 'Peter Jurg' in X.500 (see section 927 2.1) would be 'jurg,surfnet,nl'. A DUA interface should accept this 928 as input and use a particular algorithm to find the entries that 929 belong to it; 930 - A DUA interface should support some basic functionality, such as: 931 - browse (list); 932 - search on different types of attributes; 933 - bind/authentication (modification of entries). 935 The fact that many attractive user interfaces already exist that meet 936 these requirements is mostly thanks to LDAP, and the instant 937 availability of LDAP libraries for Unix, DOS and Macintosh platforms 938 (courtesy University of Michigan). 940 In the SURFnet project an effort was made to establish integration of 941 DUA functionality in popular e-mail client software. The results 942 were not available during the project, but will become available 943 early in 1995. The current, or soon to be available, implementations 944 are listed in appendix A. 946 4.4.3 Centrally provided access services within SURFnet 948 One interface, Directory Enquiry (DE) as developed by University 949 College London for the Paradise project, was selected as the best 950 interface for 'dumb' terminals. The interface was translated into 951 Dutch, and installed as the SURFnet public Directory user interface. 952 This interface is now available to all users who do not have a local 953 DUA interface installed. Access to the public DUA interface is open 954 for telnet (TCP/IP). 956 Two interfaces that are available through the SURFnet Information 957 server are the gopher (URL: gopher://ldap.surfnet.nl:7777) and WWW 958 (URL: http://ldap.surfnet.nl:8888) gateways to X.500. The WWW 959 gateway can handle the 'labeledURL' attribute (this is a 960 non-standard attribute type which will be changed to a 'labeledURI' 961 attribute type) that enables connecting back from X.500 to WWW. 962 These gateways can be accessed by means of standard gopher- and 963 WWW-client software. Although the functionality of the gateways does 964 not meet the functionality of DE, both gateways have become popular 965 during the project, as they integrate X.500 with the frequently-used 966 navigation/information services on the Internet. Moreover, the 967 SURFnet public DUA (DE) was also inserted in the Gopher menu at the 968 SURFnet Information server. 970 To allow for the use of LDAP based DUA interfaces, SURFnet installed 971 an LDAP server. LDAP DUA interfaces used within SURFnet can connect 972 to this server (ldap.surfnet.nl) and the server translates the LDAP 973 queries into X.500 DAP queries. In 1995, as soon as the SOLO 974 protocol and server have been fully developed, SURFnet will also 975 install a SOLO server with similar functionality. 977 5 Data management and Operation of a Directory Service 979 This chapter describes the main results of the experiences with 980 respect to data management of the participants in the SURFnet 981 Directory Services pilot project (sections 5.1 and 5.2) and the 982 experiences of SURFnet with respect to the operation of a large 983 Directory Service (section 5.3). 985 At the start of the project, a difference was assumed between large, 986 medium-sized and small organisations. Hence, each of these 987 organisation classes was involved in the data management pilot 988 project. 990 The experience gained in data management in the Directory Service was 991 collected from contributions of 10 universities, 5 government 992 departments, 8 medium-sized organisations and 4 small organisations 993 (up to 25 persons). 995 Although basically the project was directed towards the use of X.500, 996 the experiences of the data-management pilot are largely independent 997 of the underlying technology. Therefore, the results and conclusions 998 in this chapter may be equally valid for Directory Services of 999 different nature (e.g. Whois++). 1001 5.1 Data-management issues 1003 The SURFnet project proved that organising data management requires 1004 a considerable effort. However, if data-maintenance procedures for 1005 a Directory Service are embedded in existing operations of data 1006 within an organisation, the extra effort for operations is minimal. 1008 This section points out how to set up data management for a 1009 Directory Service in effective way. 1011 In order to get a good start with organizing data management and to 1012 obtain an incentive for the cooperation of various departments in 1013 large organisations, a management commitment was required from all 1014 participating organisations. 1016 5.1.1 The necessity of a high-quality Directory Service 1018 The value of a Directory Service from the user's point of view (and 1019 therefore also from the participating organisation's point of view) 1020 mainly depends on quality: 1022 - the quality of network and communication services that include 1023 availability, accessibility, performance and robustness of the 1024 Directory Service (these are discussed in some detail in chapter 4). 1025 - the quality of the information offered by the Directory Service, 1026 including the following parameters: 1027 - availability (e.g. number of hits per 1000 queries); - accuracy 1028 (e.g. number of error-free Directory records in a sample of 100); 1029 - completeness (e.g. number of complete records in a sample of 100 1030 Directory records, 'complete' to be defined); 1031 - information richness (e.g. number of useful attributes per entry). 1033 If standards are set for the quality of information parameters, this 1034 will enable the impartial measurement of informational quality 1035 contributions by individual organisations to Directory Services 1036 operations. Publication of statistics on this subject may encourage 1037 competition between organisations, thereby improving the Quality 1038 of Directory Service (QODS) as a whole. Various technically 1039 different solutions for Directory Services should be compared as 1040 well as various services based on the same technology (e.g. Paradise 1041 vs. other X.500 implementations). 1043 A high-level QODS, to be achieved by quality standards and healthy 1044 competition, will broaden the support for both the use of Directory 1045 Services and the effort to contribute to them. 1047 5.1.2 No need for new administrative procedures 1049 For the acceptance of a Directory Service within an organisation it 1050 is of vital importance that as little structural overhead as 1051 possible is used for the maintenance of the Directory data. This can 1052 be achieved by embedding the maintenance of Directory information 1053 within existing procedures for the maintenance of personnel (and 1054 student) databases. An even better solution is the implementation 1055 of an automated Directory update process based on data from existing 1056 source databases. The creation of completely new administrative 1057 procedures for datamanagement is strongly discouraged, as these 1058 carry the risk of not being executed properly, resulting in a 1059 degradation of the Directory information quality. 1061 5.1.3 Spreading the load caused by management activity 1063 Data management and maintenance of the QODS proved to be important 1064 activities. As the number of Directory contributors grows, these 1065 activities may develop a significant traffic volume and processing 1066 load. This should never hinder the performance of the Directory for 1067 people or processes executing information searches. Searching and 1068 browsing activities should have priority over data management. 1069 Moreover, simultaneous data management activities of several 1070 organisations must not interfere with each another, both with 1071 respect to the information contents and the performance of the 1072 Directory Service. One way or another, methods have to be found with 1073 which spread the network traffic and DSA processing load caused by 1074 organisations carrying out their data management jobs. Particularly 1075 in multi-user DSAs, such as the Dutch central DSA for example, this 1076 is mainly a matter of allocating well-chosen timeslots for data 1077 management to contributing organisations. 1079 5.1.4 Continuity in datamanagement: a matter of organisation 1081 As stated above, continuity in data management has to be created by 1082 effectively combining existing procedures and databases of personnel 1083 and relation-management processes. However, these processes are 1084 highly dependent on the size of the organisation. We will therefore 1085 take a closer look at how things work within organisations of 1086 various sizes. 1088 Large organisations: coordination and commitment Universities, 1089 administrative agencies and other large institutions usually consist 1090 of a number of more or less autonomous units: faculties, 1091 departments, etc. Each unit may have its own staff and/or student 1092 administration system where Directory data can be derived from. 1093 Additional information, such as room numbers, phone numbers, e-mail 1094 addresses, etc., may be supplied by other systems, centralized, 1095 departmental or application-specific (e.g. the telephone directory 1096 application). In cases where Directory data are extracted from 1097 various data sources, the cooperation of the managers of these 1098 sources must be gained. Also, some coordination effort must be made 1099 to synchronize the databases and to establish an efficient process 1100 for the periodical data collection from various sources, maximizing 1101 the actuality of the data. Multi-party cooperation may be enabled 1102 by a written management commitment from the Board level of an 1103 institution (this was required in the SURFnet project before 1104 participation was granted). However, as reported by some 1105 universities, enthusiasm, a good understanding of the importance 1106 of Directory Services and, particularly the possible benefits for 1107 existing management efforts, have a much greater impact on the 1108 willingness for cooperation. Management commitment, although 1109 necessary for the legal basis of the participation of an 1110 organisation in Directory Services, should not be used to enforce 1111 cooperation in an early stage of the project. 1113 Medium-sized organisations: commitment and enthusiasm In organisations 1114 with no more than a few hundred people (employees, students, etc.) 1115 the foremost problem is generally not cooperation of several data 1116 managers and coordination of their activities. Often, the data 1117 source for the Directory Service is in one or a few administrative 1118 systems, managed either by one IS manager or by a small IS 1119 department with employees who are organised to cooperate. A major 1120 problem in this type of organisation is time, or priority. As the 1121 systems department is responsible for all IS activities, generally 1122 a great deal of time is spent on day-to-day management activities, 1123 such as user support and trouble-shooting, and time for development 1124 activities is scarce. Furthermore, the remaining resources for IS 1125 development are rather spent on applications related to the 1126 company's primary processes than on organisation supportive 1127 applications such as Directory Services. As the IS manager or IS 1128 department is quite autonomous within medium-sized organisations, 1129 commitment to Directory Services has to be generated within this 1130 department. An enthusiastic 'project champion' is necessary to 1131 continuously push the organisation through the project activities. 1132 This employee must have a sound understanding of the value of 1133 Directory Services for the organisation, knowledge of the 1134 organisational issues and the ability to convince sceptic people 1135 within the organisation of the importance of allocating resources 1136 to Directory Services. Special attention is also needed for 1137 Directory maintenance. 1139 Small organisations: how to implement continuity? Continuity is also a 1140 key issue within small organisations, as the frequency of data 1141 management activities within such organisations generally is far too 1142 low to maintain the skills needed for updating. Usually, there is 1143 no link between the Directory data and some personnel management 1144 system or any other kind of database. The Directory data are simply 1145 fed manually into the Directory (in the Dutch data management pilot 1146 this is the central DSA provided by SURFnet). This involves a 1147 serious risk of a one-time action to fill the Directory, which is 1148 then not maintained afterwards. Since small organisations almost 1149 always make use of an external database (DSA), a possible solution 1150 to this problem may be to have the updates done by the system 1151 manager of that system. The small organisation can provide the 1152 system manager with the necessary information by fax or e-mail. The 1153 SURFnet central DSA service provides such a service. 1155 5.2 Security issues 1157 Operation of a Directory Service includes some security threats. 1158 These will be discussed in this section. Both the protection of 1159 confidential information in the Directory and the robustness against 1160 faulty actions of (inexperienced) data managers are items of 1161 interest. However, during the data management pilot project, no 1162 potential security threats from end users have been traced or 1163 otherwise disclosed. 1165 5.2.1 Risks involved in actions of non-experienced data managers 1167 As data managers are more privileged than other users of Directory 1168 Services, they are able to influence to some extent the operation 1169 of the systems the service has been built on. In particular, data 1170 managers who do uploads in a central DSA that holds information of 1171 many organisations may cause a major malfunction of the service. 1172 In the SURFnet project the robustness of the central DSA against 1173 uploading errors emerged as an item of interest when the 1174 introduction of the Bulkload tool (BLT, see section 4.4.1) for data 1175 managers was discussed. At least one case has been identified where 1176 the central DSA crashed upon entering a defective set of 1177 organisational data into the central DSA. Since then prevention of 1178 such a situation has been part of the instruction for remote 1179 BLT-users. 1181 In general, the problem of malfunctional uploads can be prevented by 1182 training data managers, implementing procedural checks, back-out 1183 procedures, and so on. Of course, Directory data collection will 1184 never affect the data in the source systems. Therefore, the data 1185 manager may invoke the selection and delivery process within the 1186 contributing systems, but he must not be authorized to make changes 1187 in those databases. 1189 5.2.2 Protecting information (systems) of contributing organisations 1191 There are no possibilities to gain access to corporate information 1192 systems of participating organisations from the X.500 Directory 1193 Services infrastructure. Directory data are generally stored in 1194 different systems from the corporate administrative systems. 1195 Periodically, Directory data are retrieved from corporate systems 1196 into an intermediate file on a local system of the contributing 1197 organisation. After a merge of various such files into a 1198 bulkloadtool formatted file and a final check, the connection is 1199 made to either the local DSA of the institution or the central DSA 1200 and the file is sent over for bulkload processing. 1202 By downloading the actual Directory information and comparing it with 1203 the original BLT-formatted file, a check for unauthorised 1204 modification of the latter file (which is only a theoretical 1205 possibility) can be executed. 1207 5.2.3 Protecting the privacy of registered people 1209 Chapter 3 discusses the implications of privacy laws with respect 1210 to data management. Special attention is needed when internally 1211 visible data in an organisation should differ from externally 1212 visible data. In that case, a thorough authentication mechanism 1213 should prevent users from outside being able to view the internally 1214 available data. A pragmatic approach to achieve this would be to 1215 install a gopher or WWW gateway (see section 4.4) that is only 1216 available to (a group of) users inside the organisation and uses 1217 authentication to display the data that is meant for these users 1218 only. Such a solution obviates the need for every individual user 1219 in the organisation for a userid/password combination for accessing 1220 this data. 1222 Attention must also be paid to data replication. According to the 1223 European law (see chapter 3), the system manager of a database (DSA) 1224 is responsible for the privacy aspects of data that are held in the 1225 database, as well as data that are replicated from another 1226 database! 1228 Generally, the data subjects of a Directory Service have to be 1229 informed about the presence of their data in the Directory. 1230 Publication of this fact in media that are available to all data 1231 subjects is sufficient. However, one must ensure that this is indeed 1232 the case! 1234 5.3 Towards the operational phase of the X.500 Directory Service 1236 This section discusses the possibilities to set up an 1237 economically-sound Directory Service. This is not a trivial task, 1238 as the established Directory Service in this project is a product 1239 of joint work, based to a large extent on voluntarily contributed 1240 effort. Who is responsible for the service? Who has the right and 1241 means to enforce participants to continuously supply high volumes 1242 of correct and current data? Who will pay for the service, and how 1243 much...? Some questions that will be discussed in the sections 1244 below. 1246 5.3.1 Quality of service management 1248 In general, every organisation that participates in a distributed 1249 Directory Service such as X.500, is responsible for its own part 1250 of the data and its own database in the whole service. Only the 1251 structure of the X.500 DIT (see section 2.1.2) may reside under the 1252 responsibility of a central organisation in a country (see also 1253 section 5.3.4). Other issues, such as the quality of the service 1254 as a whole, can only be the responsibility of a union of 1255 participants. Hence, the quality of a Directory Service demands the 1256 close cooperation of all participating organisations. 1258 In the SURFnet Directory Service, SURFnet assumes responsibility for 1259 the central part of the service, i.e., the structure of the DIT, the 1260 international connectivity, the (top level) master DSA, the central 1261 DSA and some centrally managed DUA interfaces and an LDAP server. 1262 The quality of the remaining part of the service is guaranteed by 1263 two different user groups and a special advisory board. The user 1264 groups are a data managers group and the DSA managers group referred 1265 to in section 4.3. The advisory board (consisting of a small number 1266 of Directory Services experts from the participating organisations) 1267 will advise SURFnet on the minimum service quality requirements that 1268 have to be met by all participating organisations in the SURFnet 1269 service in order to run an acceptable service. This recommendation 1270 will be discussed in the user groups and will be revised if their 1271 response requires it. SURFnet will ensure that the requirements that 1272 are agreed upon are met by all participants. 1274 The issues concerning the quality of service that must be tackled are 1275 summarized in section 5.1.1. A branch in the DIT of organisations 1276 that does not meet the requirements (which might well be the case 1277 for organisations that are just starting) could be marked as 1278 'experimental'. 1280 5.3.2 When will organisations join the service? 1282 As soon as the service has a good quality (in particular with respect 1283 to completeness and available user interfaces), new organisations 1284 will certainly be interested to join. However, before the 'critical 1285 mass' has been reached, special incentive projects (such as SURFnet 1286 Directory Services pilot project) are required. 1288 However, other motivations may also play a role. Organisations may 1289 also use a Directory Service for internal purposes (perhaps using 1290 data that is only available inside the organisation). For example, 1291 the Directory Service may replace a paper telephone directory and 1292 save costs. Or its introduction may be used to revise or improve the 1293 internal administrative procedures. The latter was the outcome for 1294 almost all large organisations within the group of participants in 1295 the SURFnet project. In many cases the administrative procedures 1296 were improved 'on the fly'. 1298 5.3.3 A financially self supporting Directory Service 1300 Transforming the X.500 Directory Service from the project stage into 1301 an operational service raises the issue of how to generate the 1302 revenues needed to cover operational costs. Who is going to pay for 1303 investments in the DSA infrastructure, who is going to pay the data 1304 management costs? 1306 In a White Pages Directory Service there are generally three parties 1307 involved: the users who want access to the Directory, the 1308 information providers who maintain the Directory information in DSAs 1309 and the wide-area network service providers who maintain a 1310 (national, regional, etc.) infrastructure that interconnects the 1311 DSAs and may provide basic access services (ldap server, etc.; see 1312 section 4.1). 1314 Current charging models for information services show two types of 1315 charging: 1317 - a straightforward approach in which users pay directly 1318 for the use of the service on a volume-dependent basis; 1319 - an approach where the information providers pay for all the costs, 1320 since they view the service as marketing platform. 1322 The first approach is difficult to apply to a Directory Service as 1323 described here, since such a service has a distributed and 1324 international character. It requires elaborate accounting and 1325 administrative tools that can distinguish between the retrieval of 1326 address entries of different organisations, national traffic and 1327 international traffic, etc. Owing to the complexity of this approach 1328 in the case of a Directory Service, volume-based tariffs are not 1329 considered with respect to the Directory Service within SURFnet. 1330 An example of the second approach is the World Wide Web (WWW) on the 1331 Internet. In order to make information available via WWW, many 1332 information providers pay for connection costs (of their servers) 1333 and for their own efforts to maintain the information. The users pay 1334 for basic access to the Internet, but no additional costs for the 1335 use of WWW. Of course, information providers view upon WWW as a 1336 marketing platform. They assume that eventually users repay their 1337 efforts by buying other products or services from them. However, a 1338 marketing value cannot be assumed for a White Pages information 1339 service, particularly where it concerns information of 1340 non-commercial organisations. Hence this approach will probably not 1341 be used for the SURFnet Directory Service. 1343 Another model could be to regard the Directory Service as an 1344 infrastructural service, which is an integral part of other services 1345 such as e-mail or information services and that will improve the 1346 quality of these services. In this approach the network provider can 1347 charge all its customers for the infrastructural costs by 1348 integrating the charges for the service in the tariffs of e.g. an 1349 e-mail service. However, the question remains who will pay for the 1350 data management costs incurred by the information providers. Again, 1351 if the information providers are non-commercial organisations, it 1352 will be clear that they will not be eager to pay these costs 1353 themselves. And if the users have to pay for it, we are back to 1354 (partial) volume-based charging which does not seem feasible. One 1355 solution to overcoming these problems arose during the SURFnet 1356 pilot: stimulate participation in the Directory Service by offering 1357 a discount on the general license for e-mail, information and other 1358 services to organisations that make their address information 1359 available via the Directory Service. This model has to be further 1360 elaborated. 1362 5.3.4 For further study 1364 In this section, some elements are mentioned that have not yet been 1365 thoroughly addressed. These aspects are regarded as being important 1366 for the future success of the Service and hence are recommended for 1367 further study in 1995. 1369 Applications beyond the White Pages Service The concept of X.500 1370 Directory Services is appropriate for development of many services 1371 beyond the currently implemented White Pages Service (WPS). For 1372 instance, at one of the universities maps are added to department 1373 records to show external users of the X.500 Directory Service the 1374 way to get to the location (the forthcoming integration with the 1375 World Wide Web will improve the quality of such a service). 1376 Elsewhere, the X.500 infrastructure of a university is used as a 1377 basic register for local elections at the university. Students make 1378 use of the Directory to view their individual test results. 1380 Most of these applications, in particular those making use of 1381 internal data of an institution outside the Directory data, require 1382 a local DSA system. Organisations using the central DSA system do 1383 not have the possibility to submit other data than the 1384 communication-related set defined in the White Pages Service. 1386 Other applications that are considered useful in the X.500 1387 infrastructure are: 1389 - Yellow Pages Service, which allows searching 1390 with attributes such as 'scientific field of interest', 'job 1391 description', 'business activity', etc. Also see section 2.3; 1392 - two-way link to the World Wide Web, both for searching Directory 1393 Data from the Web and for creating a Directory of WWW Home Pages. 1394 Discussions on a special attribute for this (labelled URI) are now 1395 ongoing in the Internet; 1396 - distribution of public encryption keys 1397 (e.g., in PGP and PEM). Publication of this key in the Directory 1398 eliminates mail exchanges with the key owner or his mail 1399 administrator and accelerates the process of acquiring the key; 1400 - routing of X.400 mail. MTAs may use the Directory to look up 1401 routing information for messages submitted to them; 1402 - distribution of EDI identifiers. 1404 Measuring end-user experiences Only recently the project reached a 1405 point where an investigation of the experiences of end users has 1406 become meaningful. As mentioned before, within the university 1407 community, the hit-rate was increasing dramatically by the end of 1408 1994. These users have to gain some experience with the X.500 1409 Directory Service before a questionnaire can be sent to them. 1410 Therefore, this aspect will be studied in 1995, with special 1411 interest for user-friendliness, user perception of quality of 1412 service and measurements of service usage. 1414 Directory Structure evolution In 1995, the SURFnet Directory Service 1415 will merge with other national Directory Services. Since SURFnet 1416 uses a very simple Directory Structure (DIT and attribute 1417 prescriptions) which is ideal for only a small number of 1418 participants, this means that a new, national Directory Structure 1419 is needed in 1995. A small working party is now defining this 1420 structure. It is thought necessary to add a branch to the DIT in 1421 which private (i.e. non-organisational) persons can be linked to 1422 their administrative community (e.g. municipality), their province 1423 or state, and their country. This branch will be added below the 1424 country level and will use the locality attribute as classification 1425 method. The proposed DIT looks like: 1427 nl 1428 /\ 1429 / \ 1430 / \ 1431 provinces organisations of 1432 national importance 1433 /\ 1434 / \ 1435 / \ 1436 cities organisations of 1437 provincial importance 1438 | 1439 | 1440 organisations 1441 and inhabitants 1443 Organisational entries at any level of the DIT can have an alias 1444 elsewhere. Hence, the entry of an organisation of national 1445 importance can have an alias under each city where it has a point 1446 of presence. The Dutch Naming and Addressing Authority should 1447 control the standardization process of the Structure. Unfortunately, 1448 the position of this authority in the Dutch government is not 1449 covered yet. This function could be placed either within the 1450 Ministry of Transportation and Public works (Telecommunications and 1451 Post Department) or within the Ministry of Economic Affairs (Dutch 1452 Standards Institute). 1454 6 Main conclusions of the SURFnet Directory Services pilot 1456 The SURFnet Directory Services pilot project has evolved into an 1457 operational service with a reasonable quality of service. It 1458 contains the entries of personnel and students of 10 universities 1459 and 11 other educational and research organisations. The 1460 participation achieved in the pilot seems to have exceeded the 1461 required 'critical mass'. Other organisations within the SURFnet 1462 target group (and outside it) are now interested in joining the 1463 Directory. The main technical difficulties have been overcome by 1464 establishing a well-maintained infrastructure and by focusing on one 1465 DSA product for the time being. 1467 The major concern for the near future is the economic model for the 1468 service. At this time (early 1995), SURFnet does not charge for 1469 joining the service (either by using a private DSA or by using the 1470 central DSA). Based on the relative success of the current service, 1471 a model has to be found in which joining the Directory Service will 1472 not be charged in itself, but will be included as part of a larger 1473 set of services. 1475 Another concern is the further development of user interfaces. 1476 Although there are some rather good DUA interfaces at this time, 1477 there is still a lack of interfaces that are integrated in other 1478 application such as e-mail clients. However, the first beta-versions 1479 of new e-mail clients with integrated DUAs are now available. 1481 Both the service and the data quality are decisive for the user 1482 satisfaction of any Directory Service. Hence, quality of service 1483 definitions for Directory information, availability ('hit rate'), 1484 accuracy ('error rate'), completeness and information richness are 1485 indispensable. These have to evolve continuously according to the 1486 feedback of a user group. 1488 7 Recommendations for participants 1490 The experience with building a Directory Service as described in the 1491 previous chapters has shown that it is feasible to build an 1492 operational Directory Service in which different types of 1493 organisations participate. However, there are still many obstacles 1494 that any organisation starting with Directory Services has to 1495 overcome; technical, as well as legal and organisational. The 1496 following recommendations are made to allow as much as possible for 1497 the removal of these obstacles, and to make it as easy as possible 1498 for organisations to build their own Directory Service and join the 1499 SURFnet Directory Service. 1501 7.1 General 1503 Establishing a Directory Service requires a systematic 1504 approach. This type of service is complex with regard to the 1505 combination of different aspects (technical, administrative, 1506 organisational, legal) and demands the involvement of people 1507 originating from different disciplines. 1509 As a primary requirement, prepare the contribution of your 1510 organisation with great care. Don't be too eager to load the 1511 Directory. Keep in mind that data on people are involved. Take 1512 sufficient time to prepare all necessary actions before actually 1513 feeding personal information into the Directory. 1515 Information on working practices, available DSA and DUA software, 1516 legal aspects, etc. is available at the SURFnet infoserver (URL: 1517 gopher://gopher.nic.surfnet.nl/11/SURFnet.dir.dutch/Projecten/X500). 1518 Furthermore, practical issues are discussed and exchanged over the 1519 distribution list snetx500@nic.surfnet.nl (a Dutch Listserv list). 1521 7.2 Technical 1523 Use the DSA software as recommended by SURFnet (see section 4.2), 1524 available through SURFdiensten bv, and use the SURFnet supplied 1525 default configurations. 1527 Use the DUA interfaces that are recommended by SURFnet (see section 1528 4.4 and appendix A). For user access, small organisations can use 1529 the centrally provided interfaces and LDAP server and large 1530 organisations can set up their own access services. 1532 A basic principle in Quipu X.500 is the principle that information in 1533 one DSA is replicated in other DSAs. This reduces access time and 1534 improves the quality of service (a DSA may be down, but the 1535 information it contains is still available). When an organisation 1536 is planning to run its own DSA, a certain level of replication in 1537 the technical set-up has to be negotiated with other DSA-owners. 1539 In order to obtain a good technical quality of service (performance 1540 and user friendliness) the responsible system manager within your 1541 organisation must join the SURFnet X.500 DSA managers group (send 1542 e-mail to DSA-man@nic.surfnet.nl). 1544 7.3 Legal 1546 The legal registration of the Directory Service of your organisation 1547 (as presented to the outside world) needs a clearly-defined purpose. 1549 Define this purpose in such a way that no legal constraints are 1550 placed upon the information you want to make available. Remember 1551 that offering only attributes for communication purposes eliminates 1552 the legal obligation to register your contribution at the 1553 Registration Chamber. 1555 Inform persons who are to be included in the Directory well before 1556 actually inserting their data. Draw up regulations concerning 1557 additions, changes, deletions, and publicize these. Respect the 1558 legal rights of individuals: 1560 - to view the information stored about themselves; 1561 - to demand restoration of faulty data on their person; 1562 - to refuse being included in the Directory. 1564 Use the SURF brochure 'De grenzen van het Paradijs' [24] to inform 1565 yourself and others about the privacy and legal issues involved in 1566 setting up a Directory Service in the Netherlands. 1568 7.4 Data management 1570 Determine the motivations for setting up a Directory Service within 1571 your organisation, e.g.: 1572 - replacing a paper telephone directory, paper e-mail address lists 1573 and the like; 1574 - making e-mail addresses easily available and up-to-date; 1575 - improving personnel administration; 1576 - etc. 1578 Look for useful elements in the Directory that are not otherwise 1579 obtainable to stimulate the use of the Directory, e.g., favourite 1580 drink, scientific field of interest (in a university or research 1581 environment), room number, private telephone number (for internal 1582 use only!). 1584 The primary motivation for setting up a Directory Service is the 1585 provision of useful information that applies locally. Additional 1586 benefits from participating in the SURFnet Directory Service, with 1587 access to other Directory information on organisations all over the 1588 world, should not be the main motivation to build and maintain a 1589 Directory Service. 1591 Achieve an executive level commitment to start a Directory Service. 1592 This will make it much easier to get cooperation from people within 1593 the organisation that are to be involved in setting up a Directory 1594 Service. 1596 Decide on the kind of data the Directory should contain and how it 1597 should be structured. Follow the Internet and SURFnet 1598 recommendations for structuring the data (according to the X.500 1599 standard). See [4] and [12]. 1601 Define criteria for the quality of the data in the Directory, like 1602 timeliness, update frequency, correctness, etc. Communicate these 1603 criteria throughout the organisation and commit contributing 1604 entities to the defined quality levels. 1606 Use existing databases within the organisation to retrieve the data 1607 you want to be part of the Directory, to the greatest extent 1608 possible. Involve the people who maintain that data and make sure 1609 to get a formal written commitment from them to use their data 1610 source in the Directory. Rely on these people, since they have the 1611 experience in management and control of local, available data. 1612 Setting up a Directory Service not only requires a technical 1613 solution, but mainly the solution of an administrative problem. A 1614 balanced representation of the different disciplines involved in 1615 setting up a Directory Service stimulates the quality and progress 1616 of the tasks to be carried out. 1618 8 References 1620 [1] ITU (1993), The Directory - overview of concepts, models and 1621 service. International Telecommunications Union, X.500 series 1622 of Recommendations. 1624 [2] Huizer, E (1992), Proposal for a X.500 Directory Services 1625 Project, SURFnet EH/911533. 1627 [3] Paradise (1991-1994), Paradise International Reports, 1628 University College London, April 1991 - April 1994. 1630 [4] Kille, S, et al (1993), A Strategic Plan for Deploying an 1631 Internet X.500 Directory Service, RFC1430 1633 [5] Huizer, E (1993), Building a Directory Service, Final Report 1634 test phase SURFnet X.500 pilot project, SURFnet 1636 [6] Chadwick, D (1994), Understanding the X.500 Directory, Chapman 1637 & Hall, London 1639 [7] Rose, M (1992), The little black book, Prentice Hall, Englewood 1640 Cliffs (U.S.) 1642 [8] Steedman, D (1993), The Directory standard and its application, 1643 Technology Appraisals, Twickenham (U.K.) 1645 [9] Weider, C, Feltstrom, P (1994), The Whois++ Directory Service, 1646 Connexions, vol. 8, no. 12 1648 [10] Foster, J (1994), A Status Report on Networked Information 1649 Retrieval: Tools and Groups, RFC 1689 1651 [11] Postel, J, Anderson, C (1994), White Pages meeting report, 1652 RFC 1588 1654 [12] Barker, P, Kille, S, Lenggenhager, T (1994), Naming and 1655 Structuring Guidelines for X.500 Directory Pilots, RFC1617 1657 [13] Kille, S (1991), Replication Requirements to provide an 1658 Internet Directory using X.500, RFC1275. 1660 [14] Kille, S (1991), Replication and Distributed Operations 1661 extensions to provide an Internet Directory using X.500, RFC1276 1663 [15] Getchell, and Sataluri (1994), A Revised Catalog of Available 1664 X.500 Implementations, RFC 1632 1666 [16] Harrenstien, Stahl, Feinler (1985), NICNAME/WHOIS, RFC954 1668 [17] SYN287 (1992), Directive concerning the protection of 1669 individuals in relation to the processing of personal data, The 1670 council of the European Communities, Com(92)422 SYN287 1672 [18] Hill, J (1992), The X.500 Directory Services: a discussion of 1673 the concerns raised by the existence of a global Directory, 1674 electronic networking, vol.2, no.1 1676 [19] Barker, P (1994), Experiences in providing a White Pages 1677 directory service based on the X.500 standard, Computer Networks 1678 and ISDN Systems 26, pp. 1365-1374. 1680 [20] Koechlin, B., Treca, K., Pays, P. (1994), Strangers in 1681 Paradise, Proceedings INET'94/JENC5, 261 1683 [21] Howes, T, et al. (1993), The X.500 string representation of 1684 standard attribute syntaxes, RFC1488 1686 [22] Yeong, W, et al. (1993), X.500 Lightweight Directory Access 1687 Protocol, RFC1487 1689 [23] Kille, S (1993), Using the OSI Directory to achieve User 1690 Friendly Naming, RFC 1484 1692 [24] Wijngaard (1994), A van de, De Grenzen van het Paradijs, ed. 1693 A., SURF 1695 9 Glossary 1697 ACL Access Control List; a mechanism to restrict access to 1698 data stored in an X.500 Directory Service. 1700 Attribute Attributes belong to an entry in the Directory 1701 Service, and contain information belonging to that 1702 entry, e.g. surname=jurg (see section 2.1.1). 1704 BLT BulkLoadTool; a tool to download an existing 1705 database into a DSA. 1707 cDSA See Central DSA 1709 Central DSA A DSA that is shared by multiple organisations, 1710 mostly SMOs, to make their data available in the 1711 X.500 infrastructure. The DSA system is maintained 1712 by a computing centre, the data is maintained by the 1713 organisations that provide the data. 1715 Centroid A type of index information used in the Whois++ 1716 standard and possibly used in an integrated 1717 Directory Service. 1719 DAP Directory Access Protocol; protocol used between a 1720 DUA and a DSA, to access the Directory Information. 1722 DE Directory Enquiry; an ascii-based DUA interface. 1724 Directory Service An electronic database that contains information 1725 on entities (e.g. people, services, organisations 1726 etc.) and that is accessible over the network. 1728 DIT Directory Information Tree; the hierarchy of the 1729 distributed database that makes up an X.500 service 1730 (see section 2.1.2). 1732 DS See Directory Service. 1734 DSA Directory System Agent; system in an X.500 1735 infrastructure that holds part of the Directory 1736 Service data (see section 2.1.2). 1738 DUA Directory User Agent; system in an X.500 1739 infrastructure that is used to access the 1740 information in the Directory Service. 1742 Dutch Strange Anglo-Saxon word to indicate something or 1743 someone from the Netherlands, or the language 1744 spoken in the Netherlands. 1746 E-mail Electronic mail. 1748 Entry A Directory Service contains entries on people, 1749 organisations, countries, etc. Entries belong to a 1750 certain object class, and information on entries is 1751 stored in attributes (see section 2.1.1). 1752 EU European Union. 1754 IDM Interactive Data Manager; a DUA interface that is 1755 useful for maintaining a large set of data. 1757 IP Internet Protocol; part of the popular TCP/IP suite 1758 of protocols. 1760 ISO International Organisation for Standardization. 1761 Responsible for a wide range of standards, 1762 including those relevant to networking. ISO is 1763 responsible for the most popular networking 1764 reference model and related standards: the OSI 1765 reference model. 1767 ITU International Telecommunication Union; (formerly 1768 known as CCITT) a standards-making body for 1769 telecommunication operators (PTTs). Responsible for 1770 the OSI conformant X-series of recommendations (e.g., 1771 X.500, X.400 etc.). 1773 Labelled URI Labelled Uniform Resource Identifier; see URL. 1775 LDAP Lightweight Directory Access Protocol, an internet 1776 standard [21] and [22] for a lightweight version of 1777 DAP running over TCP/IP. 1779 Master DSA A DSA that serves the entry for a country, and that 1780 holds information on all DSAs available within that 1781 country. 1783 NeXor A commercial supplier that sells ISODE, Quipu and 1784 PP based products. 1786 NL The Netherlands. 1788 Object Class Entries in a Directory Service belong to an Object 1789 Class to indicate their type and characteristics; 1790 e.g., Object Class 'person' (see section 2.1.1). 1792 OSI Open Standards Interconnection; an international 1793 standardization program, facilitated by ISO and ITU to 1794 develop standards for data networking. 1796 Paradise A European Directory Services pilot and now 1797 infrastructure in which SURFnet participates. 1799 PEM Privacy Enhanced Mail; an Internet standard for 1800 sending secure E-mail. 1802 Quipu An implementation of the X.500(1988) 1803 recommendations. 1805 RFC Request For Comment, internet series of 1806 publications. 1808 RFC-1006 Internet standard that specifies how to run OSI 1809 applications over TCP/IP. 1811 SURFnet The academic and research network in the 1812 Netherlands; URL:http://www.nic.surfnet.nl/surfnet/ 1813 surfnet.html. 1815 TCP/IP Transmission Control Protocol and Internet Protocol, 1816 the two best known Internet protocols, TCP 1817 corresponds roughly to layer 4 of the OSI model 1818 (the transport layer), IP corresponds to layer 3 1819 (the network layer). 1821 UFN User Friendly Naming; an internet standard for 1822 identifying an entry in X.500 by a user friendly 1823 name. 1825 URL Uniform Resource Locator; an address for any 1826 document on the Internet. 1828 Whois++ An Internet directory services protocol; a possible 1829 alternative for X.500. 1831 WPS White Pages Service; a Directory Service that 1832 contains (addressing) information on people and 1833 organisations. 1835 X.500 A series of recommendations as defined by the ITU, 1836 that specify a Directory Services protocol. 1838 10 Security Considerations 1840 Security issues are not discussed in this memo. 1842 11 Authors' Addresses 1844 Peter Jurg 1845 SURFnet bv 1846 PO Box 19035 1847 3501 DA Utrecht 1848 The Netherlands 1850 Phone: +31 30 2305305 1851 EMail: Peter.Jurg@SURFnet.nl 1853 Erik Huizer 1854 SURFnet bv 1855 PO Box 19035 1856 3501 DA Utrecht 1857 The Netherlands 1859 Phone: +31 30 2305305 1860 EMail: Erik.Huizer@SURFnet.nl 1862 Mark Jacobs 1863 Stratix Consultancy bv 1864 Triport 1, Evert vd Beekstraat 1865 1118 ZP Amsterdam 1866 The Netherlands 1868 Phone: +31 020 4466555 1869 EMail: mark.jacobs@stratix.nl 1871 Evelijn Jeunink 1872 University of Utrecht 1873 Faculty of Law 1874 Nobelstraat 2 1875 3512 EN Utrecht 1876 The Netherlands 1878 Phone: +31 30 2537285 1879 EMail: E.Jeunink@rgl.ruu.nl 1881 Ton Verschuren 1882 SURFnet bv 1883 PO Box 19035 1884 3501 DA Utrecht 1885 The Netherlands 1887 Phone: +31 30 2305305 1888 EMail: Ton.Verschuren@SURFnet.nl 1889 Appendix A: DUA interfaces 1891 Date: January 5, 1995 1893 This is a list of available DUA interfaces for interactive use of the 1894 Directory via the Internet. The list is not complete, but should 1895 provide new X.500 users with enough information to choose an 1896 appropriate interface for accessing the Directory. The interfaces 1897 in this list are end-user interfaces and not meant for data 1898 management. Two types are distinguished: - standalone DUA interfaces 1899 for end users; - DUA interfaces for end users integrated in other 1900 applications. 1902 All DUA software below use either DAP or LDAP on top of TCP/IP (using 1903 RFC1006 in case of DAP) to access the Directory. 1905 People who are interested in this information are recommended to read 1906 Getchell (1994). The DUA interfaces that have been tested in the 1907 SURFnet Directory Services project are marked with "(Test)". In such 1908 cases, a brief summary of the test results is provided. The full 1909 test reports will be available in html format through 1910 www.nic.surfnet.nl (but probably only in Dutch). 1912 A1 Standalone DUA interfaces 1914 DE 1915 A character-based Unix DUA interface that supports (from version 7.0) 1916 both DAP (ISODE is needed) and LDAP. It supports authenticated 1917 binding (even strong authentication), modifying and UFN. 1919 URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software/x500/ 1920 unix-de/de-7.0.tar.Z 1922 Freeware. 1924 DOS-DE 1925 This is the DOS version of Unix DE, which uses LDAP as access 1926 protocol. It needs NCSA Telnet stack or SUN's PCNFS version 4.1 or 1927 Novell's LAN Workplace for TCP/IP connectivity. 1929 URL: ftp://info.nic.surfnet.nl/mirrorarchive/software/x500/ 1931 Freeware. 1933 Max500 (Test) 1934 Max500 is a DUA interface for Macintosh that uses LDAP as access 1935 protocol. It supports UFN, authenticated binding and modifying. 1936 Max500 also supports presentation of picture and sound attributes. 1937 The latest version supports the labelled URL attribute and can use 1938 some WWW clients as helper applications to connect to the URL that 1939 is given in the value of this attribute. Max500 enables searching 1940 and browsing. 1942 URL:ftp://info.nic.surfnet.nl/mirrorarchive/software/x500/ 1944 Freeware. 1946 Test results 1947 Max500 has an attractive user interface, although the multiple 1948 search options sometimes make it difficult to be used by 1949 inexperienced users. It can run on almost any Macintosh 1950 ( >system 6.0.5). 1951 Installation is easy, configuration is a little more difficult. 1952 A disadvantage for use in Appletalk networks is that the 1953 configuration preferences reside on the Mac that runs the 1954 application. This means more work for system managers. 1956 PCDUA 1957 PCDUA is an LDAP based DUA interface for Windows. It uses Winsockets. 1958 It supports no UFN, but authenticated binding and modifying is 1959 possible. 1961 URL:mailto:sales@nexor.co.uk 1963 Commercial product. 1965 PC-PAGES (Test) 1966 PCPages is an LDAP based DUA interface for Windows. It uses 1967 Winsockets. It supports UFN, but no authenticated binding (hence 1968 no modifying). 1970 URL:mailto:x.500@brunel.ac.uk 1972 Commercial product. 1974 Test results 1975 PCPages has a rather elaborate installation procedure where .INI 1976 files and OID tables have to be edited. However, the 1977 documentation is good. PCPages also offers a user-friendly 1978 interface. Searching and browsing is easy with PCPages. 1979 Approximate searching could perform better. PCPages can be used 1980 in combination with ECS Mail. 1982 SLU 1983 A character-based Unix DUA interface that supports DAP (ISODE is 1984 needed). 1986 URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software 1987 /x500/slu/slu-1.1.tar.Z 1989 SWIX (Test) 1990 Swix is an LDAP-based DUA interface for Windows. It uses Winsockets. 1991 It supports UFN, authenticated binding and modifying. 1993 URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software 1994 /x500/swix/swix21.exe 1996 Freeware. 1998 Test results 1999 Swix is a relatively simple DUA interface with an easy 2000 installation procedure and a good manual. It is recommended for 2001 end-users. Swix cannot be linked to other programs (DDE) and the 2002 representation of the entries could be better. Swix is good in 2003 handling approximate searches, but the tested version had some 2004 difficulties with multiple hits and did not perform too well when 2005 searching was done with exact matches. 2007 UD 2008 A simple character-based Unix DUA interface that comes with the LDAP 2009 package and hence supports LDAP. It also supports UFN and 2010 authenticated binding for modification of entries. 2012 URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software 2013 /x500/ldap/ldap-3.1.tar.Z 2015 Freeware. 2017 WDUA (Test) 2018 WDUA is an LDAP based DUA interface for Windows. It uses Winsockets. 2019 It supports UFN, authenticated binding and modifying. 2021 URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software 2022 /x500/wdua/wduainst.exe 2024 Freeware 2026 Test results 2027 This DUA interface is recommended to data managers who have to 2028 modify a relatively small number of entries. WDUA is a little too 2029 complicated for ordinary users. One disadvantage is that it 2030 cannot be linked to other Windows programs such as e-mail 2031 clients, etc. 2032 Some other DUA interfaces for Windows support such a feature 2033 (DDE). 2035 WINDUA 2036 WINDUA is an LDAP-based DUA interface for Windows. It uses 2037 Winsockets. It offers authenticated binding and modifying and it 2038 supports a DDE server for links with other Windows applications. 2040 URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software 2041 /x500/windua/windua.zip 2043 Freeware. 2045 XT-DUA (Test) 2046 XTDUA is an X-Windows DUA interface that supports authenticated 2047 binding, modifying and UFN. It uses DAP/ISODE. 2049 URL: mailto:sales@nexor.co.uk 2051 Commercial software. 2053 Test results 2054 This DUA interface is recommended to data managers who have to 2055 modify a relatively small number of entries. It is a little too 2056 complicated for ordinary users. Some modifying functions are 2057 somewhat too easy (one could easily delete all kinds of things). 2058 It lacks a function to the same attribute in many simultaneous 2059 entries. 2061 XLU 2062 XLU is a Motif and X-windows DUA interface that uses DAP/ISODE and 2063 supports authenticated binding , modifying and UFN. It is the 2064 'windows version of SLU'. 2066 URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software/x500/xlu/ 2068 Freeware. 2070 A2 Integrated DUA interfaces 2072 gopher/X.500 gateway (Test) 2073 This gateway provides a gopher interface to X.500 and runs on Unix 2074 machines. The gateway uses LDAP as access protocol and provides a 2075 browsing function and a one-level searching function. Authenticated 2076 binding is not provided, but the latest version should support UFN. 2078 URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software/x500/ldap/ (it 2079 comes with the LDAP package) 2081 Freeware 2083 Test results 2084 The gateway is easy to install, but must run on the same system 2085 as the LDAP server (it uses some of the LDAP libraries). It uses 2086 the inetdeamon which means that it does not have to run all the 2087 time, but only when a request comes in. The interface is 2088 particularly suited for inexperienced users, since it is simple, 2089 but provides the basic functionality. 2091 WWW/X.500 gateway (Test) 2092 This gateway provides a WWW interface to X.500 and runs on Unix 2093 machines. The gateway uses LDAP and provides a browsing function and 2094 a one-level searching function. Authenticated binding (modifying) 2095 is supported in a beta release. Display of attributes containing 2096 pictures and sound is supported (if supported by the WWW client or 2097 helper applications). The latest version also supports links from 2098 the labeledURL attributes. 2100 URL: ftp://isode.tu-chemnitz.de/pub/web500gw-1.5a.tar.Z 2102 Freeware 2104 Test results 2105 The user documentation is not very good, but the gateway is not 2106 too difficult to install. Filters for graphical format conversion 2107 are provided. The interface offers a great functionality to a 2108 large group of WWW users. However, searching sometimes leads to 2109 strange results. Users have to gain some experience with the use 2110 of the gateway. 2112 Minuet with X.500 access (Test) 2113 Minuet is a DOS client for WWW, gopher, e-mail, news and ftp. In a 2114 beta-release an X.500 DUAS interface is also incorporated by means 2115 of a SOLO implementation. 2117 URL: ftp://boombox.micro.umn.edu/pub/pc/minuet/beta16/minuarc.exe 2119 Shareware. 2121 Test results 2122 The software suffers from some typical beta-version drawbacks 2123 (e.g., at every start-up the name of the SOLO server has to be 2124 typed in). It only offers searching and not browsing (listing). 2125 The results were rather poor, but this may be due to the use of 2126 an experimental SOLO server in France (no SOLO servers outside of 2127 France were available at that moment). Further tests are needed 2128 with a LOCAL SOLO server. 2130 Pegasus with X.500 access 2131 Pegasus is an e-mail client for Internet and Novell networks that 2132 runs on DOS, and Windows PCs and Macintoshes. In the first months 2133 of 1995, it is expected that some Pegasus clients, starting with the 2134 Windows client will have integrated X.500 access (LDAP). Not 2135 available when this summary was compiled. 2137 Freeware. 2139 ATISmail with X.500 access 2140 ATISmail is an e-mail client for Internet and Novell networks that 2141 runs under Windows. It incorporates X.500 access by means of LDAP. 2143 URL: ftp://ftp.nic.surfnet.nl/mirror-archive/software 2144 /simtel-win3/winsock/atisml04.zip 2146 Shareware 2148 CSO to X.500 gateway 2149 A CSO server is a very popular non-distributed Directory Service for 2150 which many clients (integrated in gopher or e-mail clients) are 2151 available. The University of Utrecht wrote a small program that 2152 translates between CSO and UD (see above). It enables LDAP access 2153 to the X.500 Directory Service from CSO clients. 2155 URL: ftp://info.nic.surfnet.nl/surfnet/projects 2156 /x500/SURFnet-duas/ph-ud.tar.gz 2158 Freeware.