UK Academic Community Directory Group Minutes of Meeting on 19th April, 1989 Paul Barker Organisation: UCL Document Location: UCL ABSTRACT Minutes of the Third Meeting of the UK Academic Community Directory Group held at the Computer Science department of University College London on Wednesday 19 April 1989. May 30, 1990 UK Academic Community Directory Group Minutes of Meeting on 19th April, 1989 Paul Barker Organisation: UCL Document Location: UCL Present: Adrian Barker UCL Paul Barker UCL (Secretary) Chris Bayliss Birmingham Max Caines Wolverhampton Poly Graham Carpenter Surrey Jim Craigie JNT (Chair) John Dyer JNT Andrew Findlay Brunel Roland Hedburg University of Ume, Sweden (guest) Julia Hill Heriot-Watt Karen Holloway RAL Steve Kille UCL Andy Linton Newcastle Chaoying Ma Cambridge Andrew Mitchell Reading George Neisser MCC Stella Page UCL Geir Pedersen University Of Oslo (guest) Bob Proctor Southampton Dave Richards Bath Colin Robbins UCL Graham Rule Edinburgh Barry Smith Thames Poly Jamie Slee Open U. Alan Turland UCL John Woulds Asst Data Protection Registrar Apologies from: Caroline Leary Sussex Mike Guy Cambridge - 2 - 1. Approval of the Agenda The following agenda was agreed upon: 1. Introductions 2. Review of minutes of the meeting held on 31 January 1988. 3. Matters arising. 4. The Data Protection Act and Directories (John Woulds - Assistant Data Protection Registrar) 5. Data Gathering 6. Demonstration of THORN and QUIPU interfaces and interworking 7. THORN implementation status report 8. QUIPU implementation status report 9. Status of other known Directory implementations 10. Report on the RARE Working Group 3 and RARE Directory Project 11 Storing NRS information in the Directory 12 Initial pilot configuration. 13 Date of the next meeting. 2. Approval of minutes of previous meeting The minutes were approved nem con. 3. Matters Arising Actions from the last meeting other than those below were taken as having been completed. 3.1. Approach to UGC working party An attempt to try to persuade the University Data Processing Officers association and the UGC Admin. Initiative to participate in the Directory Group had drawn a blank. An opportunity to speak to an assembly of the chiefs was missed by virtue of contacting the DPOs a week after they had had their annual meeting. The situation seemed to be that lots of sites were interested but efforts were uncoordinated. However the work of the UGC Management and Administative - 3 - Computing Initiative was of relevance to the group. The initiative is initially an examination of the data typically held by universities and the processes that are performed on that data. The intention is to identify groups of universities whose data practices are similar so that the universities might adopt a more coherent computing strategy. It is clear that the requirements of Directory Services need to be considered in this planning process. It was felt that it would be beneficial for all parties if the meetings were attended by at least one representative from the following groups: - The UGC initiative - NISS - Information Services Project 3.2. Approach to Administrative department Edinburgh reported that they had approached their Information Services department. The lack of suitable hardware to run the Directory Service was the major stumbling block. 3.3. SUN X.25 Andrew Findlay reported that the situation with regard to X.25 for SUNs running OS.4 looked more promising now and that a release was not likely to be too far into the future. 3.4. Hardware to support Siemens Directory Service implementation Steve Kille reported that Siemens Directory Service implementation runs on a Siemens UNIX box. The software is available only under OEM agreements but is probably not of great interest to the UK Academic community. 3.5. THORN procedural interface Due to the importance of getting the software released as early as possible, release of this document has been further delayed. 4. Data Protection Act The meeting was addressed by John Woulds, the Assistant Data Protection Registrar. The following points were made either in the presentation or during the questions and answers session which followed. He first corrected some apparent misunderstandings. He - 4 - commented on an assertion in the minutes that the Data Protection Act (DPA) was better thought of as a Data Registration Act. This was erroneous inasmuch as there was more to the DPA than merely registering. Compliance was expected as well!! He also noted that principle 1 of the DPA requires that data is held fairly as well as legally. In addition he indicated that a data subject did not always have to pay a fee to inspect data held on him or her. The prime intention of the DPA was not one of imposing restrictions but rather one of making the holding of data more open. The Act concerned the rights of individuals. The principles of the DPA are couched as absolutes. However in practice the Registrar will be more interested to see that the intention of the DPA is being adhered to. The notion of damage done by an inadvertent failure to update the directory to reflect a change of room was slight. However while the Registrar had not tended to use his powers very much in the early life of the Act, there was now a greater willingness to do so if the Act was not complied with. There did not appear to be any inherent problems in registering the holding of the Directory Service data within the terms of the DPA. The following points were made: - It would be useful for the UK Academic Community to produce a model registration. This could then be discussed with the Registrar. - It seems preferable for each institution to have a separate registration for the Directory Service. - Registering for world-wide access should not pose a problem. - The EEC may introduce new rulings which will require amendments to the details of registration. The following aspects of managing the data seem particularly important with respect to the DPA: - Who manages each item of data? If a person is allowed to update certain aspects of their own directory entry, responsibilities must be clearly delineated. - What mechanisms are there for ensuring that the data is kept up-to-date? While failure to maintain the quality of data is a problem in itself, incorrect data also means that the DPA has been breached. The rights of an individual in an organisation to go ex- - 5 - directory were limited. An individual may surrender some rights to privacy by becoming an employee of an organisation. A suggestion was made that DPA registrations should be stored in the Directory. Yes! - the Registrar's holding of the DPA registrations are registered under the Act. 5. Data Gathering The following sources of data were cited: - Phone directories - Libraries - Administration centres - Individual departments - Computer centres The need for funding for data gathering was mentioned. The problem was not solved by one-off copying of data, hacked into shape for the directory. It was often relatively easy to get large amounts of poor quality data, or small amounts of good quality data. Getting large amounts of good quality data required hard work. Building tools for maintaining up-to-date information was not a trivial task. It was still the case that very few administrative departments were convinced of the need for Directory Services. Very few such departments had hardware which could run or even access such a service. It was suggested that there should be an OSI requirement in the procurement specification for Academic systems. A comment was made that existing pilot Directory Services were useful if one wanted information about individuals at one of a very short list of institutions! A helpful step in the right direction would be to hold all the names and addresses of all the UK Academic Institutions. An offer from Dave Richards (wearing which hat I know not) to manage this data was welcomed. Jim Craigie said that he would write to institutions to determine their preferred name forms. 6. Demonstration of user interfaces. Highlights of the demo were as follows: - Accessing an ICL DSA using QUIPU's DISH interface and deleting an entry there (no access control!) - 6 - - Using the various flavours of THORN interface to access a QUIPU DSA. - Various searches were demonstrated. The success of these was somewhat limited by network connectivity problems. The THORN interfaces seemed to lack polish in their current state. DISH was an interface aimed at the computer literate, although DISH scripts could be written which would make the Directory Service easier to use for simple queries. 7. THORN implementation status report The code was on its way to UCL at the time of the meeting. A second release of the code would be made in about 2 months time in line with the IS (as opposed to the output from the Geneva Directory meeting of March 1988). The current release supports DAP but not DSP. 7.1. Availability of code to others The DUA could be made available as source. The DSA would probably be available as a binary library. 7.2. Public domain documents Due to the slippage in the delivery of the THORN system, the release of the promised documents had inevitably been delayed. General Architecture - mainly a question of tidying up the document Procedural Interface - being brought in the line with the code. Should be available shortly. 8. QUIPU Implementation status report QUIPU is now publicly available as part of ISODE-5.0 8.1. Technical matters The following is a break-down of possible enhancements to QUIPU. 8.1.1. DSA internals - Performance - Writing cached information to disk. - Reducing the space taken to store an entry in - 7 - memory. Currently about 2k per entry, could be improved by factor of 4-5. - Optimisation of search operation - Select priority of operation, to give priority to human users. - Speed-up updates, although this is not regarded as much of a problem - Searching - More flexibility with syntaxes - Better support for human names. - New matching algorithms - System V portability - Need to solve problem of long file names. - T.61 support 8.1.2. Procedural DUA - Abandon is currently synchronous! - Asynchronous access - interfaces will be able to fire off more than one query at a time. 8.1.3. Distributed Operation - Support for interaction with non-QUIPU DSAs, need to be able to pass referrals to (non-standard) DAP-only DSAs. - Improved distributed search - Authentication and Authorisation - need to move towards a securer system. Strong authentication takes approximately 8 seconds on a SUN 3/50 per operation. Protected simple authentication costs virtually nothing. - Incremental update - DSA should push deltas rather the current copying of large amounts of data 8.1.4. Management This was promised "sooner rather than later"!! - Less editing of EDB files, more management should - 8 - be done over the net. - Tools to monitor DSAs - User data management tools - Directory configuration management - Production of a printed directory 8.1.5. User interfaces - Work to continue on DISH - xface and xwho programs using DAP - Marshall Rose to produce naive-users white pages interface. - Andrew Findlay producing a JNT-funded user interface. 8.1.6. X.25 - Situation appalling - Lack of support for Camtec/Dexpand - Sunlink - still no X.25 for OS.4 - Urgent need for ISODE / X.25 ports 9. Other Directory implementations 9.1. Other THORN partners' implementations 9.1.1. ICL ICL have developed their own experimental DSA. This is the THORN database (developed by ICL) accessed by an ICL protocol stack and ICL superstructure. 9.1.2. INRIA INRIA have taken the exact opposite approach. They are using the THORN protocol engine (developed by INRIA) over their own database. It will include DSP operation. The system is some way from being ready. 9.1.3. Siemens Demonstrated system with 4 DSAs at CEBIT (some DSAs at CEBIT, some at Siemens). DAP only. - 9 - 9.2. Other implementations 9.2.1. RETIX Demonstrated at CEBIT, interoperating with Wollongong systems. DAP only. 9.2.2. Wollongong Demonstrated at CEBIT, interoperating with RETIX systems. DAP and DSP. 9.2.3. EAN/Sydney Should include distributed operations. Available around June. 10. Report on RARE WG3 RARE is an umbrella organisation for national organisations such as the JNT within Europe. 10.1. Meeting report There had been a WG3 meeting on the previous day (18th April). A European Directory is to be funded to coordinate directory activities throughout Europe. Countries initially participating include UK, Holland, France, Germany and Scandinavia. The intention was to experiment while moving steadily towards to a more service-oriented environment. The THORN naming architecture has now been split into 2 parts; the THORN system architecture (with THORN specific bits) and the THORN and RARE X.500 naming architecture. There was also a discussion on coping with the different rfc822 and grey book mail formats. It was agreed that the mail addresses should all be stored as rfc822 and that interfaces could be made to do the "right thing" according to the religion of the user. 11. Storing NRS information in the Directory. Initially information would be extracted from the NRS database and down-loaded into the X.500 systems. Eventually, the shadowing would be done in the other direction. UCL is currently investigating schemas for storing NRS information in an X.500 directory (Steve Kille has produced a note which will be distributed to the Directory group). It was suggested that FTAM processes should be registered in - 10 - the directory. UCL can provide an example entry. 12. Initial Pilot Configuration 12.1. Funding for Hardware The Chair noted that a major impediment to the progress of the UK Pilot seemed to be the lack of suitable hardware to run the software on. There was general agreement with this statement. The Chair then indicated that the Computer Board might be prepared to fund some hardware, initially for a limited number (6-12?) of sites. [The Computer Board has some extra funds earmarked for OSI Transition, but which are spread across three financial years. It is expected this will enable each University to be provided with hardware to operate a Grey Book/ISO-10021 mail converter (eventually). A DSA could co-exist on the same hardware. A case could therefore be made for early hardware provision for the directory pilot, but the amount available this FY is limited.] There was then some excited discussion of the resources that would be required to run a DSA. It was decided that the issue of what constituted suitable hardware should be dealt with separately by a technically qualified group. Sites wishing to participate in the directory pilot were invited to make a case. Guidance was given as to a suitable form of bid. - The bid should be service oriented. - The bid should show how the service provider was liaising with the institution's administrative departments. - The bid should discuss the steps taken to get a basic system going. - The bid should discuss what the site was proposing to do to get the system out to users. - The bid should discuss data gathering and ongoing data maintenance arrangements. - Bids should not discuss hardware. The Chair also indicated that participants in the Pilot would be expected to produce reports of their experiences in operating a service. - 11 - Bids should be sent to Jim Craigie at the JNT by the 17th May 1989. 12.2. Current state of preparedness by site Sites represented at the meeting were asked to indicate the current state of their preparations to participate in a Directory Pilot Exercise. 12.2.1. Surrey - Had already ported QUIPU. Had only 3 entries in database. - Just started talking to Admin people. Should get data for all at the University. 12.2.2. Heriot-Watt - Were already gathering data. - Planned to take up an offer from UCL to run a Heriot- Watt DSA at UCL until hardware could be found at Heriot-Watt. 12.2.3. Brunel - Had already ported QUIPU. Had 600 entries for computer-using staff. - Two DSAs were envisaged. - Already had embryonic admin and phone data. - Planned to give people line-mode access using dish. - Planning to develop interfaces suitable for naive user, to run on UNIX and MS-DOS machines. 12.2.4. Newcastle - Data gathering was well advanced, waiting for hardware. - Had access to on-line telephone directory, on-line address book and email addresses. - Can get student records each year. 12.2.5. JNT - JNT data would be held in a DSA at UCL. - 12 - 12.2.6. Reading - Email data available - Not sure whether phone data available on-line - Student records were on a non-networked machine. - The admin people seemed fairly keen to cooperate. 12.2.7. Rutherford - Had a copy of QUIPU but not ported it yet. - Already had the data that was used as part of THORN LSPX (although this needed updating). - Hoping to get data from admin 12.2.8. Thames Poly - Pointed out that they would get no help from the Computer Board. - Data was available - Until hardware was made available, would take up UCL offer to run a Thames Poly DSA at UCL 12.2.9. Bath - Porting QUIPU onto a Gould machine - Not sure about data situation 12.2.10. Edinburgh - Were porting QUIPU - Had email data and phone data. - "Looking forward to getting admin data after the relevant negotiations with admin. Are intending to mount initial directory before this data is available (partly to show the usefulness of a directory to admin!)." [quote GR] 12.2.11. Open University - Plans for campus mail service, hence requirement for directory support - Currently lack hardware for Directory Service - 13 - - Plan is to run software on a SUN 4, waiting for X.25 support 12.2.12. Wolverhampton Poly - No major objections from the admin department to providing data. 12.2.13. Birmingham - Admin were happy to release data on staff, but possibly not for students 12.2.14. UCL - Computer science will run both THORN and QUIPU DSAs. - Dish just about to be released to all in the CS department. - Departmental data regularly updated automatically. - Computer centre email data - investigating automation of updates - College phone data on non-networked machine - investigating whether this situation can be remedied. - Should be able to get admin data. 12.3. Computer Teaching Initiative There was a discussion on whether Directory Services had any part to play with respect to the requirements of the CTI. The question was put as to whether it would be possible to use X.500 Directory Services to discover all the Organic Chemists in GB. There was discussion of how such global searches might be obviated by the building of lists or how searches might be speeded up by judicious replication of data. However, the upshot of the discussion was that it seemed probable that the CTI would be over by the time that the Directory Service was sufficiently established. 13. Date of next meeting. Wednesday 12 July 1989 at UCL dept of Computer Science. 14. Actions before the next meeting. JCraigie To write to academic institutions to determine their preferred name forms. - 14 - JCraigie To talk to groups such as Information Services Project and UGC Initiative about their having representatives at the Directory Group meetings. CJR To provide an example of an FTAM registration in the directory SEK To circulate note on storing NRS information in the Directory PB To set up accounts etc. so that Heriot-Watt and Thames can run DSAs at UCL JMH To produce a model Data Protection Act registration.