It should be noted that these requirements are not only applicable for the pilot service, but for a generic electronic directory to be used by the public administration.
Various objections had been raised relating to privacy of personal data and to an organization's interest in keeping some information on their employees out of the public domain (these concerns are described in next section - Different Views).
The minimum total number of entries would be equal to the number of e-mail users (or potential users) within the organization. It would also be quite useful to include other entries corresponding to other people or organization units without direct access to the e-mail service.
Organizations that should be part of the directory service
Req. 1: All parts of national administrations (central or federal, regional and local administrations) in Europe.
Req. 2: European institutions (Council and Commission specifically). This shall include the autonomous bodies of the Ministries, etc.
Req. 3: Research centres, universities and organizations taking part in European projects (research or otherwise).
Fig 4.1: Organizations to be included
Other international organizations (UN, NATO, etc.) can be included as well as state owned and private companies (particularly public services such as energy, water and transport, etc.).
These requirements, although expressed by the interviewed organizations, are out of the scope of the pilot service. The objective of this project is to promote the use of X.500 directories, including the creation of an initial user group. This will provide the first steps along the road to achieving a critical mass of service providers and users in the future. It is unfeasible to achieve this number of users under this project, despite this it has to be noted here as a requirement for a full service.
Req. 4: An entry shall typically comprise of the following data:
• Personal name
• Organization name
• E-mail address
• Postal address
• Telephone number(s)
• Fax number(s)
• Post (name, roles and responsibilities)
• Organizational unit and/or department name
• Hierarchical relationship
• Activity and services of the organization
• Type of e-mail
• Other communication and documentation facilities and distribution lists
Fig. 4.2: Data of other organization
As shown in the diagram, names (organizational and personal), electronic address and telephone data was requested by 100% of the interviewed organizations. Other fields were suggested depending on the nature of the organization.
There are several reasons for this:
• Data privacy (addressed by data protection laws)
• Technical entries/attributes (for system use only: mail routers and others)
• The organization's wish to limit access to some employee information
The provision of two (or more) different views addresses many of the requirements listed above. The internal view will typically include personal information to be consulted by organizational staff, whereas the public view will include functional information about the organization and how to locate it's official contacts.
The provision of internal and external views does not address the issue of data protection satisfactorily in all cases. For this reason it may be advisable to provide more than one homogeneous internal view - a normal internal view (accessible by everybody within the organization), a private or confidential internal view (with restricted access only) and a technical internal view (system access only). In addition to this, parts of the internal view may be made accessible externally to selected individuals.
In practice it is often very difficult to safely identify the user querying the directory (i.e. avoiding possible attempts at impersonation). Additionally, security policy is difficult to encode and maintain with the current technology. As a result it may not be possible to satisfy the requirement for many views.
The best solution would be to make each field of each entry individually configurable. This would then enable the creation of different views according to the needs of each organization, providing a solution to related organizational problems.
Another aspect of this subject is the set of identification data to show in the different views. At least two different profiles are identified, a staff view (personal entries) and an organizational view (functional role entries).
It would be desirable to have a functional view of the data where different organizational units and their functional roles might appear, although a comprehensive view of this nature will be difficult to organise and maintain.
As a final conclusion on this point, the entries and views suggested here provide a good framework for the generic organization. The specific needs of some organizations, however, would require further business analysis for a detailed DIT (Directory Information Tree) design.
1) To maintain a local directory in a computer belonging to the organization.
2) To send the directory data to an external service provider (similar to the service maintained centrally by EuroView).
Most users will prefer a local directory server in order to maintain control over data updating and user access.
This complies with the underlying X.500 philosophy of data distribution, with every organization taking responsibility for it's own directory (data accuracy, performance, etc.).
But to run a directory implies some investment in computing equipment, software licenses, communication lines and above all maintenance effort. Not all organizations have the required resources for such an investment.
The choice of which of the two options to select will therefore be motivated by the organization's commitment to the service and the amount of resource available. Of course in most cases the resource allocated to any project is proportional to the level of importance associated with the goals of that project!
The issue of directory updating results in two possible options. Both options may be equally suitable for the user and both should be feasible.
Req. 6: At least two methods of data maintenance should be made available to every organization in the directory:
• A file could be generated in a specific format containing the changes to be made, to be sent to the directory manager.
• A remote connection could be formed, thus allowing the directory to be updated directly.
For those private servers, the connection requirements are focused on internal access to the server, although in many cases the main usage of the directory comes from the external organizations querying local entries.
Req. 7: The basic connection method is TCP/IP.
All servers should have IP connectivity with the national server at a minimum, either full Internet (if the organization already has this facility) or leased or dial-up lines (using SLIP or PPP to implement the IP connection to the server). The latter solution has an associated financial and operational penalty since the local server is only accessible when the (possibly expensive) link to the national server is working.
Req. 8: The three national servers should implement connections to international X.25 and the Internet.
This will allow them to act as gateways, interconnecting servers located in different networks and using different protocols.
The use of closed networks (private X.25 networks in particular) is a problem for the pilot service. The scenario where a EuroView server is not able to connect to a certain user has to be taken into account when designing the service, although it is expected that any organization wishing to join the pilot will accept the need for IP or public X.25.
It must be pointed out that Internet connection results in some security problems since sensitive data will sometimes be stored in the servers database.
Req. 9 : Access to the Internet shall be protected against security attacks.
Firewall services will have to be studied carefully and deployed to achieve an acceptable degree of security. This may be more difficult for private servers, and each case will have to be studied on its own merits.
Req.10:Aaccess to the directory through a WWW service shall be provided.
The explosion of WWW servers and clients indicates a strong need for a WWW gateway to the X.500. This service would be located in each of the three national servers, and would consult local data and other servers through X.500, and offer the results as HTML pages. Although the functionality cannot match that of a full X.500 service this is a good way to promote the directory service and make it widely accessible.
Req. 11: Replication of the data in the directories shall be used to reduce the traffic at national and European level.
The EuroView servers shall replicate sufficient information, in particular the root context and the particular national contexts using the X.500 1993 replication facilities, to avoid excessive traffic for trans-national queries.
Req. 12: Directory links with other directory services of the European Commission, other institutions of the European Community and with NameFlow-Paradise, shall be implemented.
Analysing the answers to the questions on "Existing links with other entities", it is clear that the range of directory information made available to an organization cannot be limited to other users of EuroView. Similarly, directory information concerning an organization cannot be made available solely to other users of EuroView.
The User Agent is the most visible part of the service and is a critical factor in providing user satisfaction.
In the case of EuroView, however, the functionality of the User Agent will be constrained due to conformance to the X.500 standard which defines the querying services available to the user. As expected, all services shall be supported by the User Agent.
Free searches by activity, organization, etc. will therefore be allowable operations. It will also be possible to search on an organizational role rather than a personal id (which changes too often), with each role entry being mapped onto the appropriate person or group of people. Another useful facility would be an identification system of the information services associated with every organization, giving the name of the Web server, Videotext address, etc.
The design of the user interface must be ergonomic and adapted to the use that a typical user would put it to: grouping the more frequent commands, showing everything in a coherent representation, etc.
The User Agent for the pilot service will be developed from the existing PC-Pages package. This product has been demonstrated to various future users, and they have expressed their satisfaction with its functionality. On the issue of user interfaces, therefore, all user requirements have been dealt with from the onset.
Req. 14: The User Agent shall be integrated with e-mail and word processing tools as a minimum.
"A directory service without such an integration is regarded as less useful". That e-mail software should be integrated with the directory service seems to be a unanimous opinion. Other potential software suitable for integration would be office applications (word processors, diary managers, etc.), mailing applications, safety software, telephony applications (click and dial), Web service and business applications (form entry, EDI, business transactions, etc.) .
Existing databases
It was also noted that integration should not be limited to the client side only. The source data bases (Ingres, Oracle etc.) might provide the means of presenting data in a format more suitable for the loading of the directories.
Req. 10: Due to technical reasons the response time shall be less than 30 seconds
Req. 11: The service should be made available for 98% of the time, ensuring it is available during all working hours.
A general security requirement could be identification by password. It is essential to ensure that only authorised personnel may access non-public data (i.e. internal or system data views).
Organizations using the external directory service providers could experience security problems, as this would involve transferring sensitive data to an external organization, perhaps a private company.
The data maintenance procedures must guarantee that only authorised personnel are able to modify directory data (either the owner of the data or the directory manager).
Fig. 4.7: Legal and security requirements
It may be appropriate for the provider of directory information to give a guarantee on the correctness of data. If this were the case, many legal implications may result. This issue, together with other issues related to legal and security requirements, will be addressed in another phase of the project (the study of national and European data protection laws).
Some surveyed organizations had specific security requirements due to the presence of important information involving national security, etc. These problems cannot be addressed in this set of general requirements but must be considered and reolved closer to the time of service implementation.
The question of top level naming has not yet been solved satisfactorily in European countries. It is not clear who the official naming authorities representing country-level entries are. This is the case for most European countries, and appropriate actions have been requested from EuroView.
Specific requirements stressed in individual interviews.
MAP: Would like to use the directory for key distribution support, as part of a future clearing centre for telematic services: registered e-mail, EDI, Certification Authority, key distribution, etc.
DGTel: Said one of the problems with e-mail is signature recognition in official documents.
MAFF: Would like to use X.500 as the central repository of all communications information, e.g. telephones, video conferencing, etc..