5i' SECTION 2 DIRECTORY SERVICES Recommendation F.500 INTERNATIONAL PUBLIC DIRECTORY SERVICES Given the rapid multiplication and expansion of CCITT-defined telecommunication services, there is a growing need for subscribers to these telecommunication services to be able to communicate with each other. In order to facilitate such intercommunication for the subscribers of the various services, public directory services will be required. The CCITT, considering (a) that the CCITT-defined telecommunication services, includ- ing Telegraphic, telematic and telephone services, have directory requirements; (b) that such requirements are being implemented as on-line electronic directories (in addition to traditional hard-copy ver- sions); (c) that national initiatives are being taken to develop elec- tronic integrated directories or service specific directories; (d) that the system definition is being undertaken by the CCITT in the field of electronic directories in the X.500-series of Recommendations, unanimously declares that the specifications of this Recommendation should be applied to the provision of public directory services. CONTENTS 1 Introduction 2 Purpose and scope 3 Organizational provisions 4 Public directory services 4.1 Service requirements 4.2 Service features and optional user facilities 4.3 Further features and facilities 4.4 Service controls 5 Names as the key to directory searches 5.1 General 5.2 Entries 5.3 Distinguished names 5.4 Classification of requests 5.5 Naming of entries 5.6 Qualification of attribute types 6 Character repertoire and languages 6.1 Character repertoire 6.2 Language of requests to the directory and responses from the directory. 7 Display of a response 8 Operational issues 8.1 Management 8.2 Authentication 8.3 Access control 8.4 Operational actions 8.5 Maintenance of the directory information 8.6 Error handling 8.7 Operator assistance 9 Quality of service aspects 9.1 Availability 9.2 Security of directory information 9.3 Successful directory requests 9.4 Access 9.5 Response time 10 References Annex A - Abbrevations Annex B - Service error messages Annex C - Selected object classes Annex D - Selected attribute types Annex E - MHS selected object classes Annex F - MHS selected attribute types Annex G - User visibility of the search operation Annex H - Glossary of terms 1 Introduction International public directory services will enable sub- scribers to determine rapidly and easily what services are avail- able and how to access and address their correspondents. Public directories may also be used internally by the various telecommunication services for the proper routing of calls or mes- sages. However, this application of directory systems is not covered by this Recommendation. Service specific directories may be implemented as part of a global directory service. Consistent with the need to make direc- tory information as widely available as possible, it is anticipated that Administrations will aim to provide global electronic direc- tory services. In order to provide international public directory services, Administrations should mutually cooperate in handling inquiries for information across national boundaries. Public directory services should solve the primary problem of name to address association, e.g. obtaining a company's telex number by querying the directory with the name of the company. The reverse question, i.e., obtaining the name and other information from the address, may also be applicable in certain services and its provision is at the option of an Administration. Public directory services should include directory information concerning the provision of services, service descriptions, opera- tional instructions, tariff conditions, etc. Public directory services should make provision for accessing information without knowing the name of the object sought, e.g., designating categories of goods, business areas or services. Advertising is included in the scope of public directory ser- vices, but is left to national implementations. Public directory services can be considered as supplementary to the services for which they provide information or by which they are accessed. Private directory services which are compliant with the public directory services defined in CCITT Recommendations may be permit- ted to intercommunicate with public directory services under national regulations. 2 Purpose and scope This Recommendation provides for the general framework for the provision of international public directory services. It defines the requirements for and the service features associated with the provision of public directory services. It specifies naming aspects, describes operational issues to be taken into account in providing the public directory services as well as quality of ser- vice aspects. 3 Organizational provisions Provision of a public directory service will be done in accor- dance with the organizational model described in Recommendation X.501. An Administration Directory Management Domain (ADDMD) is responsible for the application of the basic service features and the optional user facilities provided in that domain. Directory management domains shall intercommunicate with each other as far as the provision of the public directory services requires it. The protocol to be used for interworking as well as the directory's overall concept and behavior, is described in the X.500 series of Recommendations. Private Directory Management Domains (PRDMDs) may exist and intercommunicate with ADDMDs, following national regulations. A Directory Management Domain (DMD) consists of one or more Directory System Agents (DSAs) and zero or more Directory User Agents (DUAs). Each directory management domain may act as the naming author- ity for that domain. Names need to be unambiguous. The intercommunication between PRDMDs is outside | of the scope of this Recommendation. 4 Public directory services 4.1 Service requirements The fundamental ability of a public directory service is to provide a means by which subscribers or users of telecommunication services may, in a user-friendly manner, and from information they would normally possess, obtain information about a desired reci- pient, such as addresses or communication capabilities. This public directory service is provided in an on-line and interactive manner. It should be made available for subscribers or users at the discretion of the Administration offering the service. Each Administration is responsible for the access methods used. The characteristics of the access methods between terminals and the public directory service are a national matter. However, the directory service offered is independent of the access method, the terminal used and the location of the user. Public directories of Administrations should intercommunicate (or refer to each other) to fulfill requests made by customers when the directory serving the customer does not have available the information requested. 4.1.1 Basic service requirements The following basic service requirements are fulfilled by the public directory services: - to provide subscribers with information, e.g., a telex number, needed for establishing communication with other sub- scribers or users of telecommunication services; - to provide subscribers with information, e.g., service instructions, needed to use the telecommunication services and the directory itself; - to assist subscribers in the formulation of queries to narrow the scope of the operation; - to allow for flexibility in the formulation of a request, e.g., names should not artificially remove natural ambi- guities; names should admit natural abbreviations and commonly used variations in spelling. 4.1.2 Non-basic service requirements The following non-basic service requirements are fulfilled by the user facilities of the public directory services. - to provide subscribers with other information, e.g., advertising; - to provide subscribers with " yellow page " information, e.g., categories of goods, business areas or services; - to provide an interted directory for specific services, e.g., for telex and teletex; - to provide " wildcards " capability to ease, as far as possible, the input of the requests to the directory; - to provide means for the verification of creden- tials, under conditions specified by the provider of the directory service; - to provide possibilities for the search of dis- tribution lists; - to provide means for the phonetic matches. 4.2 Service features and optional user facilities The service features and the optional user facilities of a public directory service will be provided in accordance with the X.500-series of Recommendations. The terms used in the context of service features and optional user facilities discussed below are explained in Annex H. 4.2.1 Basic service features Basic service features are inherent in directory services and are always available for use in directory service. They are pro- vided by all service providers offering international public direc- tory services or by private directories intercommunicating with public directory services. The basic features are: - read operation ; - search operation Other basic features are for further study. 4.2.2 Optional user facilities Optional user facilities may be selected by the user or sub- scriber at the time the service is being used. Each optional user facility visible to the user is classified as either essential or additional. Essential (E) optional user facilities are to be made available internationally by Administrations. Additional (A) optional user facilities may be made available by Administrations for national use and for international use on the basis of bila- teral agreement. The major terms used in this Recommendation are contained in Annex H. The classification of optional user facilities is shown in Table 1/F.500. H.T. [T1.500] TABLE 1/F.500 Classification of optional user facilities ________________________________________________ Classification ________________________________________________ Abandon E (see Note 1) Add A Additional service controls A Compare A Distribution lists A List A Management of access control A (see Note 2) Modify A Remove A Security capabilities A Time limit service control E ________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - This abandon operation is not guaranteed outside of the local scope, i.e., the DSA or DMD to which the original request was made. Note 2 - The full functionality is presently not provided in the present system specification of the X.500 series of Recommendations (see X.501, S 3 and Annex F). This is for further study and referred to as being presently a national matter. Access control functions are for further study. Table 1/F.500 [T1.500], p. Other optional user facilities are for further study. 4.3 Further features and facilities Some of the following items are not yet specified as elements of service in the X.500 series of Recommendations and will be stu- died further. Some others will need further study under service aspects. The following list may provisionally be considered as gui- dance for service providers to be taken into account for the provi- sion of public directory services under national responsibility. The items may become basic features or optional user facilities in the future or/and will be included with descriptive text in future Recommendations. - Provision of inverted directories for telex and teletex services. - Provision of additional information with or after the result of a query. - Provision of query cost information. - Provision of information about services, service instructions, tariffs, etc., in standardized formats taking into account additional attributes. - Provision of additional service controls. - Provision of full functionality of access control mechanisms. - The ability of the user to indicate the desire not to receive partial results when service control maximum parame- ters are exceeded. - Provision of the return of multiple responses in groups of n (n = any number). - Provision of administrative procedures for authentication. - Provision of standardized error service messages. - Provision of shadowing (controlled replication) of directory information. - Provision of geographical extension. - Consequences of distributed directory services. 4.4 Service controls Because of its generality and scope, the direcory service can fulfill subscribers' requests that might require consumption of resources beyond a level desired by the subscriber or by the ser- vice provider. Service controls help to prevent such situations by imposing limits on the resources that may be consumed in fulfilling a request for service. Service controls not impacting the provision of international directory services are a local matter. The follow- ing service controls are provided by the system application (see Recommendation X.511): 4.4.1 Prefer chaining This service control indicates a choice for chaining over referral and multicasting. For the international intercommunication of public directories, chaining is the preferred choice. The setting of this service control is for the service pro- vider who may allow the user to invoke it. 4.4.2 Chaining prohibited The scope of a search will then be limited to the local por- tion of the Directory Information Base (DIB) by prohibiting chain- ing. The setting of this service control is for the service pro- vider who may allow the user to invoke it. 4.4.3 Local scope The scope of the operation will be limited to the local por- tion of the DIB. The determination of local is restricted to a sin- gle DSA or DMD in accordance with an Administration's policy. For the international intercommunication of public direc- tories, generally no limitation to local scope is assumed. Public directories will aim to open their scope as much as possible. The setting of this service control is for the service provider who may allow the user to invoke it. 4.4.4 Do not use copy This service prevents a DMD from returning copied information. The setting of this service control is for the service pro- vider who may allow the user to invoke it. 4.4.5 Do not dereference alias This service control allows reference to an alias entry itself rather than to the aliased entry. The setting of this service control is for the service pro- vider. 4.4.6 Priority: low, medium, high The setting of this service control is for the service pro- vider. The usefulness of this service control is for further study. 4.4.7 Time limit The scope of this service control is to limit an operation in terms of total elapsed time such that if the limit is exceeded, then the operation will be terminated, and for search and list operations partial results should be returned, with the indication that results are incomplete due to the time limit. This service control shall be honoured by any DMD involved. The setting of this service control is for the service pro- vider who may allow the user to invoke it. Note - This service control is an essential optional user facility. All service controls other than the time limit are a local matter and when implemented, need not be made available by the service provider to the user. 4.4.8 Size limit (applicable to search or list operations) If the list size specified is exceeded any results equal in number to the size limit should be returned, with the indication that the results are incomplete due to the size limit. The setting is for the service provider who may allow the user to invoke it. 4.4.9 Scope of referrals Indicates the scope to which a referral (or advice), if gen- erated, is to be restricted to, i.e., limits the range of alternate access points at which the requestor (DUA or DSA) may alternately use to satisfy the request. The limitation can be restricted to a country or DMD. The setting of this service control is for the service pro- vider who may allow the user to invoke it. Note - Combination of some service controls may affect the quality of the results, e.g., combination of priority, time limit and size limit may conflict, or chaining cannot be both preferred and prohibited simultaneously. If no service controls are supplied with an operation, the following is assumed: referrals and/or chained operations may be used; no limit on the scope of the opera- tion; locally held copies of information are permitted; no prefer- ence of priority for operation processing; there is no time or size constraint; referrals, if generated, are not restricted to a DMD or country; and aliases are dereferenced. 5 Names as the key to directory searches 5.1 General A name within the directory service is a label which is con- structed to identify a particular object, that is, which singles out an object from the set of all objects. A name should not be ambiguous, that is, should not denote more than one object. How- ever, there may be more than one name for an object. Thus, it is possible to call an object by the name International Widget Makers or IWM. In either case, one and only one object is identified. A more abstract definition of "name" can be found in Annex H. 5.2 Entries The directory service will provide information about entries. The complete set of such information is called the Directory Infor- mation Base (DIB). The information about entries is composed of attributes; attributes, in turn, are composed of an attribute type (one type of attribute could be a telex number) and one or more attribute values. (The actual telex number would be a value.) The entries are arranged in a tree, called the Directory Information Tree (DIT). This is graphically illustrated in Figure 1/F.500. How- ever, this does not preclude other directory information struc- tures. Thus, an entry may be viewed as an entity which is named through one or a series of attributes. A company may be suffi- ciently named simply through the use of its actual legal name e.g., the PADRAIC STEEL CO. A plumber in Secausus, N.J. can be named through the use of his common name, his postal address and his business category "plumber". A human person may be named through the use of his or her common name and telephone number. 5.3 Distinguished names It should be noted that within the directory system recommen- dations, the term "distinguished name" is used. This is the combi- nation of the minimum attribute value assertions (AVAs) needed to denote an entry uniquely. This minimum will be established in accordance with the requirements of the naming authority and/or the directory management domain, and the preference of the owner of tne entry named. Use of the distinguished name may be of assistance in performing the most effective search of the DIB. However, it should be recognized that in some instances, distinguished names may not be user friendly and may contain information, which, in fact, is the object of the directory search, i.e., a person's postal address. Figure 1/F.500, p.2 5.4 Classification of requests To satisfy the most common needs of directory users which are presently met by so-called " white pages " or " yellow pages " (classified directories) or organization directories, three clas- sifications of requests to the directory service are provided. 5.4.1 Common name requests (type 1) Information returned under this type of request includes information about one or more of the following entries. (Selected object classes can be found in Recommendation X.521; they are listed in Annex C.) a) A person Example: Bernadette L. Casey b) A residential person Example: Cornelius Fecit 2 Humbug Road Fun City, New York 11666 USA c) An application entity Example: Some logical name, usually a sequence of alpha and/or numeric characters identifying an application process; consequently not necessarily user friendly. d) A communication device Example: the XYZ 9.6 modem (however, this information is normally associated with an organization and is thus generally of greatest utility to organizations). e) An alias Example: Neil Fecit [an alias for the residential person in b)] f ) An organizational role Example: Director of regulatory affairs g) A group of names Example: Members of special rapporteur's group Ques- tion 14/1. 5.4.2 Business category requests (type 2) Information returned under this type of request includes information about one or more of the following entries. (Selected object classes can be found in Recommendation X.521; they are listed in Annex C.) a) A person Example: John Smith b) A residential person Example: John Smith, with the rest of the postal address c) An organization Example: The Padraic Steel Company d) An organizational unit Example: Regulatory Affairs Department e) A group of names Example: The plumbers in Secausus 5.4.3 Organization requests (type 3) Information returned under this type of request includes information about one or more of the following entries. (Selected object classes can be found in Recommendation X.521; they are listed in Annex C.) a) An organization Example: The Padraic Steel Company b) An organizational unit Example: Regulatory Affairs Dept. c) An organizational person Example: John Jones, Padraic Steel Company d) An organization role Example: Chief Operating Office e) A group of names Example: The President's Staff f ) An application entity Example: as above in S 5.4.1 c) g) A device Example: An XYZ 9.6 modem h) An organizational unit alias Example: the "bean counters" which is an alias for the "Controller's Dept." i) An organizational name alias Example: GMC for "Good Modern Cooks Inc." 5.4.4 Use of attributes Attribute types that are recommended to be included, whenever they exist (subject to the permission of the owner) in each entry of each group, either for query or retrieval, are listed in Table 2/F.500 (see also Annex D). H.T. [T2.500] TABLE 2/F.500 Use of attributes for each type of request _____________________________________________________________________________________________________ Attribute type Abbreviation for Type 1 for Type 2 for Type 3 _____________________________________________________________________________________________________ Business category BCTG - M R Common name COM M Q Q Country name CTN M M M Description (free text) DES R R R { Destination indicator (public telegram) } DI - - - Facsimile telephone number FAX - Q Q ISDN address ISDN - Q Q Knowledge information KI - - - Locality name LOC M Q Q Member MEM R R R Object class CLASS Q Q Q { O/R address (MHS) (see Note 1) } O/R R R Q Organization name ORG - - M Organizational unit name OUN - - Q Owner OWN - - - Physical delivery office name PDO Q Q Q Post office box POB Q Q Q Postal address PADD Q Q Q Postal code (see Note 2) PCOD Q Q Q Preferred delivery method DLM R R R Presentation address PRADD R - R { Registred address (public telegram) } RADD - R R Role occupant RO R - R Search guide SG R R R See also SEE R R R Serial number SN - - - State or province name STN M (see Note 3) Q Q Street address SADD Q Q Q Supported application context SAC Q Q Q Surname SUR Q Q Q Telephone number TEL Q Q Q Teletex terminal identifier TTX R Q Q Telex answerback (see Note 4) A/B R R R Telex number TLX R Q Q Title TIT - - Q User certificate UC R R R User password UP R R R { Videotex user number (see Note 4) } VTX Q Q Q X.121 address X.121 - Q Q R _____________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - This attribute type is defined in the X.400 series of Recommendations. Note 2 - The postal address will normally contain the postal code. Requirements may exist to justify the postal code as being a separate attribute type. Specific conditions are applied to a postal address for Physical Delivery (see Recommendation F.401). Note 3 - Depending on the value of the attribute "CTN". Note 4 - This attribute type has not yet been defined in Recommendation X.520. __________________________________________________________________________________________________________________________ M Mandatory to reach | an object of this type. Q { May be used to reach an object of this type (within a distinguished name or as a search filter), but may also be part o the directory response. Additional attribute types may be used for selection criteria within national implementations. } R { Normally part of the directory response with regard to the request of the user. } - { This attribute type may either be part of a local sub-object class or used nationally. } __________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 2/F.500 [T2.500], p. Some terms used in Table 2/F.500 are explained in Annex H. Definitions of other terms can be found in the X.500 series of Recommendations. 5.5 Naming of entries To reach an entry, a user has to provide some information, a part of which is essential to the performance of the request (e.g., the provision of attributes CTN, ORG, CLASS, for an organizational object), as described in S 5.2. Depending on the knowledge the user has about the naming structure of the part of the directory information tree (DIT) to which the entry of the intended object belongs, the request infor- mation provided by this user to reach the intended entry is either the distinguished name of the entry (in which case the response is unique), or the value of some relevant search attributes (already known by the user) arranged in a logical pattern to act as a filter to reduce as far as possible the number of the directory responses. Since distinguished names have to be unambiguous, it is not expected that they will always be user-friendly. For instance, a name of a residential person may include the telephone number and thus be rather difficult to predict, especially if the telephone number is the information requested from the directory. It is recognized that the distinguished name (DN) of an object may not be commonly known, in which case the DN may be acquired by using a list operation and in some instances a search operation. To perform efficiently the search or list operation, it is recommended that one narrows as far as possible the scope of the search, either by giving a base object (from which the search starts in the DIT) near enough to the intended entry (in terms of DIT levels), or by obtaining and using the appropriate filtering. It should be possible to obtain from the directory which of the attributes (qualified with "Q" in Table 2/F.500) may be used as part of the search filter for a given object class starting from a given base object. However, it is recognized that the use of this feature across domain boundaries is subject to national restric- tions and bilateral agreements. It is expected in most cases that a directory management domain will be able to provide from previous experience the useful search criteria of subordinate levels, whether or not they effi- ciently manage those levels, without exploring the DIT further for each request. Knowledge of the search criteria may also be acquired by DUAs from the directory by automatic means, e.g., by reading the "search guide attribute" if available. It is up to the Directory Management Domain (DMD) managing a given entry to select from the attribute types specified in S 5.4 for use as search criteria. The use of wildcards to replace the value or part of the value of unknown recommended search criteria should be made possible. Phonetic or orthographic extensions, when requested, may be locally applied to the provided values for query operations. How- ever, their actual provision depends on the capabilities of the directory system. The fall-back mode is phonetic or orthographic extensions not supported. 5.6 Qualifications of attribute types Some criteria of the selected attribute types require qualifi- cation. "Mandatory" in Table 3/F.500 indicates that, if that attribute type exists in an entry of the directory, it shall be part of any response provided, when asked for by the user, and that no combination of access controls may be kept on attributes which would preclude provision of a meaningful directory service, subject to the owner's approval. The "required length" of an attribute type in Table 3/F.500 designates the minimum number of character positions to be made available for the attribute type to be displayed on the terminal of a user, and can therefore assist Administrations in defining their attribute values with the assurance that the attribute value will not be truncated. (The X.500-series Recommendations have system qualifications for the maximum length of attribute types.) The system specification does not provide multiple values for country name and preferred delivery method. All others may be recurring. For example, an organization may be "Padraic Steel" and "Padraic Steel Company". Only one value needs to be displayed to the user. Table 3/F.500 contains a list of the user-visible selected attribute types to be used in the directory service. The figures shown may require revision in the light of experience. H.T. [T3.500] TABLE 3/F.500 Qualifications of attribute types _______________________________________________________________________ Attribute type Mandatory Required length _______________________________________________________________________ Business category Yes 128 Common name Yes 64 Country name (see Note 1) Yes 30 Description Yes 1024 { Destination indicator (public telegram) } Yes 4 Facsimile telephone number No 150 ISDN addresse No 16 Knowledge-information No - Locality name Yes 64 Member No - Object class No - O/R address MHS (see Note 2) Yes - Organization name Yes 64 Organizational unit name Yes 64 Owner No - Physical delivery office name No 64 Post office box No 40 Postal address No 180 Postal code (see Note 2) No 20 { Preferred delivery method (see Note 3) } Yes 15 Presentation address No - { Registered address (public telegram) } Yes 60 Role occupant No - Search/Guide Yes - See also Yes - Serial number No 64 State or province Yes 64 Street address No 64 Supported application context No - Surname No 64 Telephone number No 16 Teletex terminal identifier No 24 Telex answerback (see Note 2) No 21 Telex number (see Note 3) No 36 Title No 64 User password No - User certificate No - { Videotex user number (see Note 2) } No 17 X.121 address No 15 _______________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note 1 - The system specification provides only a 2-character length, to correspond to the ISO 3166 value. Note 2 - The postal address will normally contain the postal code. Requirements may exist to justify the postal code as being a separate attribute type. Specific conditions are applied to a postal address for Physical Delivery (see Recommendation F.401). Note 3 - The system specification provides a shorter field. Note 4 - For some attribute types, values are stored in encoded/compressed format and will need to be displayed in a non-encoded format or human readable format. Note 5 - See also Recommendation X.520, Annex C. Table 3/F.500 [T3.500], p. 6 Character repertoire and languages 6.1 Character repertoire Directory information will be entered and stored locally using a character repertoire suitable to the country where the directory is located. More than one character repertoire may be needed to cover different languages or to provide for access from different types of communication terminals. However, in order to provide international public service, the character repertoire to be used internationally should be limited to CCITT standardized sets, i.e., the IA5 and T.61 character reper- toires. For the intercommunication between public directory services, the repertoires may be agreed to bilaterally. However, where no such agreement exists, the character reper- toire to be used shall consist only of those characters defined as "printable string" in Recommendation X.208. Furthermore, those Administrations which use character reportoires other than this repertoire shall provide suitable conversion of the information into this character repertoire for directory requests from Adminis- trations with which no bilateral agreement has been reached. Subscribers have to be instructed on the use of the appropri- ate character repertoires. 6.2 Language of requests to the directory and responses from the directory Subject to the conditions in S 6.1, the results of requests to the directory should normally be provided in the language or languages of the DMD providing the information. However, the information is presented to the requestor is a national matter. 7 Display of a response Attribute types and values will be displayed to the user, when required, by converting the values in accordance with Recommendation X.408. Though it is logical enough that the right response always be sought, in some cases where no such answer can be provided, and on explicit request of the requestor, the directory may also provide phonetic and orthographic extensions corresponding to the intended object. For displaying directory responses, the following order is recommended: a) the right answer(s); b) the answer(s) approaching the right answer(s) using conjunctions, particles, articles, as well as extended or concatenated abbreviations; c) the phonetic and orthographic extensions (e.g. plural instead of singular denominations). It should be noted that such responses may be erroneous. Partial responses, including referrals, should be displayed to the requestor and properly identified as such. The cause for par- tial responses should also be displayed. 8 Operational issues 8.1 Management It is the responsibility of the Directory Management Domains (DMDs) to exercise the management of information within their Domains. Inter-Domain Management is for further study. 8.2 Authentication Authentication in this context means that the identity of the subscriber or user is established. In some cases, the directory service has to ensure that directory information is released only to authorized requestor(s), and in some cases it has to ensure that data is modified only by an authorized originator (e.g., by employ- ing techniques related to data origin authentication). Checking and keeping of credentials, when performed, are at the discretion of the DMD, taking into account the requirements of privacy of the owner of the information. The precise reason for credential failure will be masked from the user. The user will be advised that denial of the request was because an inappropriate authentication level was encountered. See also Recommendation X.509. Further study is required. 8.3 Access control Access controls are a national matter. When access control prohibits the return of the information requested, an appropriate code error code will be returned. Note - The international application of access control is for further study. 8.4 Operational actions Actions performed within a directory can be categorized as: 1) primary (subscriber/directory) action - always in direct support of a subscriber; 2) secondary action in support of a subscriber request, either serving the subscriber's DUA or an intermediary DSA. These actions are qualitatively different, and differ also in what they imply concerning the obligations of an ADDMD. Examples of such interactions can be found in Recommendation X.518. 8.4.1 Primary (subscriber/directory) action The public directory service should provide three user-visible activities of support, as follows: a) Request formation In this activity, the subscriber composes a request to the directory. The way in which these functions are performed is a national matter. b) Presentation of results In this activity, the directory service presents to the subscriber the results of a previously entered request. The format, presentation medium and other aspects of result presentation are a national matter. c) Subscriber assistance In this activity, the directory service assists the sub- scriber by providing instructions on the use of the directory. The means through which the subscriber asks for such instruction, and the manner in which an instruction is delivered, are a national matter. 8.4.2 Secondary action for subscriber support In order to provide the public directory service, DMDs shall cooperate. Such cooperation includes adherence to defined patterns of interaction, and also includes provision of requested directory information to one another, subject only to internationally agreed access controls (or bilateral arrangements). This technical cooperation among DMDs implies an equivalent level of cooperation in service terms, especially with regard to information sharing, among the DMDs. Examples of such interaction can be found in Recommendation X.518. 8.5 Maintenance of the directory information The service provider has to ensure integrity of the informa- tion contained in the directory. Shadowing (controlled replication) of information in other DMDs is permitted by bilateral agreement. The international application is for further study. Creation and modification of directory information by the sub- scribers may be permitted by the DMDs concerned. 8.6 Error handling Error conditions will be returned as a value of an error code for all standardized operations. The meaning will be displayed according to national implementations as service error messages to the user. See Annex B/F.500 for guidance. 8.7 Operator assistance For further study. 9 Quality of service aspects 9.1 Availability In principle, a public directory service should be available to subscribers 24 hours a day, seven days a week. 9.2 Security of directory information Information in public directories should be given the broadest dissemination. However, subscribers or users about whom information is available in a directory should be able to require the entity charged with the management of the directory to limit access to such information to ensure their own privacy. 9.3 Successful directory requests Normally, a successful directory request will result in a report of all the requested information, unless it is denied because of authorization restrictions. Requests to the directory which do not provide sufficient information to execute a reasonable search will normally not lead to a successful result. 9.4 Access Providers of a public directory service should ensure that an adequate number of access ports are available to accommodate sub- scribers' requests for information. In principle, this means that a requestor will receive a prompt within 15 seconds as a goal. 9.5 Response time Recognizing that responses to requests will be controlled in part by the level of ambiguity tolerated in requests and the number of DMDs which shall be traversed to retrieve the information requested, a subscriber normally should expect an initial ack- nowledgement regarding his request within 5 seconds. The scope and priority of the request may have an impact on the response time. The requestor may terminate his request at any time. A final response (successful or unsuccessful) will depend on the capabilities of the directories consulted. A response indicat- ing that no information or incomplete information is available (possibly with hints for further searches) should be given within one minute. Note - The figures for quality of service are provisional and may be revised in the future. 10 References 10.1 Recommendations of the X.500 series - Data communica- tion networks: directory X.500 The directory - Overview of concepts, models and ser- vices X.501 The directory - Models X.509 The directory - Authentication framework X.511 The directory - Abstract service definition X.518 The directory - Procedures for distributed operation X.519 The directory - Protocol specification X.520 The directory - Selected attribute types X.521 The directory - Selected object classes 10.2 Recommendations of the X.200 series - Data communica- tion networks: open systems inter connection (OSI) 10.3 Recommendations of the F.400 series - Message han- dling and directory services operations and definition of service 10.4 Recommendations of the X.400 series - Data communica- tion networks: message handling systems ANNEX A (to Recommendation F.500) Abbreviations H.T. [T4.500] ________________________________________________________________________ A { Additional Optional User Facility } ADDMD { Administration Directory Management Domain } AVA Attribute Value Assertion DIB { Directory Information Base } DIT { Directory Information Tree } DMD { Directory Management Domain } DN Distinguished Name DSA Directory Systems Agent DUA Directory User Agent E { Essential Optional User Facility } ITU { International Telecommunication Union } PRDMD { Private Directory Management Domain } RDN { Relative Distinguished Name } RPOA { Recognized Private Operating Agency } ________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau [T4.500], p.5 ANNEX B (to Recommendation F.500) Service error messages Error codes produced while performing operations in directory systems are transformed by the local DUA into service error mes- sages. The values of the error codes and the meaning are summarized in this Annex. Standardized service error messages are for further study. The presentation to the user is a local manner. See also Recommendation X.511. B.1 Attribute error This error is displayed on a per-selection criteria basis (attribute type) and includes the attribute type, attribute value and problem reason value. The problem reason values are as follows (see Table B.1/F.500). H.T. [T5.500] TABLE B-1/F.500 __________________________________________________________________________________________ Reason value Meaning __________________________________________________________________________________________ 1 { The requested information does not exist for the named entry. } 2 { The syntax of the value used for the distinguished name or the selection criteria is inappropriate. Contact support staff for assistance. } 3 { Attribute Type is not defined for this . } 4 { Inappropriate matching for the information type . } 5 { Attribute Type or Attribute Value is not within its constraints. } 6 { or already exists. } __________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table B.1/F.500 [T5.500], p. B.2 Name error This will be displayed with one of the following reason values whenever a name provided by the user is detected to have a problem (see Table B.2/F.500). H.T. [T6.500] TABLE B-2/F.500 ____________________________________________________________________________________________ Reason value Meaning ____________________________________________________________________________________________ 1 { The name supplied, , cannot be found. (Note - ALIAS names are resolved to the actual named entry.) } 2 { is an Alias that can not be properly resolved. } 3 { Part, , of the name used is underfined. } 4 { The syntax of the value used, , is inappropriate. } 5 { List operation is improperly specified. } 6 { An Alias was encountered in an operation where it is not allowed. } ____________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table B.2/F.500 [T6.500], p. B.3 Interconnect error This error will be displayed whenever the operation cannot be carried further at this time. The possible access points for con- tinuing the request are provided in the form: "Name and Access Point". B.4 Service error This will be displayed with one of the following reason values whenever the operation requested has detected a problem that affects the user service (see Table B.3/F.500). H.T. [T7.500] TABLE B-3/F.500 ______________________________________________________________________________________________ Reason value Meaning ______________________________________________________________________________________________ 1 { The directory system is busy. } 2 { The directory system is presently unavailable. } 3 { System is unable to proceed with the request. Contact support staff for assistance. } 4 { Information not found in the local system. [Optionally, the directory service provider may advise the user that the restriction to use local service information only should be removed and the request may be re-submitted to allow remote directory services to be utlized.] } 5 { Administrative limit exceeded. Contact support staff for assistance. } 6 { Unavailable critical extension. } ______________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table B.3/F.500 [T7.500], p. B.5 Update error This will be displayed with one of the following reason values whenever the the modify (Add, Change, or Delete) operation(s) requested has detected a problem (see Table B.4/F.500). H.T. [T8.500] TABLE B-4/F.500 ____________________________________________________________________________________________ Reason value Meaning ____________________________________________________________________________________________ 1 { The update violates directory naming rules. } 2 { The update violates the directory rules for that class of objects. } 3 { Update not allowed because of the object's position in the directory. } 4 { Update not allowed on an RDN when modifying an entry. } 5 { Entry already exists (relevant for add operation only). } 6 { Update denied, affects multiple directory systems. } 7 { Any update against this class of objects prohibited. } ____________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table B.4/F.500 [T8.500], p. B.6 Security error For further study. B.7 Abandon error For further study. B.8 Referral error For further study. ANNEX C (to Recommendation F.500) Selected object classes See Recommendation X.521. Object identifies are allocated to object classes. The concept makes use of the concept of subclasses (see Recommendation X.501). Selected object classes provided by the directory systems specifications depend on the scope of public directory service chosen by the service provider. It is assumed that the presently defined selected object classes will allow the provision of a use- ful directory service. - Top - Alias - Country - Locality - Organization - Organizational unit - Person - Organizational person - Organizational role - Group of names - Residential person - Application entity - Application process - DSA - Device - Strong authentication user - Certification authority Note 1 - A certain object class is used as a classificatory attribute type. Note 2 - The definition of additional selected object classes for public directory service is for further study. Note 3 - Messaging handling, in X.400-series of Recommenda- tions, defined additional object classes for MHS specific use (see Annex E). ANNEX D (to Recommendation F.500) Selected attribute types It is assumed that the presently defined selected attribute types will provide a useful directory service. The implementation of the attribute types used in the public directory service are left for the decision of the service provider. Selected attribute types provided by the directory system specification, Recommendation X.520, are: a) System attribute types - Aliased object name - Knowledge information - Object class b) Labelling attribute types - Common name - Serial number - Surname c) Geographical attribute types - Country name - Locality name - State or province name - Street address d) Organizational attribute types - Organization name - Organizational unit name - Title e) Explanatory attribute types - Business category - Description - Search guide f ) Postal attributes - Physical delivery office name - Post office box - Postal address - Postal code - Registered address g) Telecommunications addressing attribute types - Destination indicator - Facsimile telephone number - ISDN address - Registered address - Telephone number - Teletex terminal identifier - Telex number - X.121 address h) Preferences attribute types - Preferred delivery method i) OSI application attribute types - Presentation address - Supported application context j) Relational attribute types - Member - Owner - Role occupant - See also k) Security attribute types - User password - User certificate - Authority revocation list - Certificate revocation list - CA certificate Note 1 - Other attribute types may be defined for local scope or on bilateral agreement. Note 2 - The definition of additional selected attribute types for public directory services is for further study. Note 3 - Messaging handling, in X.402, defined additional attribute types for MHS specific use (see Annex F). ANNEX E (to Recommendation F.500) MHS selected object classes See Recommendation X.402 for further details. Selected object classes provided by the directory systems for MHS depend on the scope of the public directory service chosen by the service provider. It is assumed that the presently defined selected MHS object classes will allow the provision of a useful directory service that intercommunicates well with MHS as defined in X.400-series of Recommendations. MHS object classes - MHS (Generic MHS user information) - MHS organizational user - MHS distribution list - MHS message store - MHS message transfer agent - MHS user agent ANNEX F (to Recommendation F.500) MHS selected attribute types It is assumed that the presently defined attribute types defined in X.400-series of Recommendations will provide a useful directory service for message handling systems. The implementation of the attribute types used in the public directory service are left for the decision of the service provider. MHS selected attri- bute types provided by the X.400 system specification, Recommendation X.402, are: MHS attribute types - MHS deliverable content length - MHS deliverable content types - MHS deliverable encoded information types - MHS distribution list members - MHS distribution list submit permissions - MHS message store - MHS O/R addresses - MHS preferred delivery methods - MHS supported automatic actions - MHS supported content types - MHS supported optional attributes ANNEX G (to Recommendation F.500) User visibility of the search operation Some examples of filters are shown for the practical use. G.1 Possible examples ORG = Organization name OUN = Organizational unit name G.1.1 Sales units of TTT or marketing units of TNT [(ORG = "TTT"), AND, (OUN = "SALES")] OR [(ORG = "TNT") AND, (OUN ="MARKETING")] G.1.2 Marketing or sales units of TTT (ORG = "TTT"), AND, [(OUN = "MARKETING, OR OUN = "SALES")] G.1.3 All departments of TTT except Marketing [(ORG = "TTT"), AND, (OBJECT CLASS = OUN)], AND NOT, [(OUN = "MARKETING")] OR [(OUN = MARK*)] G.1.4 All organizations in a country whose telex numbers are in the range of 5030 to 5067 (OBJECT CLASS = ORG)AND, [(TLX 5067), AND, (TLX > 5030)] G.2 Practical use and effect of filters G.2.1 Task "Retrieve" in the USA, the location (state or province), the telefax number, and voice telephone number for the sales depart- ments of TTT or the marketing departments of TNT. The total elapsed time for retrieving the information should not exceed 10 minutes (600 s) and the maximum number of objects found should not exceed 20. G.2.2 Solution/action Action SEARCH Criteria: Base object: "CTN = USA". subset: "whole subtree" Filter [(TYPE = 3), AND, (ORG = "TTT", AND, OUN = "SALES") , OR, (ORG = "TNT", AND, OUN = "MARKETING")] Service controls: { time limit = 600, size limit = 20, priority = medium } Selection: { FAX, TEL, STN } Result The directory will return the requested information within the limits designated by the requestor. If the limits are exceeded, an error indicating the limit that was exceeded and arbitrary collec- tion of partial results are displayed in this example. ANNEX H (to Recommendation F.500) Glossary of terms Note - Some of the terms included are quoted from X.500-series of Recommendations and are only included to enhance understanding of system related descriptions. Some of the text pro- vided are definitions and others are of explanatory nature. A separate Blue Book named "Definitions" may be used as a further source. H.1 abandon A directory operation to terminate a request. This operation is not guaranteed outside of the local scope. Note - This directory system operation is considered to be an optional user facility in the service context. H.2 access control Method of controlling access to information held in the direc- tory either for retrieval, managing or updating purposes. H.3 ADD A directory operation to add an object entry or an alias entry to the directory information tree (DIT). Note - This directory system operation is considered to be an optional user facility in the service context. H.4 additional service controls Function of a directory system to control certain additional performance criteria. Note - These service controls are considered to belong to additional optional user facilities. H.5 administration Denotes a public telecommunications Administration or Recog- nized Private Operating Agency (RPOA). H.6 administration directory management domain (ADMD) A DMD which is managed by an Administration or RPOA. H.7 alias (entry) An entry of the class "alias" containing information used to provide an alternate name for an object. It points to the entry that actually contains the information. H.8 alias name A name for an object where at least one of whose relative dis- tinguished names (RDNs) is that of an alias entry. H.9 attribute The information of a particular type concerning an object and appearing in an entry describing that object in the directory information base (DIB). Note - See X.500-series of Recommendations for further details. H.10 attribute type That component of an attribute which indicates the nature of information given by that attribute. H.11 attribute value A particular instance of information indicated by an attribute type. H.12 attribute value assertion A proposition, which may be true, false, or undefined, con- cerning the values (or perhaps only the distinguished values) of an entry. H.13 authentication Method to establish security services by means of simple or strong authentication. There are two kinds of authentication: data origin authentication and peer entity authentication. Note - See Recommendation X.509 for more information. H.14 authentication mechanisms Authentication mechanisms are used to provide for encryption, data integrity and digital integrity. H.15 business category Attribute type which specifies the commercial activity of some common objects, e.g. people. H.16 chaining A feature used by the directory system to communicate between directory system agents (DSAs) to satisfy the users request. To achieve this multiple DSAs must be able to intercommunicate as peers. This feature may be inhibited by the user or service pro- vider through service control parameters that are supplied with the user's request. Note - A set of agreements is required between the domains (DSAs) wanting to interact based on this method. H.17 classified information In the context of the directory, directories presently known as "white pages", "yellow pages", etc. H.18 common name In the context of directory systems: An attribute type identifying an object that is named. It is the name by which the object is commonly named, and conforms to the naming conventions of the country or culture with which the object is associated. In the context of message handling systems: Standard attribute identifying a user or distribution list relative to the entity denoted by another attribute (e.g., an organization name). (See Recommendation X.402.) H.19 compare An operation of the directory system to compare a value (which is supplied as an argument of the request) with the value(s) of a particular attribute type in a particular object entry. Note - This directory system operation is considered to be an optional user facility in the service context. H.20 copy information Replicated information. H.21 country name An attribute type that identifies a country. A country name is a unique designation of a country. When used as a component of a directory name, it identifies the country in which the named object is physically located or with which it is associated in some other important way. In the context of directory systems a value from ISO 3166 (Alpha-2 country codes) is used. H.22 description An attribute type which describes the associated object, e.g. as an "Yellow pages" entries. H.23 destination indicator (public telegram) An attribute type specifying the country and city associated with the object (the addresses) needed to provide the public telegram service. Note - See CCITT Recommendations F.1 and F.31. H.24 directory A collection of open systems cooperating to provide directory services. H.25 directory entry A part of the DIB which contains information about an object. H.26 directory information base (DIB) The complete set of information to which the directory pro- vides access, and which includes all of the pieces of information which can be read or manipulated using the operations of the direc- tory. H.27 directory information tree (DIT) The directory information base considered as a tree, whose vertices (other than the root) are the directory entries. Note - The term DIT is used instead of DIB only in contexts where the tree structure of the information is relevant. H.28 directory interrogation Methods to get results from a request to a directory by read, compare, list, search or abandon operations. H.29 directory management domain (DMD) A domain responsible for managing the information contained in a directory and the operation on this information. H.30 directory modification Methods to change information in a directory by add entry, remove entry, modify entry or modify relative distinguished name functions. H.31 directory name A construct that singles out a particular object from all other objects. A directory name must be unambiguous (that is, denote just one object). However, it need not to be unique (that is, be the only name which unambiguously denotes the object). See also name . H.32 directory schema The set of definitions and constraints concerning DIT struc- ture, object class definitions, attribute types and syntaxes which characterize the DIB. H.33 directory system agent (DSA) An OSI application process which is part of the directory, and whose role is to provide access to the DIB for DUAs and/or other DSAs. H.34 directory user agent (DUA) An OSI application process which represents a user in access- ing the directory. Each DUA serves a single user so that the direc- tory may control access to directory information on the basis of user's identity. DUAs may also provide a range of local facilities to assist users to compose requests (queries) and interpret the responses. H.35 directory management domain (DMD) A collection of one or more DSAs and zero or more DUAs which is managed by a single organization. Management of a DUA by a DMD implies an ongoing responsibility for service to that DUA, e.g. maintenance, or in some cases ownership, by the DMD. H.36 distinguished name The sequence of relative distinguished names of the entry which represents the object and those of all its subordinate entries (in descending order). Because of the one to one correspon- dence between objects and object entries, the distinguished name of an object can be considered to also identify the object entry. H.37 distinguished value An attribute value in an entry which has been designated to appear in the relative distinguished name of the entry. H.38 distribution list List of O/R addresses for message handling services stored in the directory. Note - This feature is considered to be an optional user facility in the service context. H.39 DIT structure The definition for an entry of an object class of the permis- sible object class or classes to which the immediate superior (or subordinate) may belong and its permissible RDN attribute types. H.40 do not dereference alias A service control which allows to prohibit that any alias used to identify the entry effected by an operation is to be derefer- enced. See also alias . H.41 do not use copy A service control allowing for prohibition of copied informa- tion. H.42 entry (directory entry) A part of the DIB which describes a particular object, and which consists of information that the directory holds about that object. H.43 error code Information provided from the directory system for the purpose of indicating to the requestor why a request could not be performed sufficiently. Note - A local directory domain may transfer the information to the requestor in a way appropriate to local requirements. Error codes may refer to service error, attribute error, update error, security error, referral error, abandon error or name error. They are transferred to service messages for the user. H.44 facsimile telephone number An attribute type which specifies a telephone number for a facsimile terminal (and optionally its parameters) associated with an object. H.45 filter A filter parameter applies a test to a particular entry and either is satisfied or not by the entry. The filter is expressed in terms of assertions about the presence or value of certain attri- butes of the entry, and is satisfied if and only if it evaluates to TRUE. H.46 intercommunication In the context of directory services a relationship between services, where one of the services is a directory service, ena- bling the user of a service to communicate with the directory. Note - The term also applies for the relation between public and private directories, for the relation between directory ser- vices of different service providers and for the relation between directory management domains. H.47 ISDN address An attribute type which specifies an ISDN address associated with an object. H.48 knowledge information An attribute type which specifies a human-readable accumulated description of knowledge mastered by a specific DSA. H.49 locality name An attribute type which specifies a locality. When used as a component of a directory name, it identifies a geographical area or locality in which the named object is physically located or with which it is associated in some other important way. H.50 list An operation in the directory system to obtain a list of immediate subordinates of an explicitly identified entry. Under some circumstances, the list returned may be incomplete. Note - This directory system operation is considered to be an optional user facility in the service context. H.51 local scope A service control which restricts the scope of directory operations. Note - The definition of local scope is itself a local matter, and may, for example, mean a limit within a single DSA or a single DMD. H.52 member An attribute type which specifies a group of names associated with the object. H.53 modify An operation in the directory system to perform a series of one or more of the following modifications to a single entry: - add a new attribute; - remote an attribute; - add attribute values; - remove attribute values; - replace attribute values; - modify the RDN of a leaf entry; - modify alias; - modify entry. Note - This directory system operation is considered to be an optional user facility in the service context. H.54 modify operations These are operations to alter the contents of the directory: add entry, remove entry, modify entry and modify relative dis- tinguished name. H.55 multicasting This is a special case of distributing simultaneously a request to more than one DSA. See Recommendation X.518. Note - A set of agreements is required between the domains wanting to interact based on this method. H.56 name In the context of a directory, the designation of entries and parts thereof. A name must be unambiguous, that is, denote just one object. However, a name need not to be unique, that is be the only name that unambiguously denotes the object. Note - See X.500-series of Recommendations for further study. H.57 naming authority An authority responsible for the allocation of names. Each object whose object entry is located at a node in the DIT is, or is closely associated with, a naming authority. In the context of public directory services, the administra- tion directory management domain administers the part of the DIT covered by entries of that domain. It may act as naming authority for the distinguished names used in the scope of the domain. H.58 object (of interest) Anything in some "world", generally the world of telecommuni- cations and information processing or some part thereof, which is identifiable (can be named), and which is of interest to hold information on the DIB. H.59 object entry An entry which is the primary collection of information in the DIB about an object, and which can therefore be said to represent that object in the DIB. H.60 object class An identified family of objects (or conceivable objects) which share certain characteristics. Note - See X.500-series of Recommendations for further study. H.61 O/R address Address of an originator/recipient of messages in the context of message handling. H.62 organization name An attribute type which specifies an organization. When used as a component of a directory name it identifies an organization with which the named object is affiliated. H.63 organization unit name An attribute type which specifies an organizational unit. When used as a component of a directory name it identifies an organiza- tional unit with which the named object is affiliated. H.64 owner In the context of a directory, that attribute type specifying the name of some object which has some responsibility for the asso- ciated object. H.65 physical delivery office name An attribute type which specifies the name of the city, vil- lage, etc. where a physical delivery office is situated. H.66 post office box An attribute type which specifies the post office box by which the object will receive physical delivery. If present, the attri- bute value is part of the object's postal address. H.67 postal address An attribute type which specifies the address information required for the physical delivery of postal messages by the postal authority to the named object. Formatted and unformatted postal addresses exist. Note - See also Recommendations F.401 and X.520. H.68 postal code An attribute type which specifies the postal code of the named object. If this attribute value is present it will be part of the object's postal address. H.69 preferred delivery method An attribute type which specifies the object's priority regarding the method to be used for communicating with it. H.70 presentation address An attribute type which specifies a presentation address asso- ciated with an object representing an DSI application entry. H.71 priority A service control which specifies the priority of a request (low, medium, high) for the service. This is not a guaranteed ser- vice in that the directory as a whole does not implement queuing. There is no relationship implied with the use of priorities in underlying layers. H.72 private directory management domain (PRDMD) A DMD managed by another organization than an Administration. H.73 public directory service A service provided by Administrations to subscribers and users for the purpose of obtaining information on addresses for telecom- munication services and other related information from an elec- tronic directory. H.74 read operation An operation of the directory system to extract an explicitly identified entry. It may also be used to verify a distinguished name. Note - This directory system operation is considered to be a basic service feature in the service context. H.75 referral Request handling by the DSA in the case of failing to find the requested information in the first DSA. In this case the directory may return a referral, which suggests an alternative access point at which the DUA can make its request. Note 1 - This is an alternative method to chaining or multi- casting. The implementation is a local matter. Note 2 - A set of agreements is requuired between the domains (DSAs) wanting to interact on the basis of this method. Whether referrals are presented to the user or not is a local matter. It has to take into account whether the domain (DSA) being referred to will accept requests from these users. Note 3 - Referrals to domains (DSAs) without prior agreement (including accounting procedures) with them are undesired. H.76 registered address An attribute type which specifies a mnemonic for an address associated with an object at a particular city location. The mnemonic is registered in the country in which the city is located and is used in the provision of the public telegram service. H.77 relative distinguished name (RDN) The unique name of an entry. It consists of a particular sequence of attribute value assertions, each of which is true, con- cerning the distinguished values of an entry. H.78 requestor The subscriber, user or system entity making a particular request to the directory. H.79 role occupant An attribute type which specifies the name of an object that fulfills an organizational role. An attribute value for role occu- pant is a distinguished name. H.80 search guide An attribute type which specifies information of suggested search criteria which may be included in some entries expected to be a convenient base-object for the search operation, e.g. country or organization. H.81 search operation An operation in the directory system to search a portion of the DIT for entries of interest, and to return selected information from those entries. Note - This directory system operation is considered to be a basic service feature in the service context. H.82 security capabilities Capabilities of a directory system to provide protection against security threats. Note 1 - These directory system capabilities are considered to be additional optional user facilities in the service context. Note 2 - See Recommendation X.509 for explanation of security capabilities. H.83 see also An attribute type which specifies names of other objects which may be other aspects (in some sense) of the same real-world object. H.84 serial number An attribute type which specifies an identifier, the serial number of a device. H.85 service control A function of a directory system to control certain performance criteria. A service control parameter contains the con- trols, if any, that are to direct the provision of the service. Note - One service control in the directory system (time limit) is an essential optional user facility. Other specific ones are additional optional user facilities in the service context, if the service provider offers them. See also S 4 of Recommendation F.500. H.86 size limit A service control which indicates the maximum number of objects to be returned in the results of a search or list operation (the control is only applicable to those operations). If the list size is exceeded, any results equal in number to the size limit should be returned, with the indication that the results are incom- plete due to the size limit constraint. If this component is omit- ted, no maximum is implied. H.87 state or province name Identifies the geographical subdivision in which the named object is physically located or with which it is associated in some other important way. H.88 street address An attribute type which specifies a site for the local distri- bution and physical delivery in a postal address, i.e. the street name, place, avenue and the house number. When used as a component of a directory name, it identifies the street address at which the named object is located or with which it is associated in some other important way. H.89 subclass Relative subordinate to a superclass, an object class derived from a superclass. The members of the subclass share all the characteristics of another object class (the superclass) and addi- tional characteristics possessed by none of the members of that class (the superclass). H.90 subscriber A user of a telecommunication service, normally based on a contract with the provider of a public service. H.91 superclass Relative superior to a subclass, an object class from which a subclass is derived. H.92 supported application context An attribute type which specifies the object identifier of an application context that the object (an OSI application entity) supports. H.93 surname An attribute type which specifies the linguistic construct which normally is inherited by an individual from the individual's parent or assumed by marriage, and by which the individual is com- monly known. H.94 telephone number An attribute type which specifies a telephone number associ- ated with an object. Note - The format of internationally agreed telephone numbers follows Recommendation E.164. H.95 teletex terminal identifier An attributed type which specifies the teletex terminal iden- tifier for a teletex terminal associated with an object. Note - The format follows Recommendation F.200. H.96 telex answer-back An attribute type which specifies the telex terminal identif- ier for a telex terminal associated with an object. Note - The format follows Recommendation F.60. H.97 telex number An attribute type which specifies the telex number, country code, and answer-back code of an telex terminal. Note - The format follows Recommendation F.69. H.98 time limit A service control that indicates the maximum elapsed time, in seconds, within which the service should be provided. If the con- straint connot be met, an error is reported, unless it was a search or a list operation, in which case partial results should be returned to the DUA with the indication that a time limit problem has been encountered. If this component is omitted, no time limit is implied. Note - This service control is an essential optional user facility. H.99 title An attribute type which specifies the designated position or function of the object within an organization. H.100 user In telecommunication service context: A human being using a service. In a technical context: A human being, an entity or a process. Note - A user will not necessarily be a subscriber of a telecommunication service. H.101 user certificate See Recommendations X.520 and X.509. H.102 wildcard In the context of directory services, a way to replace unknown parts of attributes for a request to the directory. H.103 user password A sequence of characters to identify a user. H.104 videotex user number An attribute type which specifies a videotex user number asso- ciated with an object. H.105 white pages See under "classified information". H.106 X.121 address An attribute type which specifies a number from the X.121 numbering plan associated with an object. H.107 yellow pages See under "classified information".