Network Working Group P. Barker Request for Comments: 1431 University College London February 1993
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
This RFC is being distributed to members of the Internet community in order to solicit their reactions to the proposals contained in it. While the issues discussed may not be directly relevant to the research problems of the Internet, they may be interesting to a number of researchers and implementers.
This document defines a set of criteria by which a DUA
implementation, or more precisely a Directory user interface, may be
judged. Particular issues covered include terminal requirements;
style of interface; target user; default object classes and attribute
types; use of DAP; error handling. The focus of the note is on
"white pages" DUAs: this is a reflection of the current information
base. Nevertheless much of the document will be applicable to DUAs
developed for other types of Directory usage.
Please send comments to the author or to the discussion group <osi- ds@CS.UCL.AC.UK>.
1. Overview
2. General Information
3. Conformance to OSI Standards
3.1 Directory protocols
3.2 Protocol stacks
3.3 Schema
3.4 DIT structure
4. Conformance to Research Community Standards
5. The General Style of the DUA
6. Schema
6.1 Object Classes and Attribute Types
6.2 DIT structure
7. Entering queries
8. Strategy for locating entries
9. Displaying results
10. Association Handling
11. Suitability for management
12. Query Resolution
13. International Languages
14. User Friendliness
15. Operational Use
16. Security Considerations
17. Author's Address
The purpose of this document is to define some metrics by which DUA products can be measured. It should be first be noted that the use of the term "DUA" is rather misleading. There is an assumption here that the DUA is implemented correctly and is able to "talk" valid X.500 protocol: this is a sine qua non. Instead, this document seeks to draw out the characteristics of Directory user interfaces. However, the term DUA is persisted with as it is used by most people when referring to Directory user interfaces. The format of these DUA metrics is essentially a questionnaire which extracts a detailed description of a user interface. DUAs come in very different forms. Many make use of windowing environments, offering a "high-tech" view of the Directory, while others are designed to work in a terminal environment. Some interfaces offer extensive control over the Directory, and thus may be well-suited to Directory managers, while others are aimed more at the novice user. Some interfaces are configurable to allow searches for any attribute in any part of the DIT, while others lack this generality but are focussed on handling the most typical queries well. In many aspects, it is almost impossible to say that one DUA is better than other from looking at the responses to question in this document. A flexible management tool will be better for management than a DUA aimed at servicing simple look-ups, and vice-versa. Furthermore, in other areas, there are several radically different approaches to a problem, but it is not as yet clear whether one approach is better than another. One example of this is the extent to which a DUA provides an abstraction of the underlying DIT hierarchy, either emphasising the world as a tree or trying to conceal this from the user.
However, other aspects, such as whether the DUA can actually find the entries required, and if so, how quickly, can be directly measured in some way. Throughout this document, some of the questions posed are annotated with a square-bracketed points score and an explanation as to how the points should be allocated. For example, a question might be appended with "[2 if yes]", indicating score 2 points for an affirmative answer to that question. These points scores should be
collated in Table 1 at the end of the document, and this table constitutes a measure of the DUA. The metrics are on a section by section basis, which should help the reader who is seeking, for example, a DUA with good management capabilities which runs on a wide variety of platforms, to focus on the critical aspects of a DUA for the particular requirement.
This section contains general information about the implementation under discussion.
2. Version number of the DUA described in this document
3. Are further versions planned? [3 if yes]
4. Name and address of supplier or person to contact
(a) User interface part [1 per platform, up to a maximum of 4]
ii. O/S (state version if critical)
D. MS-Windows
E. Macintosh
F. Other)
(b) DUA server part (or n/a) ....................................
ii. O/S (state version if critical)
iii. How does the user interface communicate with the DUA server?
B. DIXIE protocol, as described in RFC1249
(c) Name any other software required to run the DUA which is not supplied with the operating system or with the DUA software itself. Examples might include X.500 DAP libraries, or communications software .....................................
For the next two questions, [2 per stack supported for up to 4 stacks]
(a) TP.x over CONS (state transport class) ......................
(b) TP.4 over CLNS ..............................................
(a) TP.x over RFC1006 over TCP/IP (state transport class) .......
(b) TP.x over X.25(1980) (state transport class) ................
(c) State any other options supported. .........................
The COSINE and Internet Directory Pilots have agreed a set of extensions to the standard, which make for a more cohesive pilot. This section is about conformance to these extensions.
(a) The ordinary user, who has no understanding of X.500, the hierarchical DIT, the state of advancement of the pilot, etc. [10] ........................................................
(b) A secretary who wants to do telephone or room number look-ups within their department or organisation [8] .................
(c) A computer-literate user, who habitually uses a wide-range of
network services [6] ........................................
(d) An organisation's (or department's) data manager [4] ........
(e) A Directory system manager [2] ..............................
(a) Scrolling, line-mode interface ..............................
(b) Full screen, "vt100" style interface ......................
(c) X-Windows ...................................................
(d) MS-Windows ..................................................
(e) Macintosh ...................................................
(f) Other .......................................................
Some DUAs are tightly focussed on answering particular queries: for example, white pages look-ups for information about people. Others offer more general capabilities. Please answer this question accordingly.
(a) The target object classes ...................................
(b) The default attribute types .................................
(c) Other attribute types which may be configured. This might be
answered as, for example, "all barring photo and audio", or
as a list of supported attribute types ......................
(a) State any object classes in X.521 which cannot be searched for
(b) State any object classes in RFC1274 which cannot be searched
for..........................................................
(c) State any attributes in X.521 which cannot be displayed......
(d) State any attributes in RFC1274 which cannot be displayed....
(a) Rigid .......................................................
(b) Rigid, but several hierarchies supported ....................
(c) Default hierarchy offered, but many hierarchies are supported
(d) Default hierarchy offered, but DUA fully flexible ...........
(e) No default hierarchy, DUA fully flexible ....................
26. If a default hierarchy is offered, please describe it
The term "querying" is used here as a generic term for finding an entry, whether it be as a simple look-up, or the prelude to a modification operation.
(a) Form filling (user responds to a set of prompts) ............
i. Query specified first, then resolved
ii. Query entry and resolution mixed ........................
iii. Both modes possible .....................................
(b) Queries entered as "user-friendly names" ..................
(c) Querying is by "navigating" around the DIT, the user searching and selecting .....................................
(d) Other (please describe) .....................................
A number of strategies are employed by DUAs to find the entry the user is looking for. These have implications for user-friendliness and performance. For example, an interface which makes extensive use of search operations may be excellent at finding entries, but at the cost of being intolerably slow.
(a) The DUA always uses search operations to find entries .......
(b) The DUA offers users a list of entries, and invites the user to select from the list .....................................
(c) The DUA only tries read operations (i.e., the DN must be exactly right) ..............................................
(d) The DUA tries read operations first, then searches for something similar if no entry can be found ..................
(e) The DUA tries read operations first, then offers a list of possible entries if no entry can be found ...................
(f) User explicitly controls the X.500 operation which is invoked
(g) Other. Please describe......................................
31. Does the DUA follow aliases?
If so, does it do so:
(a) Always? ....................................................
(b) Optionally? ................................................
(a) Ignore them? ...............................................
(b) Tell user, but don't display? ..............................
(c) Display hex BER encoded value? .............................
(d) Display in some other format? ..............................
This section is concerned with how a DUA handles its association with the Directory.
(a) In a system-wide tailor file ................................
(b) In a per user tailor file ...................................
(c) As a run-time command line argument .........................
(d) Other. Please describe .....................................
43. Does the DUA handle referrals automatically? [2 if yes]
If not: does the DUA handle referrals at all? [1 if yes] ......
(a) Does the DUA bind asynchronously? [2 if yes]................
(b) Are the operations handled asynchronously? .................
If so, is this true for:
ii. Some operations? [1 if yes] ............................
(a) What size limit is used? ...................................
(b) What time limit is used? ...................................
(c) Are these limits overridable? ..............................
This section is intended to establish the range of operations supported by the DUA and, in particular, whether it is suitable for management tasks.
(a) Knowledge [1]................................................
(b) Replication information [1] .................................
(c) Other .......................................................
(a) Attribute management [2 for all below, 1 for some]
ii. Modification ............................................
iii. Deletion ................................................
(b) Entry management [2 for all below, 1 for some]
ii. Modification ............................................
iii. Deletion ................................................
iv. Renaming ................................................
This section discusses the process of query resolution. While two DUAs may both be able to resolve a query using the same information, one may do so much more quickly than the other. Some DUAs may be more "economic" in their use of DAP operations to achieve the same results. Some DUAs may find the correct results even when the users' input corresponds rather weakly to Directory names. Three aspects of query resolution are measured:
The following set of queries might all conceivably be resolved such that the author's Directory entry be found. The queries are split into 2 groups: the first group SHOULD pose no difficulties for a reasonable DUA; the second group are more problematic. In each case, award [2] marks if the query found the author's entry successfully. The expensiveness of each query should be measured using the following formula, which introduces the notion of SearchStones! The SearchStone rating is calculated by adding together the total operations used in attempting to resolve a query, weighted thus:
Note: The single level searches have been separated into two
categories in acknowledgement that certain types of search are
much more likely to span multiple DSAs than others. The
weightings are the same for the moment because of the
pervasiveness of the Quipu implementation, which replicates all
sibling entries in a single DSA, whatever the level in the DIT.
The notion of SearchStones merits some further explanation and the statement of some caveats.
The idea is to give some broad brush view of the work being undertaken by a DUA to retrieve an entry. There will be some correspondence between a low SearchStone rating and a DUA responding quickly, and vice-versa, although this correlation is not consistent, for reasons given below. It would be desirable to be able to have some timing information for the resolution of queries, but such results would only be meaningful if the tests were for target entries widely distributed throughout the DIT. Maybe this is something for the future? In the meantime it is worth noting some of the factors which militate against simple minded interpretation of the SearchStones.
While acknowledging the difficulty of the exercise, there are counter arguments:
One possible way forward would be to refine the test queries such that they better represented the diversity of the DIT. However, as a first step, the tests are restricted to queries which could reasonably be constructed as searches for the author's entry. The author's entry is held in part of the DIT which is representative of much of the current DIT. It is suggested that in order to normalise the tests as much as possible, that testing be performed by connecting to the target DSA directly. The DSA's name is "cn=Vicuna, c=GB", and the addresses of the DSA may be found in the presentation address attribute for that entry. Note that the SearchStone rating should be shown even for queries which cannot be resolved.
First, the straightforward queries:
More difficult queries:
Other general questions:
If so, does it do it by:
(a) A single query under the country node? .....................
(b) Multiple queries under all organisation nodes? .............
63. Does the DUA offer multi-lingual support. If so:
(a) State which languages are already supported [1 per language up
to a maximum of 3] ..........................................
65. Is run-time help available? [2 if yes]
If so:
(a) Is context-sensitive help available? [1 if yes] ............
(b) How many screens/windows? ..................................
(c) How many bytes of help information? [2 if more than 5 Kbytes of text, 1 if more than 3 Kbytes] ...........................
The DUA exists. But is there any evidence to suggest that it is a usable tool?
(a) Is this DUA in use anywhere in the COSINE/Internet Pilot? ..
(b) Is this DUA in use in any other major pilot? ...............
(c) Is this DUA in use anywhere else operationally? ............
__________________________________________________________
|_____Section_____|_____Points____|______________________| |No._|Description_|Maximum_|Scored|______________________| | | | | | | |__2_|Gen_Info____|__10____|...___|__________n/a_________| | | | | | | |__3_|Conf_to_OSI_|__15____|...___|__________n/a_________| | |Conf to Res | | | | |__4_|Comm_stds___|__10____|...___|__________n/a_________| | | | | | | |__5_|Gen_Style___|__10____|_...__|__________n/a_________| | | | | | | |__9_|Disp_Res____|__10____|_...__|__________n/a_________| | | | | | | |_10_|Assoc_hand._|__15____|_...__|__________n/a_________| | | | | | | |_11_|Man_cap_____|__10____|_...__|__________n/a_________| | 12 |Query res | | |Search |No. of other | | | | | |Stones |entries found | |____|Q._50_______|__2_____|_...__|_...___|:_...._....___| | | | | | | | |____|Q._51_______|__2_____|_...__|_...___|:_...._....___| | | | | | | | |____|Q._52_______|__2_____|_...__|_...___|:_...._....___| | | | | | | | |____|Q._53_______|__2_____|_...__|_...___|:_...._....___| | | | | | | | |____|Q._54_______|__2_____|_...__|_...___|:_...._....___|
__________________________________________________________
|_____Section_____|_____Points____|______________________| |No._|Description_|Maximum_|Scored|______________________| | | | | | | | |____|Q._55_______|__2_____|_...__|_...___|:_...._....___| | | | | | | | |____|Q._56_______|__2_____|_...__|_...___|:_...._....___| | | | | | | | |____|Q._57_______|__2_____|_...__|_...___|:_...._....___| | | | | | | | |____|Q._58_______|__2_____|_...__|_...___|:_...._....___| | | | | | | | |____|Q._59_______|__2_____|_...__|_...___|:_...._....___| | | | | | | | |____|Q._60_______|__2_____|_...__|_...___|:_...._....___| | | | | | | |_13_|Int_Lang____|__5_____|_...__|__________n/a_________| | 14 |User-fr | | | | | | | | | | | |Query DUA | 10 | .... | n/a | | | | | | | |____|Modify_DUA__|__15____|_...__|__________n/a_________| | | | | | | |_15_|Op_use______|__5_____|_...__|__________n/a_________|
Table 1: DUA Metrics
Security issues are not discussed in this memo.
Paul Barker
Department of Computer Science
University College London
Gower Street
London
WC1E 6BT
United Kingdom
Phone: +44 71 380 7366
Fax: +44 71 387 1397 Email: P.Barker@cs.ucl.ac.uk