Electronic directory services

Electronic directory services The evolution of directory services for computer network users is surveyed by Ahmed Patel and Vincent Ryan

Electronic directory services aid users in identifying and locating objects in a distributed environment The various directory-like services available to users of computer networks are outlined, with the investigation spanning past and present advances made in the area, and developments proposed for future directory services .

Keywords: computer networks, electronic services, electronic mail

directory

What is a directory service? We are all familiar with the White Pages and Yellow Pages directories of the telephone community (public switched telephone network), where the address (telephone number) of a subscriber or a service may be obtained, given the full name of that subscriber or service . Unfortunately, no corresponding directory, computerized or otherwise, exists for the electronic mail (e-mail) community (computer networks) . Such a directory service should not be restricted to serving e-mail users alone - e-mail is only one application which can usefully employ the services of a directory, e .g. a File Transfer Protocol (FTP) based on RFC* 959 1 ; File Transfer and Management (FTAM), based on the International Standards Organization (ISO) 8571 2 ; a remote log-in protocol, e .g. Telnet, based on RFC 854 3 ; X .29, 4; security and based on the CCITT recommendations 5, authentication procedures etc. In fact, any application which interacts with named objects in a distributed environment can usefully employ directory services . However, since the most widely used application in data networks today is e-mail, directories with respect to this are discussed here . Since many of today's networks are Department of Computer Science, University College Dublin, Belfield, Dublin 4, Ireland *Request For Comments: provisional standards issued for use throughout the Advanced Research Projects Agency (ARPA) community .

based on the original Advanced Research Projects Agency Network (ARPANET), networks are first discussed with respect to ARPAN ET, and with respect to the problem of naming and addressing 'objects' in an e-mail network . When contacting another e-mail user for the first time, one must first obtain the e-mail name of the user . As there is no directory of user names to consult, an alternative communication method (e.g. telephone or postal service) must be used to acquire that e-mail name . Having obtained this information, one can then attempt to send a message to the user in question . Since the sender's name will accompany the transmitted message, the recipient can reply without undue difficulty . Embedded in the above scenario are two problems . The first (and most obvious) is the problem of initial identification : once the sender has obtained the correspondent's e-mail name he may proceed to compose a message, specify this name as the recipient, and present it to his local host machine for delivery to the destination . Now the second problem arises, that of initial communication: the sender's host machine now has the message to be transmitted which includes the name of the destination host . However, this name is of little use unless it can be translated into the corresponding address of the destination host . The use of names to identify users does have the benefit of replacing user-hostile addresses with userfriendly names, but makes an extra translation step necessary. A directory service may be used to overcome both of these problems . Such a service manages information pertaining to objects in a distributed environment . In its simplest form, a name service, it provides the single, albeit useful function of name-to-address translation, solving the problem of initial communication (a simplified model of directory service use is shown in Figure 1) . How a directory service may be used to solve the problem of initial identification is discussed below. By employing a simple name service the sender's host

0140-3664/88/050239-06 $03 .00 ©1988 Butterworth & Co (Publishers) Ltd vol 11 no 5 october 1988

239

increase in both the number of hosts per network and the number of users per host, the centralized name service became unmanageable . A static table containing an exhaustive list of all hosts was undesirable : first, because of the sheer size of the table ; and second, because a particular host may have found that many of the large number of names were seldom, if ever, used . In fact, there may be whole networks with which a particular host may never correspond . A more suitable arrangement had to be found, bringing us to developments in present day networks .

EDS PRESENT Figure 1 .

Directory service use

may obtain the address of the destination host, or in some cases, the address of a host willing to handle mail for the destination host (a mail-gateway or mail-exchange) . Finally, depending on the configuration of the e-mail network, the message will be transmitted directly to the destination host (connection-oriented approach), or will arrive there having passed through one or more intervening hosts (store and forward approach) . On receiving the message, it is the responsibility of the destination host to interpret the local-part of the destination name and deliver the message to the specified user (agent) .

EDS PAST This description is biased towards the ARPANET, since much of the early research and development on name servers was initiated there b' 7. E-mail was one of the first applications made available to users of computer networks, and has been in existence on the ARPANET since the early 1970s . Many other networks have since appeared, offering a similar service . In order to use e-mail effectively, a uniform naming system to identify users must be employed . Although the details of name formats may vary from network to network, there are some underlying similarities . The ARPA-like networks (e.g . BITNET/EARN, CSNET) all use the format laid down in RFC 733 8 which appeared in the late 1970s . This early standard specified the following naming format: @, where hostpart is a globally (network-wide) unique string of characters locally interpretable at this host machine (often it is simply a login ID) . The host's name is drawn from a flat name space, e.g . Smith@USC-ISIF identifies a username Smith at the USC-ISIF host . This naming scheme has the disadvantage of identifying a user relative to a particular host machine. At that time, networks were small by today's standards . A single central database of all host names and their corresponding addresses sufficed as a name server . In the ARPANET this central database was maintained by the Network Information Center (NIC), and an up-to-date copy was regularly distributed to every host on the network . When a host wished to send mail it searched this name table to obtain the address of the destination host and then transmitted the message to this address . With the proliferation of networks and the accelerating

2 40

What is happening internationally in the area of directory services? In the USA, new RFCs specifying standards for the ARPA community continue to be released . The ARPA network is by no means outdated - it is still one of the world's largest research networks and continues to provide network services to thousands of users . Other contemporary networks also provide a name service to their users, e .g . in the UK, the Joint Academic Network (JANET) has a centralized directory service, and the Xerox Corporation has a name service, the Clearinghouse 9, for its Grapevine 10 distributed system (discussed below) . The ISO and CCITT have been very active in producing international standards relating to directories . Various research projects have set about implementing prototypes of the ISO/CCITT output, e .g. the Commission of the European Communities ESPRIT project, The Obviously Required Name-server (ThORN) 1 and the Deutsches Forschungsnetz (German research network) VERDI/ VERDI II" projects .

ARPA community and name service In the early 1980s the ARPA Internet was formed, comprising the old ARPANET, MILNET, part of CSNET, and many university and corporation Local Area Networks (LAN), all connected in an internetwork . To cope with the increase in the number of names, and to cater for future increases, the ARPA Internet set about converting its naming scheme from a flat name space to that of a hierarchical name space . This is called the Domain Naming System, and was first described in RFC 799 13 and RFC 8191 (a comprehensive description may be found in References 15 to 17) . Domains are administrative entities, introduced in order to allow the partition of the centralized name management authority into a number of subadministrations. It was decided that there should be no geographical, topological, or technological constraints on a domain . The domain system comprises a tree-structured global name space with a small number of top-level domains . These top-level domains are subdivided into secondlevel domains, which may in turn be subdivided into third-level domains, etc . The top-level domains are shown in Table 1 . Other top-level domains are permitted : countries may be assigned two-letter ISO country codes' 8 (e .g . I E for Ireland, AU for Australia), and multi-organizations which are composed of other organizations may also be assigned atop-level domain, especially if the organizations span international boundaries . The hierarchical nature of this domain-based approach

computer communications



Table 1 . Top-level domains in the ARPA Domain Naming Scheme Top-level domain

Includes

COM EDU GOV MIL ORG

Commercial organizations Educational establishments Government organizations Military establishments Other organizations

lends itself to the decentralization of the name allocation authority and the distribution of the name service . So, associated with each domain is a naming authority and a reliable name service. Each naming authority ensures the allocation of unique names within its domain, with the name service providing access to these names to users both inside and outside the domain . The name service at each domain is supported by one or more name servers, allowing the name space to be partitioned and distributed among the available name servers . Under this new Domain Name System, all e-mail names are structured hierarchically as follows : aa , where domain-part is a sequence of names separated by dots proceeding from the most specific on the left to the most general on the right . The user-part holds its meaning as before . This is referred to as RFC 822 19 format, e .g. JSmith@,CS .MIT.ED U . This name denotes JSmith in the CS sub-domain of the MIT sub-domain of the top-level EDU domain . Underthe Domain Naming System users are identified relative to a particular domain rather than relative to a particular host machine, which is an improvement . However, the userpart still resembles a login ID more than a user's real name (see Reference 20 for further information about the Domain Naming Scheme in relation to e-mail, especially that of routing mail messages under this new system) .

JANET name registration scheme The UK Joint Academic Network (JANET) is a private X .25based network serving UK universities and research institutions . It utilizes a centralized directory system to manage its hierarchical domain scheme, known as the Name Registration Scheme . The JANET name format is similar to that of the ARPA Internet, except that the order of the domain name-parts is reversed - the most general domain appears on the left, e .g. Smith @UK .AC.UCL.CS represents a user in the CS subdomain of the UCL subdomain of the UK academic community domain . Each subdomain has a naming authority which allocates host names within that domain . However, all host names must finally be registered with the central name authority . The JANET Name Registration Scheme is discussed further in Reference 21 .

Clearinghouse name service The Xerox Corporation has developed a name service for its Grapevine ) distributed system, known as the Clearinghouse . Its function is to provide information about a variety of 'objects' (this includes 'users') in a distributed

vol 11 no 5 october 1988

office environment which spans an internetwork of local networks . Object names are organized into a three-level hierarchy comprising a local-name, a domain-name and an organization-name, e .g. John Smith @PARCCkXerox. An object's name is mapped onto a set of properties by the Clearinghouse . A property contains some useful information pertaining to an object, e .g. its network address . A collection of distributed servers are employed to manage the name space. Each server is responsible for a portion (domain) of the global name space . Each organization has a naming authority, and one or more organization clearinghouses . An organization clearinghouse is a server which manages the names of all the domain clearinghouses in a particular organization . Each domain has a naming authority, and one or more domain clearinghouses, which are servers that manage the names of all the objects in a particular domain . The Clearinghouse identifies users relative to a particular domain (as in the ARPA Internet system) . However, a 'local-name' is more representative of a user's real name (unlike in the ARPA Internet system) .

ISO/CCITT and directory service In the 1970s, ISO and CCITT set about establishing international standards for computer networks . It was decided from the outset that these standards would be developed from scratch, and not simply rehashed de facto standards . First, a model was developed, the Open Systems Interconnection Reference Model (OSI/RM) 22. Standards were then promulgated for each of the seven layers of this model . The aim was to develop truly open systems which could communicate with each other regardless of vendor or operating system, provided that they adhered strictly to the published standards . The top layer of the OSI/RM is referred to as the application layer . Due to its importance, e-mail was one of the first applications to be standardized . ISO and CCITT set about defining a standard Message Handling System (MHS) based on the CCITT X .400 series of recommendations 23 for public data networks . Because of the rapid advances being made in data communications and computer networks, much effort was invested in the MHS standard in order to provide upward compatibility with future technological advances . MHS was not based on any existing e-mail network, but was developed anew, e .g. in MHS a message is not merely a text message, but may also include encoded voice, video, teletex, facsimile, etc . The developers were very much aware of the chaos at that time with regard to naming, so an innovative approach was taken in devising a user-friendly naming system for MHS . MHS names are not based on a character string in RFC 822 19 format, which is the approach taken in many existing networks, but on coded data structures . These data structures contain a list of attribute tags and their corresponding values . MHS names do riot identify a user relative to a particular host machine, but employ higher level descriptions such as the person's name, their employer and country (to name but a few), e .g. the following list of attributes could be used to describe a person : Country=IE ; Organization=UCD ; Personal Name =John M Smith . This is clearly a much more natural representation . MHS users are no longer represented by names which are bound to the name of particular host machines,

241

but by attributes which are somehow inherent to the user . This lends itself to a more user-friendly naming scheme, i.e . given some basic information about a person (e.g. full name, employer and country), it should be possible to deduce the MHS name for that person, because MHS names are independent of network-dependent objects . However, these names do have to be verified for correctness and eventually converted into addresses . Therefore, during their conception a directory service was envisaged in order to support user-friendly naming in MHS . Let us assume that an MHS user wishes to send a message to another MHS user . The sender would present a partial or purported name for the intended recipient to the directory service for resolution or verification . The fully qualified name which is returned would be included as the destination of the message . In this way, a directory service may be used to solve the problem of initial identification (discussed above) . The sender would then pass the message to the local Message Transfer Agent (MTA) . The MTA would query the directory service to obtain the address corresponding to the destination of the message, and on receipt of this address the MTA would begin message transmission . The ISO/CCITT convergence documents on directory services 24 are currently in their final stages . CCITT refers to these recommendations as its X .500 series of recommendations for public directory services 25. This Directory Service (DS) is based on a distributed architecture, implying that the DS will span several distributed databases . Each portion of the directory information base is managed by a Directory Service Agent (DSA) whose role is to provide access to the directory to Directory User Agents (DUA) and/or other DSAs . A DUA is responsible for querying the directory on behalf of a user (see Figure 2) . This DS provides two important capabilities to its users . First, a name-to-address translation facility (this type of service has been outlined already in the form of the ARPA name service) . Users identify objects (e .g. e-mail user, a laser printer) by symbolic name rather than by physical address . Objects in a network change their locations much more frequently than they change their names,

DUA

User

EDS FUTURE

User

User

User

DUA

DUA

DUA

DUA

Directory System

s' DSA

DUA

DSA

I I

Directory Environment User

Figure 2 .

242

Current DS research ThORN is a four year project funded by the CEC ESPRIT programme begun in 1985 to develop a distributed directory service based on current standards within the OSI framework. It comprises 11 partners, from both industry and academia, spread throughout the European Community. Due to the importance attributed to directory services the ThORN project set about implementing a pilot service in advance of the final publication of recommendations by the standardization bodies . In fact, one of the major aims of the project was to provide feedback to the standardization bodies about problems encountered during the pilot service . VERDI and VERDI II are projects undertaken by DFN in order to gain experience in the area of directory services . The VERDI project predates the ThORN project, and as such is not as closely aligned with the work being done by ISO/CCITT in the area . However, recently DFN have begun VERDI II, a continuation of the project, setting out to develop a distributed directory system which interworks with distributed applications . Directories will not only aid in person-to-person communication, but may also be used to support applicationto-person, person-to-application and application-toapplication communication . The AMIGO project on advanced group communication 26 (sponsored by the CEC under the COST-11 ter programme) is very active in this area. It is investigating the use of directory services for administration and runtime support of group communication applications . Applications such as distributed bulletin-boards, date planning, computer conferencing and joint editing of documents, will all take place in a distributed computer environment. There can be no doubt that integrated directory services will be crucial in order to locate and manage objects and application entities in the OSI environment of the future .

User

DSA

therefore the introduction of a level of indirection between users and the objects which they wish to identify has an advantage . It isolates the users of the network from the frequent changes within it . Provided the DS is kept informed of any address changes in the network then users may freely refer to objects by name . The DS will perform the necessary name-to-address mapping . Users need not be concerned with changes which may occur in the underlying network . Second, the DS attempts to make the network appear more user-friendly to its users . The concept of user-friendly naming has already been described in relation to MHS names . The DS will support user-friendly naming for all objects in the network (though not all objects need have a user-friendly name) . In addition to a straight-forward directory look-up service, the DS will also provide a yellow Pages service, where information pertaining to objects is grouped into classifications . The object of all these DS services is to aid users in identifying and locating objects in a distributed network, i .e. the DS helps to overcome the problems of initial identification and initial communication .

Distributed directory functional model

The importance of directory services is only beginning to be understood and the value of an integrated but distri-

computer communications

buted directory system fully appreciated . Once a reliable public DS (involving the co-operation of PTTs) is established, what services will it provide? It is anticipated that the DS, when in place, will be distributed by country, thus providing a global directory . Many of the current computer network applications will employ the DS to retrieve information pertainingto various objects in this distributed environment of open systems . Applications for this will include FTAM, MHSs and Job Transfer Manipulation (JTM) . This open environment will bring with it the need for security and authentication . In addition to these familiar applications, telematic services such as telefax, teletex, videotex and Packet Assembly/ Disassembly (PAD), to name but a few, will also begin to utilize the DS . A directory service which will be distributed on such a global scale will first have to solve a number of problems, such as initializingthe directory information base, ensuring data integrity and consistency during updates, etc . Many of these have been addressed by ISO/CCITT, but many still remain for further study. One of the primary problems will be to dynamically manage a directory which will span many national boundaries . Name-space management as well as day-to-day operational management will require analysis, as central management will be infeasible . The problems associated with a distributed database are discussed in the literature 27. These problems of propagating updates and inconsistent information resident in cache are well known, and are not dealt with here . However, such problems and other issues are of fundamental importance for the correct implementation and operation of the DS. Another important issue is the handling of non-Roman alphabets, e .g . Chinese, Japanese and Arabic . How can these character-sets be accommodated in an international directory? As can be seen, there are many difficulties associated with providing a directory service on such a global scale . Some of these have been addressed already, but there are many issues still remaining to be investigated, and with the provision of a prototype service many more problems will come to light . It is acknowledged that a DS based on international standards will play an important role in realizing an OSI environment .

REFERENCES 1 Postel, J and Reynolds, J RFC 959 :File Transfer Protocol USC/International Sciences Institute, USA (October 1985) 2 File Transfer and Access Management ISO DIS 8571 / 1-4, Geneva, Switzerland (1985) 3 Postel, J and Reynolds, J RFC 854 : Telnet Protocol Specification USC/International Sciences Institute, USA (May 1983) 4 Data communication networks : services, facilities and interfaces CCITT Recommendations X .3, X.25, X .28 and X .29, ITU, Geneva, Switzerland (1978) 5 Information Processing Systems - Open Systems Interconnection Reference Model - Part 2 : Security Architecture ISO DIS 7498/2, Geneva, Switzerland (1987)

vol 11 no 5 october 1988

6 Harrenstien, K, Stahl, M and Feinler, E RFC 952 : DoD Internet Host Table Specification SRI International, USA (October 1985) 7 Harrenstien, K, Stahl, M and Feinler, E RFC 953 : Hostname Server SRI International, USA (October 1985) 8 Crocker, D H, Vittal, J J, Progran, H T and Henderson, D A RFC 733 Standard for the Format of ARPA Network Text messages SRI International, USA (November 1977) 9 Oppen, D C and Dalal, Y K The Clearinghouse : A Decentralized Agent for Locating Named Objects in a Distributed Environment Xerox PARC, USA (July 1981) 10 Birrell, A D, Levin, R, Needham, R M and Schroeder, M D Grapevine : An Exercise in Distributed Computing Xerox PARC, USA (April 1981) 11 The Obviously Required Name-server (THORN) General specifications Internal draft working paper, ESPRIT/IES (1986) 12 Santo, H and Tschichholz, M VERDI : a Distributed Directory System for the German Research Network - Deutsches Forschungsnetz (DFN) GMD/HMI, FRG (July 1986) 13 Mills, D L RFC 799 : Internet Name Domains COMSAT Laboratories, USA (September 1981) 14 Su, Z and Postel, J RFC 819 : The Domain Naming Convention for Internet User Applications USC/ International Sciences Institute and SRI International, USA (August 1982) 15 Reynolds, J RFC 920: Domain Requirements USC/ International Sciences Institute, USA (October 1984) 16 Mockapetris, P RFC 1034 : Domain Names - Concepts and Facilities USC/International Sciences Institute, USA (November 1987) 17 Mockapetris, P RFC 1035 : Domain Names - Implementation and Specification USC/International Sciences Institute, USA (November 1987) 18 Codes for the Representation of Names of Countries ISO 3166, Geneva, Switzerland (May 1981) 19 Crocker, D H RFC 822 : Standard for the Format of ARPA Internet Text Messages University of Delaware, USA (August 1982) 20 Partridge, J RFC 974 : Mail Routing and the Domain System CSNET CIC BBN Laboratories Inc ., USA (January 1986) 21 Larmouth, J JNT Name Registration Technical Guide Salford University Computer Centre, UK (April 1983) 22 Information Processing Systems - Open Systems Interconnection Basic Reference Model ISO IS 7498, Geneva, Switzerland (1984) 23 Data Communication Networks: Message Handling Systems CCITT Recommendations X .400-X.430, ITU, Geneva, Switzerland (1985) 24 Information Processing Systems - Open Systems Interconnection - The Directory ISO/DIS 9594/1-7, Geneva, Switzerland (1987) 25 Data Communications Networks : International Public Directory Services CCITT Draft Recommendations X .500 series, ITU, Geneva, Switzerland (1987) 26 Danielsen, T, Pankoke-Babatz, U, Patel, A, Pays, 0 P, Prinz, W, Smaaland, K and Speth, R 'The AMIGO project - advanced communication model for computer-based communication environments' Proc. Conf. on Comput. Supported Co-operative Work Texas, USA (December 1986)

243

27 Thomas, R H 'A majority consensus approach to concurrency control for multiple copy databases' ACM Trans. Database Syst Vol 4 No 2 Qune 1979)

Vincent Ryan received his BSc(Hons) in computer science from the University of Dublin in 1985. He was seconded to the ESPRIT EuroKom project where he was responsible for setting up the EuroContact directory service. He has also set up a pilot directory service as part ESPRIT ThORN of the project He is currently completing his MSc research into OSI directory services.

244

Ahmed Patel received his MSc and PhD from the University of Dublin in 1977 and 1984 respectively. From 1984 to 1986 he was responsible for developing the EuroKom Computer Conference and E-Mail Service which is used by ESPRIT participants . He currently lectures in the Department of Computer Science at UCD. His interests include computer networks, conformance testing of communications protocols, network security, network management, integrated broadband communications networks, message handling systems, distributed processing and real-time multi-task operating systems .

computer communications