Texas Z:
The Texas Z39.50 Requirements and Specifications Project

A Discussion Paper


William E. Moen, Ph.D.
School of Library and Information Sciences
University of North Texas
Denton, Texas

August 11, 1998
Revised August 24, 1998


This discussion paper provides background information on issues related to use of Z39.50 in libraries and other information organizations in Texas. During a series of Z39.50 tutorials in May 1998 (organized by the Texas State Library (TSL) and conducted by the author), participants expressed an interest in developing specifications for procuring and implementing Z39.50 products and understanding how to solve interoperability problems between Z39.50 implementations for searching library catalogs and other bibliographic databases. TSL is initiating the Texas Z39.50 Requirements and Specifications Project (subsequently referenced as the Texas Z Project) to develop a set of requirements and specifications that libraries can use in purchasing Z39.50 products and in implementing Z39.50. To carry out this project, current and potential users of Z39.50 need to participate in identifying the functions to be supported by Z39.50 and the requirements to specify when procuring Z39.50 products. To this end, TSL is bringing together a group of librarians from across the state to work for 9 to 12 months on this project. This discussion paper will serve as a foundation document for the first meeting in August 1998. The goals of the meeting will be to identify strategies, procedures, and tasks of a project working group that will result in a consensus-based set of Z39.50 requirements and specifications.

This paper does not provide background information on Z39.50 and its uses; the author assumes basic knowledge of Z39.50 functions and terminology. (The paper, however, provides pointers to resources for additional information on Z39.50 and the topics discussed; see References). The paper characterizes search and retrieval interoperability problems, sources of such problems, and potential solutions to the problems. In addition, it attempts to highlight both long and short term goals and solutions for libraries as they attempt to address increasing demands for integrated access to a wide range of networked resources, including access to library catalogs and other bibliographic resources. Finally, the paper proposes processes and a timetable for this project, specifically proposals for roles, responsibilities, and tasks of a Texas Z Working Group.

Z39.50 is becoming an important strategic tool for libraries and other information organizations. The use of Z39.50 can enhance resource sharing by providing a single interface to search multiple library catalogs; once resources are identified, Z39.50 can support item ordering. Z39.50 is also providing new access to wider ranges of information resources such as geospatial data, museum information, government information, and biological specimen and other natural history information. With the users' desires increasing for integrated access to networked information, Z39.50 becomes a foundational support for new information services. To exploit fully Z39.50 capabilities, however, requires the identification of functional requirements as well as providing guidance in specifying what features of Z39.50 should be used. The Texas Z Project can provide Texas libraries with critical guidance as they move to procure and implement Z39.50 products.


The Problem and Opportunity

Libraries across Texas have purchased and implemented, or are planning to purchase and implement Z39.50 products. In many cases, libraries have simply required that new systems are "Z39.50 compliant." Unfortunately, that requirement does not sufficiently specify requirements for Z39.50. According a recent evaluation study, librarians often are not familiar with or aware of features supported by the Z39.50 standard when they procure Z39.50 products (see An Evaluation of Z39.50 within the SILO Project http://www.silo.lib.ia.us/bluang.html ).

In determining Z39.50 use, librarians have a number of decisions to make. For example, libraries can implement a Z39.50 client or a Z39.50 server or both. The decision of which to implement depends on the type of access to information the library intends to provide: for example, does the library want to provide Z39.50 access to its resources or provide its patrons access to other libraries resources? Further, some libraries may want to provide Z39.50 access only to bibliographic data while others want to provide their patrons with the capability to search and retrieve a variety of information resources including bibliographic records, museum objects, and government information. Identifying these requirements is a critical first step. A second key step is specifying the features and details of Z39.50 products and implementations to support these varying requirements. A simple "Z39.50 compliant" statement in a Request for Proposal is not sufficient.

Many libraries anticipate their Z39.50 implementations will allow them to transparently search and retrieve bibliographic records from various library catalogs (whether from the functional perspective of technical services, reference and public access, interlibrary loan, or subject specialists). Semantic interoperability between separately developed Z39.50 accessible library catalogs is often lacking and the results are less than satisfactory for both professional staff and library patrons. The interoperability problems are not insurmountable but require libraries to demand more of their Z39.50 implementation developers and vendors. To demand more of the vendors means that the libraries must be able to specify a base set of common specifications so all Texas libraries' Z39.50 implementations can interoperate in a meaningful way.

The Texas Z Project will address the issues and problems librarians are encountering as they attempt to provide access to global information resources or simply search multiple library catalogs within a library system or across the entire state. The Texas Z Project is an opportunity to build consensus for a set of Z39.50 specifications that libraries can reference when procuring Z39.50 products. The use of such specifications can lay the groundwork for increased resource sharing across the State, leading possibly to a Texas Virtual Union Catalog (i.e., a distributed set of library catalogs which through Z39.50 can be viewed as one logical resource; see for example the Virtual Canadian Union Catalogue Project http://www.nlc-bnc.ca/resource/vcuc/ ). Given the varying requirements of different types of libraries and functional areas of the libraries, the Texas Z Project can begin building a modular set of specifications to provide functionality from Z39.50 as required by individual libraries while establishing a base set of common specifications to assure or at least increase the likelihood of meaningful interoperability. Most importantly, the Texas Z Project will increase Texas librarians' knowledge and sophistication as Z39.50 product consumers and provide them a reference set of specifications for negotiating with Z39.50 suppliers.

Texas is in a position to exploit the experience gained from recent Z39.50 projects in other states and in other countries. As an example, a recent evaluation of the State of Iowa Libraries Online (SILO) Project, An Evaluation of Z39.50 within the SILO Project (http://www.silo.lib.ia.us/bluang.html), suggested that many problems associated with the use of Z39.50 in SILO could be alleviated through the more consistent implementation of Z39.50 in the separate systems. The evaluation recommended developing a community "profile" (i.e., a set of specifications for using Z39.50 within a particular community or for a particular application) and also recommended the following actions:

The Texas Z Project is our State's proactive response to resolving problems and issues related to Z39.50 by identifying requirements and building consensus on a base set of common specifications that can serve the State's library communities. The time is right to provide guidance and specifications for implementations so that wide-spread interoperability can be achieved and librarians procuring Z39.50 products can be better informed.


Z39.50 and Interoperability

Although the development of Z39.50 has been underway for nearly 20 years, only in the past five to six years have library automation vendors and other Z39.50 developers produced stable and robust Z39.50 implementations. During this period, a wide range of commercial Z39.50 products have become available. The origins of Z39.50 are solidly in the library community, but since the early 1990s other information communities have seen the potential of an standard information retrieval protocol for providing access to a wide variety of distributed, networked resources. These resources include online library catalogs, bibliographic databases, government information, chemical databases, museum information, etc. With the increased use of Z39.50 across different types of information resources and different developers' implementations, new problems in interoperability have surfaced.

A primary goal of Z39.50 has been to enable separate information retrieval systems to interoperate, and thus provide a mechanism for a user to search one or more databases in a uniform and transparent manner. In addition, Z39.50 enables the user to retrieve data from one or more databases in a uniform manner. Interoperability is a complex challenge. Problems with interoperability result in users finding themselves unable to conduct meaningful and consistent information retrieval transactions across multiple implementations. There are many reasons for this, and it is important to identify several spheres that impact interoperability, and more generally, Z39.50 usability. There appear to be three such spheres: the standard itself; Z39.50 implementations; and local information retrieval system functionality.

The Standard: When thinking about Z39.50, it is important to understand the functionality supported by the features in the standard. It is an information retrieval protocol that enables one system to connect to another, express queries in a standard format, and retrieve results from the databases in one or more standard formats. In addition, the standard supports other important functions. (See Attachment A for list of functions supported by Version 3 of Z39.50-1995.) Usability problems can occur at the level of the standard when Z39.50 does not support functions desired by users. For example, standardized means of addressing holdings records across systems is one are of recent concern (see Use of Z39.50 to Access Distributed Union Catalogues Summary of ZIG Discussions http://www.nlc-bnc.ca/iso/z3950/holds1.htm ).

Implementations of Z39.50: Although Z39.50 is a standard, it is a standard that contains many options and choices from which implementors can choose. Two implementors that build Z39.50 implementations may find problems in interoperability between their systems because of the separate choices from the standards each implementor made. This is especially true with implementations based on Version 3 of the standard. Version 3 has a number of features that not all implementors support. Thus, if one implementor builds support for features A, B, and C and another implementor builds support for features B, D, and E, the two implementations will not interoperate on features A, C, D, and E. For basic library catalog searching, all Z39.50 implementations should support three core features: Init, Search, and Present. Yet major interoperability problems arise even for basic searching of library catalogs because of differences in attribute types and values supported (discussed in more detail below) and the record syntaxes supported in separate implementations.

Local Information Retrieval Systems: In this sphere of influences, there are differences in the functionality supported for information retrieval (IR) by the local systems. Z39.50 cannot add functionality to local systems. The standard simply defines a standard way of exchanging protocol messages that support existing functions of local IR systems. Thus, if a local system provides a feature to allow sorting of result sets and another system does not support sorting, a protocol request to have the latter server sort results sets will be impossible to execute. More problematic for interoperable search and retrieval are the access points and indexes provided by local systems and the types of searching supported. For example, if one IR system for bibliographic records supports Personal Author searching (i.e., there is an index for Personal Author names from the MARC records) and another system only supports searching on Names (e.g., as both subjects and authors), there will be interoperability impact. Similarly with systems that do or don't support truncation, proximity searching, and Boolean searching.

The preceding is not intended to be a comprehensive list of impacts on interoperability. Instead, it suggests that we need to be clear from which vantage point the Texas Z Project will focus in its requirements and specification development. The focus of the Texas Z Project will be interoperability issues in the sphere of Z39.50 implementations. But as we address issues that occur from variations in implementations, it will soon be clear that differences in local IR system functionality can still cause interoperability problems and can impact the decisions we can make.


Profiling as an Approach to Solving Z39.50 Implementation and Interoperability Problems

Profiles are a useful approach to solving interoperability problems between Z39.50 implementations. Profiles are auxiliary standards mechanisms that reflect agreements between users and implementors on a set of requirements and Z39.50 specifications to address those requirements. Profiles can be considered a subset of Z39.50 features and specifications from the standard. Profiles detail specifications and choices among options that implementations will support including:

There are a number of profiles that have been developed for using Z39.50 in various application contexts (see the Z39.50 Maintenance Agency site for a list of Z39.50 profiles http://lcweb.loc.gov/z3950/agency/).

Of particular interest to Texas Z Project are the profiles recently developed to address interoperability issues for searching library catalogs. The first profile to address basic library catalog search and retrieval was the ATS-1 Profile (for Author, Title, and Subject searching). "This profile specifies rules aimed at improving the reliability of Z39.50 search results....its purpose is to ensure that complying origins and targets can provide basic search access to bibliographic databases, similar to the common online catalog systems used in many libraries."

In the past two years, other profiles emerged to address basic library catalog searching. These include:

Common to all of these profiling efforts is the desire to improve overall interoperability among Z39.50 implementations that provide access to library catalogs and other bibliographic databases. A key area for improvement revolves around the use of the Bib-1 Attribute Set, how the attributes values are mapped to local IR systems, and the record syntaxes supported to retrieve records from MARC-based library catalogs. A primary component of the Texas Z Project falls into this arena.


Areas of Z39.50 Specifications Issues to Address

The Texas Z Project should initially focus on two major areas in addressing Z39.50 specifications:

  1. Z39.50 features to specify
  2. Z39.50 attribute types, values, and combinations to specify.

Assuming that there may be several levels of conformance identified in the specifications, there will be at least a base level that includes the three core features of Z39.50:

Attachment A lists other Z39.50 features that can be considered, but for basic search and retrieval against library catalogs, these three features may be considered sufficient.

The second area of concern deals with attribute types, values, and their combination. Z39.50 provides the Bib-1 Attribute Set http://lcweb.loc.gov/z3950/agency/defns/bib1.html as a basic language for expressing searches against library catalogs and other bibliographic databases. The document, Attribute Set Bib-1 (Z39.50-1995): Semantics ftp://ftp.loc.gov/pub/z3950/defs/bib1.txt contains a list of the Bib-1 Use attributes and their semantics. Issues related to attributes and their mapping to local IR systems comprise a critical, but challenging arena. Much of the effort of the profiles mentioned above focus on standardizing the implementation of attributes.

The National Library of Canada has done several analyses that indicate why interoperability problems are rife in the arena of searching. The document, Bib-1 Attributes Supported by Selected Vendor Servers http://www.nlc-bnc.ca/resource/vcuc/ebib-1.pdf, indicates that not all vendors' Z39.50 implementations support the same Bib-1 attributes. In that survey, only two attributes Title (4) and Subject (21) were supported by all products. One implication is that searches against all these products for title or subject should provide consistent server behavior and meaningful results. A more problematic implication is that searches using the Bib-1 attribute for Author cannot be executed by all servers. The Texas Z Project can help raise awareness of these types of problems. Further, the resulting Texas Z specifications can put pressure on vendors to modify their systems (some of which are customizable for which attributes are supported) to support a common base set of attributes. As a caution, however, a Z39.50 implementation on an IR system may be constrained by indexes available on the local system. This is a problem not related to Z39.50 functionality or semantic interoperability, but it does impact whether or not searches against such systems are not just successful but even possible.

When one examines the existing profiles that address search and retrieval against library catalogs, the profiles themselves do not all specify the same attribute values and combinations. Again, the National Library of Canada has compared attributes in the profiles mentioned above (see Preliminary Comparison of Bib-1 Attribute Combinations Among Several Profiles http://www.nlc-bnc.ca/resource/vcuc/profcomp.htm ). These differences pose problems both for the libraries that are interested in interoperability across these various profiles as well as with the vendor community. With the creation of multiple profiles all attempting to address similar interoperability problems, vendors are faced with choosing which profiles to support. The Texas Z Project must be sensitive to vendors concerns related to the numbers of separate profiles they may be required to support.

Although Texas libraries may have some unique, local requirements for searching library catalogs through Z39.50, it is more likely that a Texas Z profiling effort will build on the existing profiles -- especially for basic search and retrieval requirements. In addition, the National Library of Canada is coordinating an international effort to harmonize the various profiles mentioned above to result in a single international profile for basic search and retrieval against library catalogs. The Texas Z Project is an opportunity to have input into that effort while at the same time working to ensure that the resulting Texas Z39.50 requirements and specifications utilize the international specifications. The better interoperability Texas Z39.50 implementations have both among libraries in Texas as well as with international Z39.50 implementations, the more cost effective and usable Texas Z39.50 implementations will be.


A Proposal for the Texas Z Project

This section proposes a number of strategies and tasks to be considered for the Texas Z Project. TSL has already begun the initiative by commissioning this discussion paper and coordinating the organizational meeting for the project. Assuming that there is sufficient interest by librarians and their libraries to support the project, the following is a preliminary list of ideas for discussion and issues to be addressed at the organizational meeting.

A Texas Z Project Working Group:

TSL solicited interested individuals and groups to participate in a project working group. In any specifications/profile development activity, it is imperative that representatives of impacted organizations participate. It is only with the input from representatives of different library types and representatives from different functional areas of the libraries that a clear set of common requirements can be developed. Specification of Z39.50 can be a relatively straightforward task, assuming that the identification of the requirements has been done. This is a first task of the working group. There may be a need for prioritizing requirements and modularizing the specifications to ensure that basic common functionality can be agreed to while providing a migration path for support of more sophisticated functionality. Clearly, TSL cannot develop specifications in isolation, and the involvement of appropriate representatives in an open process of requirements identification and specification writing is essential.

The working group will comprise representatives of the Z39.50 user community to enable users to identify their requirements and a draft set of Z39.50 specifications. Vendor input and review will be essential when the preliminary requirements are identified and draft specifications are in process of development. In these processes there is the possibility that the user community will identify requirements that few if any vendors can address. Upon review by the vendors, it may be necessary to modify specifications for near term implementations. However, the requirements can also communicate to vendors what they should be working on for future releases. In effect, the Texas Z specifications should provide vendors and Z39.50 implementors with the basis for a business case to evolve their Z39.50 products AND possibly to enhance current local information retrieval systems (e.g., building appropriate indexes to support the identified distributed searching requirements resulting from the Texas Z Project).

Participants in the working group must understand that identifying requirements will be an evolving process, as will be writing the specifications. Through the entire process, all participants (working group members, TSL staff, and consultants) will develop an understanding and build consensus around the requirements and specifications. Thus, working group members will need to commit the time and energy for active involvement -- both in meetings and electronic communication for the duration of the Texas Z Project.

Goals, Objectives, and Scope of the Project

At the organizational meeting, it will be necessary to agree on the goals, objectives, and scope of the project. Realistic goals could include:

A set of measurable objectives can be derived from these goals.

In terms of the scope of the project, the working group may identify one or more phases of activities. In the near term, the Texas Z Project should consider focusing on requirements and specifications related to basic search and retrieval against online library catalogs or other similarly structured bibliographic databases. The scope of the project, however, will likely depend on the set of requirements identified by the working group.

Tasks and Activities for the Project

The working group will need to undertake a number of activities and tasks. Two important activity areas concern the identification of functional requirements and the writing of the specifications. Tasks related to identifying functional requirements may include determining:

Based on the functional requirements, there will be a number of tasks related to developing and documenting the Z39.50 specifications to support the requirements. These tasks may include:

In addition to these types of activities and tasks, the working group may also need assistance to increase its knowledge and understanding of Z39.50. The working group may have specific information needs that might call for additional tutorial sessions on aspects of Z39.50, on specifications writing, etc. The group will need to consider appropriate mechanisms for gaining the knowledge necessary for carrying out all aspects of the project.

Processes and Procedures of the Working Group

The working group will need to identify the most effective manner to carry out the project. Face-to-face meeting are probably necessary at various points during the project. Electronic communication (e.g., a listserv, a web conferencing system) can be used between meetings to conduct business and address issues. There is a Texas Z39.50 listserv that might be used for the working group, or it may be appropriate to establish a separate mechanism for carrying out the work of the group (or subgroups). The general Texas Z39.50 listserv, however, can be a useful tool for keeping other interested parties abreast of the progress of the Texas Z Project.

It may also be necessary to have subgroups of the working group that can be assigned particular tasks (e.g., a subgroup on documenting the requirements, a subgroup to draft specifications, etc.). If there are subgroups, additional coordination will be necessary to ensure that deadlines are met and deliverables are shared with the larger working group.

Roles and Responsibilities of Various Participants

For the Texas Z Project, there may be a number of organizations and individuals who are involved or interested in its outcomes. The following identify key participants and possible roles and responsibilities.

In addition to the participants in the project, there are at least two other groups who are critical to the overall success of the effort:

Other participants or interested parties may need to be identified. It is important to identify and communicate with all potential stakeholders of the outcome of the Texas Z Project.

A Tentative Time Table of Activities

Given that libraries have Z39.50 implementations (although they may not have them "turned on" at this point) or are considering purchase of Z39.50 products through TIF grants, it is imperative that the Texas Z Project move expeditiously towards a consensus-based set of specifications. The following proposes a tentative timetable for the project:

Date     Activity
August 1998     Working Group Meeting: Organizational Meeting and Planning Session
September 1998     Working Group Meeting: Requirements Identification Meeting
September-October 1998     SubGroup on Requirements
November 1998     Working Group Meeting: Finalization of Requirements/Specifications Identification and Writing
November-December 1998     SubGroup on Specifications Identification and Writing
January 1999     Working Group Meeting: Finalization of First Draft of Specifications
February-March 1999     Public Review Period for Draft Specifications
April 1999     Revise Draft Specifications based on Comment
April 1999     Roll Out of Texas Z Specifications at TLA in Next-to-Final Version;
Working Group Meeting at TLA for evaluation of effort, planning future activities, etc.
Post TLA -- 1999     Finalize and Approve Specifications; Publish; Encourage Use


Outcomes of the Texas Z Project

At the outset of this project, participants should be clear on what will be the outcome of this project. As envisioned by this document, the project will be focused on identifying requirements and developing a set of common Z39.50 specifications that can be used by Texas libraries when procuring and implementing Z39.50 products. As part of this process, it is likely that Texas librarians will increase their knowledge and sophistication of Z39.50. With their increased knowledge, they will be better prepared to buy Z39.50 products that will support important functionality to server their users better. In addition, with this effort occurring during 1998-1999, Texas can provide important input into the international work on a profile to support Z39.50 search and retrieval against bibliographic databases; work on that profile is just getting underway.

The following summarizes possible outcomes of the project:

It is important to realize that although the project can result in Z39.50 specifications and guidance, it will be necessary to ensure that the specifications will support the functional requirements of the libraries. Therefore, the working group may want to consider a "testbed" to encourage implementation of the specifications and to demonstrate how such specifications can be utilized to achieve the level of interoperable search and retrieval desired. Implementation of the specification is not a given, and thus, the working group may want to discuss a program for encouraging, training, and assisting libraries in their implementation and use of Z39.50.

In addition, during the project the working group may identify additional areas of specification that address more enhanced features of Z39.50. The working group may want to discuss procedures and processes for continuing the important work initiated in Texas Z.

References & Additional Resources

ATS-1 Profile. http://lcweb.loc.gov/z3950/agency/profiles/ats.html

Blue Angel Technologies, Inc. (1998). An Evaluation of Z39.50 within the SILO Project http://www.silo.lib.ia.us/bluang.html

Finnigan, Sonya and Ward, Nigel (1997). Z39.50 Made Simple. http://www.dstc.edu.au/DDU/projects/ZINC/zsimple.htm

Lunau, Carrol. (1998, May 26). Preliminary Comparison of Bib-1 Attribute Combinations Amongst Several Profiles http://www.nlc-bnc.ca/resource/vcuc/profcomp.htm

Lunau, Carrol and Turner, Fay. (1997, April). Issues Related to the Use of Z39.50 to Emulate a Centralized Union Catalogue. http://www.nlc-bnc.ca/resource/vcuc/ezarl2.htm

Lunau, Carrol and Turner, Fay. (1997, July 18). Summary of Issues Related to the Use of Z39.50. http://www.nlc-bnc.ca/resource/vcuc/ezarlsum.htm

MODELS Library Interoperability Profile Family. http://www.ukoln.ac.uk/dlis/models/clumps/technical/zprofile/zprofile.htm

National Library of Canada (1997, September). Bib-1 Attributes Supported by Selected Vendor Servers http://www.nlc-bnc.ca/resource/vcuc/ebib-1.pdf

National Library of Canada. Virtual Canadian Union Catalogue Project [homepage]. http://www.nlc-bnc.ca/resource/vcuc/

National Library of Canada. (1998, January 26). Virtual Union Catalogue Z39.50 Profile, Draft Version 1.5. http://www.nlc-bnc.ca/resource/vcuc/profil4.htm

Turner, Fay. (n.d. circa April 1997). Use of Z39.50 to Access Distributed Union Catalogues Summary of ZIG Discussions. http://www.nlc-bnc.ca/iso/z3950/holds1.htm

Z39.50 Maintenance Agency. (1995, September). Attribute Set Bib-1 (Z39.50-1995): Semantics ftp://ftp.loc.gov/pub/z3950/defs/bib1.txt

Z39.50 Maintenance Agency. (1998, June 15). Bib-1 Attribute Set http://lcweb.loc.gov/z3950/agency/defns/bib1.html

Z39.50 BIB-1 Attribute Set Profile for CENL http://linnea.helsinki.fi/z3950/cenl_profile.html

Z39.50 Maintenance Agency. http://lcweb.loc.gov/z3950/agency/

Attachment A
Functionality Supported by Z39.50-1995 (Version 3)

The following information is taken from Z39.50 Made Simple by Sonya Finnigan, Nigel Ward. Distributed Systems Technology Centre Pty Ltd
University of Queensland, QLD 4072. http://www.dstc.edu.au/DDU/projects/ZINC/zsimple.htm


Summary of Z39.50 Version 3 Facilities

Z39.50 Version3 provides eleven facilities of the Information Retrieval service. Most consist of logical groups of services; in several cases, a facility consists of a single service. Following is a summary description of the eleven facilities:

Initialization Facility, Init Service-- allows the client to negotiate a Z-association. This includes supported Z39.50 features, default character set, default language, protocol version and user authentication.

Search Facility, Search Service-- enables an client to query databases at a server system using a well known search format, creating a result set of records on the server and to receive information about this result set. The query may contain Boolean operators, fielded search terms, proximity searching, weighted search terms, truncation specification, generalized pattern-matching etc.

Retrieval Facility -- (two services)

Present Service: allows the client to request one or more records from a specified result set. This includes requesting specific ranges of search results (e.g., records 10 through 20), specific elements in a record (e.g., title and author), specific variants of the record (e.g., MS-Word and HTML, or English and French), search term highlighting, etc. The server may also include other metadata information (scores, word frequency counts, document lengths, etc.) to enable proper merging of results obtained from multiple distributed databases.

Segment Service:: if the records requested by a present request will not fit in a single segment, and if segmentation is in effect, the server returns multiple segments, each of which contains a portion of the records.

Result-set-delete Facility, Delete Service-- enables an client to request the deletion of specified result sets, or all result sets.

Access Control Facility, Access Control Service -- allows a server to challenge an client. The challenge might pertain to a specific operation or to the Z-association. The access-control request/response mechanism can be used to support access control challenges or authentication, including password challenges, public key cryptosystems, and algorithmic authentication.

Accounting/Resource Control Facility -- (three services)

Resource-Control Service: permits the server to send a resource-control request - e.g. notifying the client that either actual or predicted resource consumption will exceed agreed upon limits, and request client consent to continue an operation

Trigger-resource-control Service: permits the client to request that the server initiate the resource-control service, or cancel the current operation.

Resource-report Service: permits the client to request a resource-report pertaining to a completed operation or to the Z-association.

Sort Facility, Sort Service-- allows an client to request that the server sort a result set (or merge multiple result sets and then sort).

Browse Facility, Scan Service -- used to scan an ordered term list (subject terms, names, titles, etc.)

Explain Facility -- Used to discover details of the server implementation, including general features (description, contact information, hours of operation, restrictions, usage cost, etc.), databases available for searching, indexes, attribute sets, attribute details, schemas, record syntaxes, element specifications, sort capabilities and extended services supported. Explain permits the development of clients to some extent be dynamically self-configuring as they encounter various servers.

Extended Services Facility -- provides access to services outside the protocol, which may persist after the Z-association has been terminated. The extended services defined by this standard include persistent (across sessions) result sets, persistent queries, periodic search schedules, item order, and database update.

Termination Facility -- allows either an client or server to abruptly terminate all active operations and to initiate termination of the Z-association.