UK Academic Community Directory Group Minutes of Meeting on 23rd October, 1989 Paul Barker Organisation: UCL Document Location: UCL ABSTRACT Minutes of the Fifth Meeting of the UK Academic Community Directory Group held at University College London on Monday, 23rd October, 1989. May 30, 1990 UK Academic Community Directory Group Minutes of Meeting on 23rd October, 1989 Paul Barker Organisation: UCL Document Location: UCL Present: Ben Anrep Poly. of Central London Adrian Barker UCL Paul Barker UCL (Secretary) Steve Benford Nottingham Chris Bayliss Birmingham Graham Carpenter Surrey Mike Collett Nottingham Shirleen Craig Heriot-Watt Jim Craigie JNT (Chair) Andrew Dand Bath Bob Day RAL Neill Edwards CEC (Guest) Jill Foster Newcastle Andrew Findlay Brunel Mike Guy Cambridge Julia Hill Heriot-Watt Mick Kahn LNT Catherine Kelleher LNT Steve Kille UCL Caroline Leary Sussex Chaoying Ma Cambridge Damanjit Mahl Brunel Diane McDonald Strathclyde Peter Mills Manchester Andrew Mitchell Reading Julian Onions Nottingham Colin Robbins UCL Marshall Rose NYSERNet (Guest) Graham Rule Edinburgh Danny Smith Univ. of Queensland (Guest) Nicky Watkins RAL John Williams Aston - 2 - Apologies for absence from: Karen Goswell RAL 1. Approval of the Agenda The following agenda was agreed upon: 1. Introductions 2. Review of minutes of the meeting held on 12 July 1989. 3. Matters arising. 4 Directory pilot sites status reports 5. THORN implementation status report 6. Quipu implementation status report 7. Brunel's user interface implementation status report 8. Status of other known Directory implementations 9. Report on the RARE Working Group 3 and RARE Directory Project 10. Data Protection Act 11 Networked Information Services Project 12. NYSERNet Directory Project 13. Report on Directory activities in Australia 14. Any other business 15. Date of the next meeting. 2. Approval of minutes of previous meeting There was far too much too dissent on the previous set of minutes for the secretary's liking! The following points and corrections were made: - Section 8.4. The useful documents referred to had already been copied and were available from John Dyer of the JNT. - 3 - - Section 8.6.11. The second bullet point now reads "A third of the staff at RAL use email." - Section 10. The third bullet point now reads "Sites should avoid choosing legalistic, verbose name forms, not commonly used or known, as their distinguished name. (e.g. The Episcopalian Rutherford Appleton Laboratory of South Chilton)." 3. Matters Arising Actions from the last meeting other than those below were taken as having been completed. 3.1. Directory names for the UK academic institutions Jim Craigie was required to write to academic institutions to determine their preferred name forms. This had still not been done. The Chair took an uncharacteristically lenient view of this! 3.2. UNIX/Quipu configuration guide This had slipped due to the late delivery of the SUNs. Some material was available in draft form. Material was to be circulated to the pilot sites by email as soon as possible. 3.3. Use of JNT-provided hardware. There was a stern reminder that evidence that a JNT-provided SUN was being used to provide general UNIX services would result in that machine being reallocated to another site. 4. Directory pilot sites status reports It was noted that this was the last meeting when spoken reports to the meeting would be acceptable. In future, written reports would be required. Reminders would be sent out at an appropriate moment in advance of the next meeting. The reporting requirements are as follows (text extracted from previous minutes): - Each site should circulate by electronic mail a plain text copy of their report to the Directory Group. - Pretty printed reports should be given to the JNT for circulation. - Participating sites were expected to attend the meetings The reports should contain at least the following: - 4 - - List of what failed, smattering of what worked. (The exact nature of this would obviously change as the project evolved.) - Data acquisition - Data maintenance and management It was important that the reports delineated clearly between system and data aspects. In the short term at least, there would be no common format of report - this might be procrustean with regard to the richness of sites' experience! 4.1. Bath - Had received hardware, which was on the point of being commissioned. - Talking to other South-Western universities about collaborating. - Were looking at data collection. Would start with email list. - Preferred decentralised updating procedures as local sources of data superior. 4.2. Birmingham - Had received hardware, X.25 was working, but had not received coloured book software. - Had received a tape of data from the university administration. - Hoped to integrate computer centre data with admin data. 4.3. Bloomsbury - Had received hardware, X.25 was working, but had not received coloured book software. - Would initially have telephone data, soon to be followed by computer centre email data. - Were pursuing administration to get student registration data. 4.4. Brunel - 80% hardware arrived (no tape drive). Machine running (very quickly!) but only slow X.25. - 5 - - Running Quipu-5.0, which lacked a little robustness - Have all computer centre registered data. - Admin have said that data on all staff and students will be made available, although there were problems on how this would be done. - There was a public access account "brunel.dir" running a dish-based interface. - Kingston polytechnic wanted to put their data in Brunel's DSA. 4.5. Cambridge - Hardware being installed the day of the meeting. - Mainframe users' data available. - Possibly get telephone data - Interested in problems of merging the various data sources. 4.6. Edinburgh - Didn't yet have a machine (their machine was diverted by the Chairman's fiat!) - Would start with data from email directory - Vague promises from admin about other data. 4.7. Heriot-Watt - Had received hardware. X.25 not yet working due to cabling difficulties. No software to run! - Data collection was proceeding slowly. - Staff office were about to ask staff whether they believed data held on them to be correct. 4.8. Nottingham - Had received the hardware, X.25 was working, but software not yet mounted. - Had produced a model of "corporate structure". Top levels of tree would be created by hand, other data filtered in appropriately. - Believed in a supply-led rather than a demand-led - 6 - approach. Users would be asked to comment once a service was offered. 4.9. Reading - Had received hardware, X.25 was working, running coloured books (although not the software that was ordered) - Were still waiting for details of data formats. 4.10. Rutherford - Had received hardware, not yet connected to X.25 or Ethernet. - Were running Quipu on a SUN 4/280. - Had data for all Rutherford staff from SERC database. Data consists of names, organisational roles, office locations, telephone numbers and email addresses. - Rutherford had a complicated organisational structure - it was not obvious how to represent this in the Directory, or whether it should be represented. Aliasing could possibly be used to relieve these problems. 4.11. Strathclyde - Had received hardware, no X.25 yet. - Email and phone data were already available. 4.12. Surrey - Had received machine. It was connected to Ethernet, but not as yet to X.25 (cabling problems). - Data situation somewhat strange. University admin have an oracle system. For security, this is not connected to an Ethernet, but it IS connected to JANET!! Thus, when X.25 is working, will be able to get data. 4.13. Other sites No-one else had anything to report. The Chair then indicated that if other sites wanted to bid for hardware to run a DSA, that they should submit a bid to Jim Craigie at the JNT by the end of November 1989. Inasmuch as it was meaningful to give dates for the delivery for hardware, the projected delivery date was March 1990. - 7 - The following text is extracted from an earlier meeting's minutes, outlining how a bid should be presented: 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. 5. THORN implementation status report 5.1. Current status The group were reminded that the THORN software had been produced by a number of partners (unlike Quipu). The THORN software differs from the Quipu system in several ways, notably that it has a purpose built database and that greater initial effort was put into Directory management tools. Release 2 of the THORN software was now available to the partners and was currently being ported. Key components of this release were: - DAP and DSP - Purpose built database - Replication and incremental update - Schema stored in the Directory - Management tools - Access control (different to Quipu approach) The focus of activity within the THORN project was now to port the software onto all the partners' machines. Inter- operation with the Quipu system would then be vigorously - 8 - pursued. The THORN system was to be demonstrated at ESPRIT technical week in Brussels at the end of November. The project was due to end in December. There were no plans to continue the project under ESPRIT 2. 5.2. THORN and the Pilot There was a feeling that THORN had arrived too late to be of use to the UK Pilot. Experience had shown that the amount of effort required to take a prototype system and turn it into an integrated package suitable for other sites was considerable. It was not clear at the moment whether the THORN system offered a suitable platform for the UK pilot. In addition, there was currently no framework for funding future development of the THORN system. This created a problem for the Pilot as the original premise was that the Pilot would be based on at least two different implementations. The consequences of a single implementation pilot were discussed. It was recognised that a single implementation system gave less assurance that the UK pilot was running conformant, inter-operating software. These worries could be countered in two ways. First, the testing tools implemented as part of the THORN effort had been used to test the Quipu system and gave a good measure of assurance on protocol conformance. Second, the INRIA Pizarro system would be available in the short to medium term and could be used as an alternative system. It was also recognised that a single implementation system was probably of benefit to users in that effort would be better concentrated in the short term. 6. Quipu implementation status report ISODE-6.0 (and thus Quipu-6.0) were expected to be available before the end of the year (slipped from late September). However a pre-release of the code would be made available to the pilot sites, if the sites wished to have it. 6.1. Quipu-6.0 enhancements The following list shows the main development areas between Quipu-5.0 and Quipu-6.0: - Better performance, data stored more compactly - Robustness improved - Generalised attribute handling - IS aligned - 9 - - Better documentation - Distributed operations improved - DSAs use of asynchronous operations, DSA relaying, choice of which DSA to access for replicated data - Authentication and security (pilot will use protected simple authentication) - Work on interfaces - DISH and FRED 6.2. Why continue development - Feedback from users - Interoperability problems anticipated - especially schemas and aspects of distributed operations - Features missing from initial implementation - Some issues needed long term planning: funding for further work; the process of "community consultation"; how the system was to be supported, whether it should be supported by the developers or a special support group. 6.3. Areas for further development 6.3.1. Management tools - Local DUA and DSA configuration - DSA monitoring (static and dynamic) - Statistics gathering and accounting - User data tools, data merging - Directory configuration management, e.g. adding in new EDB files - Storing more information about the Directory within the Directory o DSA size o Usage o Number of errors o DSA configuration - 10 - 6.3.2. User Interfaces - DISH - xface, xwho - FRED - Brunel's user interfaces 6.3.3. Schemas - Improved searching o More syntax flexibility o Better human name matching o User control over matching - Attribute classes (e.g. cellular phone could be a sub- class of attribute class telephone) - Attribute inheritance in subtrees - Storage of schema information in the Directory 6.3.4. Security - Strong authentication - Authentication management - Improved access control (groups and roles) - Authorisation 6.3.5. MHS support - Distribution Lists - Friendly naming - Security - Routing 6.3.6. Distributed Operations - Caching o Storage on disk o Quipu DSP enhancements - 11 - o Parameterisation - Further support for non-Quipu interaction. o Reference storage o DAP only support o Spot shadowing (Quipu model assumes that all siblings held in one DSA) o Improved distributed search - Incremental update - Subtree replication - Improved "choice of DSA" 6.3.7. Miscellany - Asynchronous access at procedural interface - Printed Directory - Network robustness - User progress indication 6.4. Points raised in discussion 6.4.1. Distributed entry While the notion of distributed entries had clear advantages from the point of managing and maintaining the data, the ramifications on distributed operations were immense. 6.4.2. Access control A number of people felt that the ability to exclude (groups of) users from having access was a useful function. A member of staff of a university might be happy for his home telephone number to be available to all except students at that university. It was recognised that this was a non-trivial problem. It was far easier to grant access on the basis of who someone was than to deny access to someone on the basis of who they weren't! This area may need to be re-examined in the light of early pilot usage. 7. Brunel user interface implementation status report - 12 - 7.1. Basic tenets The intention was to produce several easy-to-use, intuitive interfaces which could be operated by most ordinary mortals, Vice-Chancellors excepted! 7.2. Provision of publicly accessible interface An initial experimental interface, based on the widget interface, would be available soon. The hope was that the interface was better as an interface than widget but that it might suffer from robustness problems in its current incarnation. There was a chance that the interface would be distributed with the next release of ISODE if work proceeded rapidly enough. The interface would soon be publicly accessible by calling "brunel.dir" from a pad. The interface would only offer limited functionality: it would not be possible to modify information; certain aspects of searching would not be accessible. 7.3. Feedback People were requested to try the interface and to make comments upon it: the system would probably invite comments to be sent to a specified mailbox. It was suggested that comments could be on the defaults chosen, aspects of interface behaviour and its general usefulness and usability. A questionnaire would also be provided. This would be sent to the JNT for distribution to the appropriate community of users. Such a document would act both as a consultative document and provide publicity for X.500 Directory services. This interface would then be revised as feedback from users was received. 7.4. Development of window based interfaces When the first phase of work on this interface had been completed, work would begin on the window based interfaces, namely X-windows for workstations and MS-windows for PCs. There would inevitably be a substantial development period for this class of interface. The problems of porting a dua onto a PC were an unknown quantity. The question of which OSI stack to use had not yet been finalised. 8. Other Directory implementations There was very little to report. - 13 - 8.1. INRIA The Pizarro system was almost ready to be packaged, but no firm dates could be given. 9. Report on RARE WG3 A meeting had taken place from which there was little to report. The European Pilot proposal was slowly progressing, but the CEC wheels grind exceedingly slowly. 10. Data Protection Act The model registration form presented at the previous meeting was felt to be inadequate as it stood with regard to the section on data disclosure. The wording for the sections on both U.K. and worldwide disclosure had been amended, and these amendments had been accepted by John Woulds, the Assistant Data Protection Registrar. It was agreed that it would be useful to circulate a copy of John Would's letter with the proforma registration form. Such a letter would help convince universities' data protection officers of the acceptability of the proforma registration form. The text of the accepted proforma registration form is reproduced in Appendix A. 11. Networked Information Services Project (NISP) Following some discussion when it became apparent that there might be some common ground between the work of NISP and the work of the Directory Pilot, Jill Foster was invited to talk to the Directory Group about the work of NISP. 11.1. Project background NISP is a project at Newcastle funded by the Computer Board. It is scheduled to run from January 1989 for 22 months. The aim of the project is to develop a prototype set of tools to facilitate group communication and information dissemination within special interest groups (SIGs). These tools would enable SIGs to set up and run: - email-list servers - discussion servers - name servers - file servers - 14 - - database servers 11.2. Assessing services and needs The first stage of the project was to assess existing services and user needs. Information services on JANET and other major networks would be examined. Existing facilities for SIGs would be assessed. Users had been interviewed to evaluate their information requirements. In addition, there had been (and would continue to be) consultation with JANET, the JNT, NISS and the CTI (Computers in Teaching Initiative). 11.3. Functional specification and prototype services. Having assessed existing services and user needs, the second stage of the project would see the production of a functional specification of the service to be provided and a model for the information infrastructure. A prototype software package, which would run on UNIX machines, would be produced in parallel with the functional specification in order to prove and refine the functional specification. The prototype service would: - offer email access to some of the information on JANET NEWS - offer access to Networkshop '90 news - be used by selected SIGs 11.4. Possible use of X.500 There were several areas where it seemed possible that X.500 Directory Services were the best way of providing the required functionality. 11.4.1. Information infrastructure The aim was to coordinate disparate sources of information into a cohesive whole. A fundamental requirement was to be able to locate some top-level server(s) which could hold pointers to where information was stored. This could be achieved by: - distributing the pointers to the information and caching them locally. - 15 - - upward registration on a central server. - a combination of the above. - using Directory Services to hold pointers to the information. 11.4.2. Name servers The aim was to allow a researcher to locate colleagues working in a similar field. It was hoped to use X.500 as quickly as possible for this. 11.5. A meeting of minds? The hope at the outset was that the meeting would lead to each group having a better understanding of the other's work. This was achieved to some degree although the outcome seemed (to the secretary, at least) inconclusive. However, some questions were easily dealt with, and some general observations made: There was no problem for X.500 with the attribute list that had to be supported for NISP's requirements. X.500 certainly seemed the appropriate technology for many of NISP's problems, although how X.500 was used to provide some of the services needed by NISP (e.g. find all the chemists in U.K. universities) required further investigation. NISP's thrust was to providing specific services to small target groups whereas the Directory Pilot was attempting to offer one particular service to a very large community of users. It was felt that it would be useful for the two groups to continue to monitor each other's activities. 12. NYSERNet Directory Project Marshall Rose, ISODE's principal developer, spoke to the meeting about the NYSERNET white pages Directory Service. 12.1. Project aims It was hoped to provide a "production quality" directory service, based on the X.500 technology, to a large community of users in the New York State Educational and Research Network (NYSERNET). Support and consultation would be offered to sites in the NYSERNET according to expertise available. In addition, if any sites in the internet (i- word) wished to participate, they were free to do so, but - 16 - they were not offered the same support facilities. The service to be provided was to be totally abstracted from complexities such as OSI directories, distinguished names and dish! It was hoped to have 2 million entries in the Directory by June 1990. 12.2. Interface criteria The project had started by examining existing, successful services. The information stored and the interfaces to the information were considered. It was decided to produce an interface which resembled the established interface whois. While this was not the most elegant of interfaces, it was well-known to many users in the i-word community and quite liked. A nice feature of whois was that it used short handles, whereas OSI tended to encourage verbose distinguished names. The interface was not to provide entry modification facilities. 12.3. FRED The interface developed is called FRED (FRont End to Dish) and has the look and feel of whois. As the name suggests, it interacts with dish to provide the service. The service is also available by telnet and email. 12.4. Experience so far The pilot had 96,000 entries by 26th September, 1989. The growth of the pilot was constrained by the amount of hand- holding that had to be done with each new site. One million entries by June 1990 was probably now a more realistic target. It was felt that the following lessons had been learned so far: The Directory Group were advised to concentrate on doing a few simple things well initially. There was much to recommend an approach where only a few object classes and attribute types were supported. The Directory tree had to be sub-divided under the country level as there were just too many organisations at that level. In the US, the problem would be solved by placing organisations under states where possible. In the UK, while we would possibly get away with the problem for a little longer, the problem would hit us eventually. (This view was not accepted by all those at the meeting). - 17 - 13. Report on Directory activities in Australia Danny Smith from the University of Queensland reported on directory activities in Australia. (Danny is no stranger to the U.K. academic Directory services scene, having recently been seconded to Rutherford to work on directories.) He reported that there were two or three groups working on Directories in Australia, but as yet no-one had produced a "finished" system. Directory activities were less far advanced than in the U.K. At the University of Queensland, some preparatory work had been undertaken. The administration were aware of X.500 and there were long-term plans for them to use X.500 Directory Services. He also reported on the X.500 standardisation plans for access control. He gave a technical outline of the approach being considered. He then commented on whether these latest plans were likely to be met with approval - the odds seemed to be against. 14. Any other business None. 15. Date of next meeting. Wednesday 24 January 1990 at UCL dept of Computer Science. 16. Actions before the next meeting. JC To write to academic institutions to determine their preferred name forms. JC To set up a new mail list for discussion and information only relevant to the pilot sites, namely "directory-pilot@uk.ac.rutherford" SEK To provide 12 copies of the NYSERNET User and Administration guides with the minutes. SB To circulate copies of a paper on "Corporate structure" to the Directory Group SEK/AF To produce a UNIX/Quipu configuration guide JH To circulate DPA proforma registration forms along with letter of approval from DPR. pilot-sites To arrange software and hardware maintenance - 18 - Appendix A 1. The model registration This was produced by J.M. Hill of Heriot-Watt in consultation with the DPR's office. It is intended as a proforma which may be used by institutions to register for X.500 Directory Services. 1.1. Text of the registration B.1 Purpose: The provision of User Directory Services based on the CCITT X.500 / ISO 9594 standard. Typical activities are: provision and maintenance of national and international directories for the purpose of communication between individuals, both electronically and otherwise; analysis for management purposes and statutory returns. B.2 Data Subjects: S001 Employees, trainees, voluntary workers S013 Advisors, consultants, professional and other experts S030 Students B.2 Data Classes: C001 Personal identifiers [Note: In the future, institutions may wish to include at this point: C052 Qualifications and skills C053 Membership of professional bodies C054 Professional expertise C055 Membership of committees C056 Publications] B.3 Sources and Disclosures: D101 The Data Subjects themselves (source & disclosure) D104 Employers - past, current, prospective - 19 - (source & disclosure) D106 Colleagues, business associates (disclosure) D206 Suppliers, providers of goods or services (disclosure) D382 Other, see below (disclosure) Disclosure D382: further details: Directory information is publicly accessible throughout the U.K. by means of the Joint Academic Network (JANET) and other networks. B.4 Overseas transfers: T999 worldwide: Directory information is accessible through international networks worldwide.