Everyone needs Directories!


The title of this chapter is quite a sweeping statement, you'll no doubt agree. But when you stop to think about it, you'll see that it is quite true. Imagine having a telephone in your house, but not having a telephone directory, or recourse to the 'directory enquiries' service. The phone now becomes a lot less useful than it was. How can you telephone your Auntie Margery in Australia to wish her happy birthday? You may not remember which digits you need to dial for international access, nor can you remember all the several hundred different country codes. And what if she has recently moved house, but you don't yet have her new address? Or what if you want to ring up several stores in town to see which one of them has the latest 'green' garden fertiliser in stock, and which one has the most competitive price? The examples might be flippant, but they make the point. Whilst it may be possible to keep your own address book of friends, colleagues and relatives that you call most frequently, it certainly is not possible to keep an address book of everyone whom you have ever called, or whom you are likely to want to call in the future. And who is going to update your personal directory when people change addresses, or get a new job, or install a new line for a fax machine? So you can see that everyone needs access to address books and (telephone) directories at some point in their lives.

Ideally we would all like access to more than the conventional telephone directory. As it stands, a paper directory, or directory enquiries service, is very limited in the service that it offers. For a start, the paper one is always at least six months out of date. And the directory enquiry service is very expensive to use in some countries. Not only that, but the national and international ones are accessed differently. Computer access to a conventional database gives you many more features such as: rapid scanning of thousands of entries, retrieval of entries with similarly spelt names, and retrieving the name of a person with a given telephone number or address. If only we could computerise the entire set of global telephone directories, and interconnect them, and give people access to them all via a standard interface, then we would have a real directory service. X.500 of course is designed to provide this service, and many more besides.

Fax is a very common form of media used in transferring business documentation. If I want to fax a message to someone, I often have to phone the person first to obtain their fax number, before I can fax the message. British Telecom started to provide a fax directory service, in order to obviate the need for this 'look-up' phone call. However, it was reported in the press during September 1992, that the service was being withdrawn, due to the administrative overhead associated with keeping the directory up to date. This leads us to the conclusion that it would be much better to allow the administration of a global directory to be devolved to the participating parties, rather than trying to co-ordinate everything centrally. The X.500 Standard assumes distributed administration of the database, and specific functions are built in for this. X.500 is also designed to store lots of information such as fax numbers and telephone numbers in the same database. The existing pilots (§ 1.4) are very good for this. Where else can you look up, from a PC on your desk, the fax number of nearly every UK university academic member of staff?

Computers have similar requirements to people in respect of directory access. In order to make a connection, or send a message, or whatever the driving application requires, the software (and hardware) needs an address to process. Whilst it would be, and is, possible to provide the application directly with the address of the remote entity, in practice it is found to be better to provide a level of indirection. This is achieved by giving a name to the remote service, or computer, or application, and providing the local application with that name. The remote name to address 'look up' is then provided via a table, or a database or a directory. This shields the local application from changes of address of the remote entity caused by such things as re-configuration, replacement of hardware, or migration of a service between different nodes in a distributed system. The service which maps the name into an address, which is in essence identical to the white pages telephone directory service, has been given various titles such as name server, white pages, WHOIS etc. X.500 is designed to provide this type of service to computer systems, using the same message passing protocol as that provided for human users. Both human and computer targeted information is held in the same global database.

Another requirement, and from the perspective of the International Telecommunication Union - Telecommunication Standardisation Burean, the ITU-T (formerly the CCITT) perhaps the most important requirement, is that demanded by electronic mail users. Email users need to know the electronic mail addresses of other Email users. The requirement is identical to that of the telephone or fax user, but the need is more urgent, since an existing paper based service does not already exist. Proprietary Email systems such as cc:Mail and IBM's Profs have built in directories containing the Email addresses of all the local users, but inter-system mail is not usually catered for. In order to send the first Email message to a colleague in another organisation, it is often necessary to telephone them first to get their Email address. Once the first message exchange has taken place, we can usually store their Email address in our local directory, where it will stay useful until it changes, but it will not be automatically updated when it does. X.500 is designed to solve these problems, by allowing all local Email addresses to be entered and stored locally. Both local and remote users are allowed to have equal (subject to local security policy) access to them, and our local users may have access to remotely stored Email addresses. And if organisations or divisions want to store local copies of remote Email addresses held on remote systems, then automatic copying and updating of the data is possible.


Coming from the two different, but very similar directory requirements, of humans and computers, the international standardisation of the Directory was born. Originally, there were three parallel activities. On the one hand there was the CCITT (now the ITU-T), whose major concern was to provide a white pages service that would return either the telephone numbers or X.400 O/R addresses of people, and on the other there was the International Standards Organisation (ISO) and the European Computer Manufacturers Association (ECMA), who were concerned mainly with providing the name server service for Open Systems Interconnection (OSI) applications. Inevitably, the two tracks would merge, and they did in 1986, with the formation of the Joint ISO/CCITT working group on Directories (w/w 1.1). The interests of ECMA were subsumed by ISO, since the former sent delegates to meetings of the latter.

Notable dates in the history of X.500 standardisation are shown in table 1.1.

Table 1.1 Notable dates in X.500 standardisation

Event  Date
CCITT Study Group VII, raise Question 35  1984
ISO start work on Directories in SC21 WG4  1984
First Joint Meeting is held (Melbourne)  April 1986
ISO Draft Proposal (DP) starts its ballot (3 months)  November 1986
ISO 2nd DP is balloted (3 months)  July 1987
ISO Draft Standard is balloted (6 months)  December 1987
Work starts on the ('92) extensions to the ('88) joint Standard (Question 20 within CCITT SG VII) March 1988
Final Editing Meeting of the ('88) joint Standard October 1988
Access Control ('92) Provisional Draft Amendment (PDAM) is balloted (3 months)  November 1989
CCITT X.500 Blue Book Recommendations are published (The official CCITT version of the '88 Standard)  January 1990
Replication and remaining ('92) extension work PDAMs are balloted (3 months)  December 1990
ISO/IEC 9594 - The Directory - is published (The official ISO version of the '88 Standard)  January 1991
('92) extension work ISO second PDAMs ballot starts (3 months)  May 1991
('92) extension work ISO DAMs are balloted (6 months)  November 1991
('96) extension work starts  May 1992
Final Editing Meeting of 1992 extension work  October 1992
ISO/IEC 9594 (1993) - The Directory will be published (The official ISO version of the '93 Standard)  1Q 1994 ??


A well known multi-national manufacturer of glass products has manufacturing plants and offices throughout Europe. It employs over 6000 people world wide. The head office is based in Brussels, but each site operates reasonable autonomously, as a profit centre.

A major manufacturing site in the UK has installed a local area network, based on PCs and ethernet. It plans to have Email facilities available to every site employee (around 600 people) during the next few years. The package chosen is cc:Mail. This was judged to provide the best user facilities for their employees.

A major manufacturing site in Germany has a PC based ethernet network, and its chosen Email package is MS-Mail. The R&D division in the UK uses DEC's All-in-One system. Other sites have still to choose their preferred Email packages.

The head office has decided to install a corporate X.400 backbone Email service, with gateways between the proprietary Email packages and X.400. This will eventually allow all employees to electronically communicate with each other, irrespective of their sites and end systems. It is also a strategic move, that will facilitate electronic communications with other business and trading partners when this is judged necessary.

However, there is the proverbial directory problem to address. How does a user in the UK work out the Email address of someone in Germany. The cc:Mail administrator does not want to populate the cc:Mail directory with the complete set of 6000 corporate names and addresses. (And obviously this solution cannot be used later when external companies come on-line.) Most cc:Mail users will not need most of the external mail addresses, and so their cc:Mail directory accesses would be severely hampered by all this extra clutter. There would also be the problems of replication of data between the sites, and the administrative burden of having to update ten times as much data in the cc:Mail directory.

Enter X.500, the ideal solution. X.500 allows each site to have its own Directory system. The administrators at each site need to only keep their own site's data up to date. Users access the local X.500 system only. If the person being looked for works at the local site, their entry will be in the local X.500 system. If the person works at a remote site, then the local X.500 system will automatically contact the remote X.500 system at the remote site, and will retrieve the information from there. X.500 switching between local and remote access is transparent to the user. If the X.500 access to the remote sites proves to be too slow, then the systems can be configured to automatically copy data to each other, and to regularly update the data. The system also provides security controls, to stop unauthorised people reading data from the Directory. Not surprisingly, the X.500 system can store lots of information, such as X.400 O/R addresses, telephone and fax numbers, computer addresses etc. All that is needed to make the dream a reality, is a product that has a user friendly PC windows based interface, and that can seamlessly integrate with the common PC based Email packages such as cc:Mail!


So how far is this dream away from realization? Whilst such a PC shrink wrapped package is not available at the time of writing, several such systems are currently being developed, and prototypes have been demonstrated. In a few years' time, there should be plenty to choose from.

In fact, the potential of X.500 has already far exceeded the original intentions. Research at University College, London, and GMD, Germany, has successfully demonstrated multi-media use of X.500. It is possible to store passport photographs of people in the X.500 Directory, as well as company logos, and maps. Voice attributes have also been stored there. Imagine going to a business meeting in a foreign country, and prior to your departure, retrieving via the PC on your desk, a picture of your host and a map of your destination. X.500 is versatile enough to allow this and any other commonly usable information to be stored within it.

After completion of the X.500 work in October 1988, no one had experience of running a local X.500 Directory service, let alone a national or global one. So two pilots were started. The White Pages pilot (Rose and Schoffstall, 1989) in the US started in 1989, and its aim was to link up about 15 companies and universities, mainly on the East Coast of America, in order to provide a replacement for the Internet WHOIS service. It was partially funded by the US DARPA. This grew substantially over the first three years, so that by 1992, over 100 organisations were participating in the pilot, and the Directory was holding nearly half a million entries.

At about the same time in the UK, the Joint Network Team of the University Funding Council, started a pilot involving a handful of universities, who were given a Sun workstation and the Quipu software. (The Quipu X.500 software is public domain software which runs on a variety of UNIX workstations (Kille, 1989; Robbins and Kille, 1991).) This quickly spread to about half of the Universities, who jumped at the chance of free kit. By February 1993 there were 59 UK organisations involved, holding collectively over 100 000 entries.

Shortly after the UK pilot started, in November 1990, the EC, via COSINE, funded the Paradise project, whose aims were to pilot an international Directory Service, linking the US and UK pilots, as well as other countries who were planning them. By 1993 approximately 20 countries in Europe had joined Paradise, with six countries from the rest of the world also participating. Nearly a million entries were then stored in the global Directory. Paradise offers a publicly accessible user interface into a pilot global directory service, available via PSS, Telnet or a modem, so that people can try it out and get a feel for the system.

Unfortunately both the US and UK pilots, which are by far the largest to date, initially only had limited success. The main problems encountered by both were: lack of good quality data in the system, slow response times, system unavailability and poor quality user interfaces. Potential users therefore found that the system offered a poor quality of service, and it was slow to catch on. Poor data quality was the result of two inhibitors - lack of manpower resources to load and update the data, and administrators' fear of making 'their' data available to external organisations. The latter was not unfounded, since the early Quipu implementation was not designed to offer a secure service. The solution really was only to add 'public' data to the Directory. Data security was not addressed in the first (1988) edition of the Directory Standard, due to lack of time, and so implementors had to produce their own access control schemes. The 1993 edition of the Standard does have a comprehensive access control scheme defined, and so one can expect more secure products to appear in the next few years. Current work in Europe's Password project (Roe, 1992), and the UK's Ministry of Defence, envisage using the Directory by the mid 90s to securely store information on behalf of users.

Part of the reason for poor quality user interfaces, was that the early ones were designed and built by the systems analysts and programmers who built the DSAs, i.e. the technocrats. It is the end users who need to be more involved in the interface design. New user interfaces are announced almost monthly, and the Paradise International Report (1991) surveyed 15 DUAs (Directory User Agents). PC windows based products are now starting to appear, and so we can expect to see a lot more of these in the next few years. The user interface designed by the Paradise project is worthy of note. Whilst only operating in line mode (this is necessary since modem access is given to dumb terminals) nevertheless the interface is easy to use and offers a comparatively high quality of service. Interested readers who posses a modem and terminal emulation software can try it out. Simply contact the Paradise Helpdesk. (Tel +44 171 405 8400 x432. Fax +44 171 242 1845. Internet Email:, or look them up in the Directory!)

Slow response times and lack of robustness were particular features of the early Quipu implementation, but this should not be taken as an indication of the likely performance of manufacturer supported products. For example, a pre-release version of a major US computer manufacturer's DSA, holding 100,000 entries on a 15 mip machine, is capable of more than 50 Read operations per second. Measurements taken at the University of Salford, of the performance of the UK pilot in 1993, reveal that searches of any organisation in the UK, from a user interface (DUA) located at Salford, on average return a response within 10 seconds.

Experimentation with pilot X.500 services is still increasing. In 1992, the North American Directory Forum, which is a collaboration between the major commercial messaging providers in the US, started the technical testing of its implementations. This should reach full steam in 1993. Commercial testing of a pilot should start in 1994. Pilots are also operating in countries as diverse as Japan, Australia and Sweden.

We may not have a fully usable global Directory service yet, but usable pockets of data are starting to grow. For example, I wanted to send a fax in August 1993 to an acquaintance working in the Swiss PTT, and from the PC on my desk, I retrieved the fax number from the Paradise pilot within 10 seconds. The buds of an international directory service have now appeared, and the service should blossom over the next few years.


1.1 The early standard's meetings were not without their ISO v. CCITT friction, with each country sending separate CCITT and ISO representatives. The party lines were drawn on people's affiliation to their particular standards making institution (CCITT or ISO) rather than along national boundaries. It was much more customary for the BSI and ANSI representatives to agree, and to be opposed by the AT&T or BT representatives.

But within a couple of years this all changed, with countries sending one set of representatives drawn from both their PTTs and national standards making bodies who shared a common position. Now it is usually irrelevant, and impossible purely from a person's technical stance, to tell whether a person's background is BT or BSI, and AT&T or ANSI. We are back to good old nationalistic tendencies!