UK Academic Community Directory Group Minutes of Meeting on Jan 31, 1989 Paul Barker Organisation: UCL Document Location: UCL ABSTRACT Minutes of the Second Meeting of the UK Academic Community Directory Group held at the Computer Science department of University College London on Tuesday 31 January 1989. May 30, 1990 UK Academic Community Directory Group Minutes of Meeting on Jan 31, 1989 Paul Barker Organisation: UCL Document Location: UCL Present: Adrian Barker UCL Paul Barker UCL (Secretary) Chris Bayliss Birmingham Max Caines Wolverhampton Poly Jim Craigie JNT (Chair) Andrew Dand Bath Bob Day RAL John Dyer JNT Andrew Findlay Brunel Andrew Gosling Reading Mike Guy Cambridge Julia Hill Heriot-Watt Karen Holloway RAL Peter Houlder Kent Mick Kahn LNT Steve Kille UCL Caroline Leary Sussex Andy Linton Newcastle Chaoying Ma Cambridge Peter Mills UMRCC Andy Powell Bath Bob Proctor Southampton Dave Richards Bath Colin Robbins UCL Graham Rule Edinburgh Jamie Slee Open U. Peter Stone Sussex Alan Turland UCL - 2 - 1. Approval of the Agenda The following agenda was agreed upon: 1. Review of minutes of the meeting held on 7 October 1988. 2. Matters arising. 3. THORN implementation status report 4. QUIPU implementation status report 5. Status of other known Directory implementations 6. Report on the RARE Working Group 3 and RARE Directory Project 7 The implications of the Data Protection Act on Directories 8 Putting Intelligence into a Mail User Interface using THORN's ECMA TR32 implementation. 9 User Interface Requirements 10 Initial UK AC Directory Pilot Configuration 11 Initial UK AC Directory Pilot Data Set 12 Date of the next meeting. 2. Approval of minutes of previous meeting The minutes were approved nem con. However it was noted that the computers produced by Siemens could not be classified as "obscure European hardware". Indeed by the end of the meeting, most of those present had shown considerable interest in Siemens' range of products! 3. Matters Arising Actions from the last meeting other than those below were taken as having been completed. 3.1. QUIPU bulk data file format A sample of QUIPU bulk data has not been circulated as yet. The action has been transferred to someone more dependable! 3.2. QUIPU bulk data format checker It is not clear whether this is useful at the moment. The action has been dropped. - 3 - 3.3. THORN procedural interface There was an enquiry as to whether this could be released to the group. The document is now almost ready for release. 4. THORN implementation status report 4.1. THORN LSPX It was noted that the THORN LSPX (Large Scale Pilot eXercise) was still running. The number of sites running the system had stabilised. There was also no development effort being put into this system. 4.2. Timescales The timescales for the THORN X.500 system were still slipping. Integration of the code was proving to be a very difficult task. The dates were now: Apr 1 Release within the project and to current LSPX sites; Jul 1 Release outside of this group. 4.3. Interworking Some interworking tests had already been done and these had revealed problems at the presentation level. 4.4. Licensing The position with regard to licensing was still unclear. The project partners suffered from conflicting objectives. They wanted - the system to be as widely used as possible; - to be able to develop their own products using the THORN code as a basis. The following compromise was currently being considered. The user interfaces and protocol engines would be available as a source code release. Management tools and infrastructure would be binary releases. In addition, it might be possible to have some special licensing agreement to allow the code to be ported to machines for which binary versions were not available. A final decision on licensing requires more precise knowledge of the likely diversity of hardware which will be used to run the code. - 4 - 4.5. THORN documents The following documents would be made available in the public domain: General Architecture - currently needs revising but will be available in approximately one month's time; Procedural Interface - needs to be brought in line with the code, available in approximately one month. Naming Architecture - is already available. This document makes a substantial number of user attributes available to a lager commmunity. It is hoped that the early publication of this document will avoid duplication of object identifiers and attribute syntaxes. 5. QUIPU Implementation status report 5.1. Technical matters 5.1.1. Progress Since the last meeting, the QUIPU implementation had matured considerably. The current implementation is available to ISODE beta sites as a part of ISODE-4.2 and is close to what will be available as part of ISODE-5.0. The following changes and events since the last meeting are of note: - DSP has been added to give standard distributed operations. This replaces the use of DAP. - There has been considerable enhancement of the user interfaces. - Robustness has been improved. - QUIPU was demonstrated at ESPRIT technical week. This is believed to have been the first public demonstration of distributed X.500 with multiple DSAs. 5.1.2. User interfaces QUIPU is distributed with 3 interfaces, but further development work is being focused on just one of these, i.e. DISH. This is a DIrectory SHell and is analogous to the MH mail interface. It is particularly suitable for the computer literate. There is also a widgets interface (not X widgets) and a - 5 - SUNview interface which others might care to develop. It was noted that there is still a need for a window-based interface (probably X windows) and a naive users' interface. 5.2. Timescales ISODE-5.0 is scheduled for release on March 28th. 5.3. Outstanding technical issues 5.3.1. Addressing There is no standard for presentation addresses as NSAPs don't exist. THORN and QUIPU have agreed an interworking format. Details of this format have been published in UCL Research Notes 89/13 and 89/14. There was general agreement that everyone wanted to run Directory Services over CONS but the unavailability of same made this problematical. It was up to everyone to put pressure on their suppliers to make X.25 (1984) available as soon as possible. In the shorter term pragmatic solutions had to be adopted. 5.3.2. ISODE It was noted that ISODE makes extensive use of structure copying which causes several users problems. Edinburgh reported that the Gould machines do not perform structure copying correctly. Patching the code provides a time- consuming short term fix. In the longer term, pressure must be put on suppliers to produce compilers that work satisfactorily. 5.4. Usage of QUIPU QUIPU was now being used in at least 6 countries. At least 20 DSAs were semi-connected. 6. Other Directory implementations 6.1. EAN It is produced by a group at University of British Columbia and is due very shortly. It will be available from UBC under license or from Sydney as a product. Initially it will be for UNIX systems, with a VMS version to follow in the mid term. Licensing could either be on a per machine basis or the JNT could possibly buy it for the academic community. 6.2. Retix Retix produced the first known working version of X.500. It - 6 - is distributed within the U.K. by CAP. It is supplied in kit form. The purchaser has to integrate their own database and user interface with a provided skeleton. 6.3. Siemens As well as being a member of the THORN consortium, Siemens are producing their own independent product. It is apparently well advanced. It is also for UNIX systems although it is not known which hardware the software is being developed for. There is an action to obtain more details of this implementation. 6.4. CSATA Italian - nothing else known! 6.5. NIST (NBS) System expected to be available in late 1989. 7. Report on RARE WG3 RARE is an umbrella organisation for national organisations such as the JNT within Europe. 7.1. Purpose of WG3 WG3's function is provide European level linkage to the various Directory Service pilots. In particular the RARE pilot was intended to: 1) support FTAM (coordinated with WG2), 2) provide a White Pages pilot. There are a number of important areas outside of the scope of the current standard. RARE can help to coordinate approaches to these areas which are not fully specified to facilitate interworking. The group can also pass on early experience of running pilots to countries with less experience in the area. 7.2. Current initiatives within Europe - The UK had assembled a superb team of wise (wo)men! - Scandinavia - project underway. - France - project underway. - Netherlands - project soon to be established. - 7 - - Germany - paper study by DFN well advanced. 8. Implications of the Data Protection Act The Data Protection Act sets out to control the quantity and quality of data held about individuals by establishing a number of principles covering electronically accessible data. It also provides a mechanism for people to examine data held on them, subject to some restrictions. It is worth noting before trying to understand the Act that it is in fact a Data Registration Act and not a Data Protection Act. There are 8 main principles: 1) Information held must be acquired and held legally in the broader sense. 2) The purposes for holding data must be specified. 3) The data must be used in accordance with the registered purpose. 4) The data held should be adequate and not excessive 5) The data must be accurate and up-to-date. 6) Data must not be held longer than necessary. 7) A data subject is entitled to be informed that there is data held about them and there should be a means to allow a data subject to inspect that data. 8) There should be security against unauthorised access or destruction of the data. 8.1. Registration There did not appear to be any prima facie problems caused by trying to register the Directory Service under the Act. As the information which would appear in the directory was almost certainly already held electronically by the various institutions, holding the information was not a problem. There are however a number of issues which depend on the form of an institution's existing registration. 8.1.1. Single or multiple registration Some institutions have several registrations for more specific categories of data. This allows an institution to reduce the amount of data that is revealed if a data subject wishes to inspect the data held on them. As a corollary, it - 8 - makes it very expensive for a data subject to establish whether the data held on them is accurate or justly held, since a fee must be paid per registration. A sample of 18 institutions revealed that 13 had a single registration and 5 had multiple registrations. However, complying with the Act with respect to Directory Services appears to be neither facilitated nor made more awkward by this aspect of registration. The important detail appears to be details of information disclosure. 8.1.2. Disclosure of information. Specifying who information may be disclosed to is analagous to Directory Service access control. The Act's mechanism is as follows. Each registration consists of one or more Purposes. Examples of purposes might be "Personnel and Academic staff records" or "student academic records". Each Purpose comprises the following categories: - Who the data subjects are; - What data is to be held; - The source of the data; - Who the data may be disclosed to. It is the last of these categories that poses the problem for institutions running Directory Services to stay within the scope of the Act. Since access is intended to be worldwide (at least for less sensitive information such as name, phone number and work address), each site will need to register a purpose with category T999 (worldwide access) disclosure. It is likely that most sites will have to register an additional "Directory Services" purpose to stay within the bounds of the Act. 8.2. Results of survey on what/how information is held 18 sites replied to a a brief questionnaire regarding, inter alia, what data was currently held, how it was stored and how it could be accessed. yes no Telephone directory: held on-line 18 0 host on LAN 7 11 Staff records: - 9 - held on-line 15 3 easily accessible 0 18 Contact between admin and computer centre: good relationship 17 1 electronic contact 5 13 9. Intelligence within Mail User Interfaces This section is a summary of experience gained at Rutherford with putting an interface to the directory into a mail user interface. The directory used was the THORN ECMA TR32 system. 9.1. Problems with email addressing There were two major problems with email addressing, namely typos and ignorance. Typos will always be a problem, but validating addresses as the message is sent should catch many errors. Current schemes for coping with ignorance of email addresses are unsatisfactory, relying too much on human intervention. In addition, validating addresses as mail is sent gives a user better feedback and there should be less undelivered messages. 9.2. The experiment An experiment was undertaken using the THORN TR32 software, the ELM mail interface connecting to a single DSA at Rutherford. The lack of a search operation in the TR32 protocol creates a serious design problem. Efficient lookups could only be achieved by keying on both a user's name and on their login name, since both name forms were frequently used for email addressing. The performance of the system was rather slow, in large part due to protocol deficiencies which enforce searching to be done at the client, necessitating large transfers of data. The following results were achieved (times in seconds). Initial lookup Subsequent lookup LAN 6-10 3-6 WAN 18-25 7-18 9.3. Limitations of the experiment The work done suffered the following limitations. - The tests were done using a connection to a single on- - 10 - site DSA. In practice however, users tend to know about as much about email addressing as a single local DSA. - The approach used would require similar integration with other mail interfaces. 10. User Interface Requirements 10.1. THORN user interfaces - X.500 versions of the ECMA TR32 interfaces thin thinline. These are command based interfaces. - X windows interface. Multi-windowed, mixture of mouse- driven and text input. 10.2. QUIPU user interfaces Refer to section 5.1.2. 10.3. The discussion I hope I do not denigrate the discussion or those present if I say that this was rather a rambling, discursive session! The following points were raised. - People are anxious that the fuzzy matching capabilities will be adequate as no-one wants to do too much typing. - There was a need for a naive user interface with helpful prompts and messages to the user. (It was reported that the TR32 interfaces gave great anxiety to parents when they saw cryptic messages suggesting that they had no children!) - The MMI should be tunable against a local DSA to optimise performance. - The JNT assured that new interfaces would be developed. 11. Initial UK AC Directory Pilot Configuration 11.1. Early participants It was felt that about 6 sites were required initially to launch the pilot. 3 would use the THORN software and 3 would use the QUIPU system. Representatives from 4 sites at the meeting indicated that they thought that they would be able to participate at a fairly early stage. These were: - Rutherford (THORN) - Brunel (QUIPU) - 11 - - Newcastle (QUIPU) - Bath (????) 11.2. Knowledge management Knowledge is the glue which keeps the disparate DSAs glued together into a coherent directory. This was an area where there would be some early experimentation. UCL would play the major role initially in knowledge management. It was anticipated that the knowledge would be arranged so that a query within the UK academic community could be answered by accessing not more than two DSAs. 11.3. Naming 11.3.1. Naming of organisations There was a lengthy discussion on how the institutions would be named. There was felt to be a need for consistency but it was also thought that some organisations would not tolerate names others than their preferred one. Decisions on this needed to be made at a high level. The naming problem can however be alleviated by the following techniques: - Aliasing - Multi-valued attributes 11.3.1.1. Aliasing Aliasing consists of creating additional distinguished names for an object. However aliasing is probably not appropriate to solve this problem. The principal intention of aliasing is to provide several quite different paths to an entry rather than a number of variants on the end of one path. More precisely, aliases are intended to achieve the effect of an entry having multiple immediate superiors, as opposed to a superior entry having multiple inferior entries associated with a single object entry. 11.3.1.2. Multi-valued attributes Attributes can be multi-valued. Only one of a set of names can be used as (possibly part of) an entry's distinguished name. However when searching for an entry, the whole set of names can be used in comparison with the provided name. A suggested initial style, already adopted by some sites running QUIPU, is that the relative distinguished name for an organisation should be a long form rather than an NRS style acronym. Thus the site hosting the meeting would have - 12 - a relative distinguished name of "University College London" but could include "UCL" or "U.C.L." as additional attribute values. 11.3.2. The importance of Distinguished Names However, contrary to the seeming flexibility offered by aliasing and multi-valued names, distinguished names were very important to get right. While they were intended in some senses to be "just another attribute", in practice users would tend to focus on these names. It was important that these names were intuitive. 11.4. Accounting There would be none initially. In practice the problem is reduced by the use of DSA referral rather than chaining. 12. Initial UK AC Directory Pilot Data Set The initial exercise would mainly concentrate on telephone numbers and grey book mail addresses. While it would not be worth integrating the directory into grey book systems, this would be done for X.400. There could be no diktat about what was and what wasn't in the directory. However it was important that users could establish what sort of information was stored where. Schemas had to be stored in the directory. 13. Date of next meeting. Wednesday 19 April 1989 at UCL dept of Computer Science. 14. Actions before the next meeting. all To put pressure on their suppliers to provide implementations of X.25 (1984). CJR To circulate a sample of QUIPU bulk load data. SEK To ascertain which hardware the Siemens implementation would run on.