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, including 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 versions); (c) that national initiatives are being taken to develop electronic 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 subscribers to determine rapidly and easily what services are available 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 messages. 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 directory information as widely available as possible, it is anticipated that Administrations will aim to provide global electronic directory 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, operational 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 services, 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 permitted 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 service aspects. 3 Organizational provisions Provision of a public directory service will be done in accordance 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 authority 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 recipient, 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.1Basic 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 subscribers 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 ambiguities; names should admit natural abbreviations and commonly used variations in spelling. 4.1.2Non-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 credentials, under conditions specified by the provider of the directory service; - to provide possibilities for the search of distribution 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.1Basic service features Basic service features are inherent in directory services and are always available for use in directory service. They are provided by all service providers offering international public directory 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.2Optional user facilities Optional user facilities may be selected by the user or subscriber 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 bilateral 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. TABLE 1/F.500 Classification of optional user facilities Classificati on Abandon E (see Note 1) Add A Additional service A controls Compare A Distribution lists A List A Management of access A (see Note control 2) Modify A Remove A Security capabilities A Time limit service E control 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, § 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. 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 studied further. Some others will need further study under service aspects. The following list may provisionally be considered as guidance for service providers to be taken into account for the provision 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 parameters 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 service 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 following service controls are provided by the system application (see Recommendation X.511): 4.4.1Prefer 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 provider who may allow the user to invoke it. 4.4.2Chaining prohibited The scope of a search will then be limited to the local portion of the Directory Information Base (DIB) by prohibiting chaining. The setting of this service control is for the service provider who may allow the user to invoke it. 4.4.3Local scope The scope of the operation will be limited to the local portion of the DIB. The determination of local is restricted to a single DSA or DMD in accordance with an Administration's policy. For the international intercommunication of public directories, 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.4Do not use copy This service prevents a DMD from returning copied information. The setting of this service control is for the service provider who may allow the user to invoke it. 4.4.5Do 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 provider. 4.4.6Priority: low, medium, high The setting of this service control is for the service provider. The usefulness of this service control is for further study. 4.4.7Time 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 provider 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.8Size 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.9Scope of referrals Indicates the scope to which a referral (or advice), if generated, 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 provider 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 operation; locally held copies of information are permitted; no preference 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 constructed 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. However, 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 Information 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. However, this does not preclude other directory information structures. Thus, an entry may be viewed as an entity which is named through one or a series of attributes. A company may be sufficiently 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 recommendations, the term “distinguished name” is used. This is the combination 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 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 classifications of requests to the directory service are provided. 5.4.1Common 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 Question 14/1. 5.4.2Business 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.3Organization 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 § 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.4Use 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). TABLE 2/F.500 Use of attributes for each type of request Attribute type Abbrevi for for for ation Type 1 Type 2 Type 3 Business category BCTG - M R Common name COM M Q Q Country name CTN M M M Description (free DES R R R text) Destination DI - - - indicator (public telegram) Facsimile FAX - Q Q telephone number ISDN address ISDN - Q Q Knowledge KI - - - information Locality name LOC M Q Q Member MEM R R R Object class CLASS Q Q Q O/R address (MHS) O/R R R Q (see Note 1) Organization name ORG - - M Organizational OUN - - Q unit name Owner OWN - - - Physical delivery PDO Q Q Q office name Post office box POB Q Q Q Postal address PADD Q Q Q Postal code (see PCOD Q Q Q Note 2) Preferred DLM R R R delivery method Presentation PRADD R - R address Registred address RADD - R R (public telegram) Role occupant RO R - R Search guide SG R R R See also SEE R R R Serial number SN - - - State or province STN M (see Q Q name Note 3) Street address SADD Q Q Q Supported SAC Q Q Q application context Surname SUR Q Q Q Telephone number TEL Q Q Q Teletex terminal TTX R Q Q identifier Telex answerback A/B R R R (see Note 4) Telex number TLX R Q Q Title TIT - - Q User certificate UC R R R User password UP R R R Videotex user VTX Q Q Q number (see Note 4) X.121 address X.121 - Q Q 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. 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 § 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 information 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 restrictions 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 efficiently 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 § 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. However, 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 qualification. “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. TABLE 3/F.500 Qualifications of attribute types Attribute type Mandator Required y length Business category Yes 128 Common name Yes 64 Country name (see Note 1) Yes 30 Description Yes 1024 Destination indicator (public Yes 4 telegram) 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 Yes 15 Note 3) Presentation address No - Registered address (public Yes 60 telegram) 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. 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 repertoires. For the intercommunication between public directory services, the repertoires may be agreed to bilaterally. However, where no such agreement exists, the character repertoire 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 Administrations with which no bilateral agreement has been reached. Subscribers have to be instructed on the use of the appropriate character repertoires. 6.2 Language of requests to the directory and responses from the directory Subject to the conditions in § 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 partial 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 employing 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.1Primary (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 subscriber 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.2Secondary 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 information 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 subscribers 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 subscribers' 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 acknowledgement 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 indicating 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 communication networks: directory X.500 The directory - Overview of concepts, models and services 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 communication networks: open systems interconnection (OSI) 10.3 Recommendations of the F.400 series - Message handling and directory services operations and definition of service 10.4 Recommendations of the X.400 series - Data communication networks: message handling systems