Chapter1

Everyone needs Directories!

1.1 EVERYONE NEEDS DIRECTORIES

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.

1.2 THE HISTORY OF X.500 STANDARDISATION

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

Table 1.1 Notable dates in X.500 standardisation

1.3 A CASE STUDY

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!

1.4 PILOT SERVICES

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: helpdesk@paradise.ulcc.ac.uk, 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.

WEIRD AND WONDERFUL

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!