UDT Series on Data Communication Technologies and Standards for Libraries - Report # 8 Interlending in the Emerging Networked Environment: Implications for the ILL Protocol Standard (1995) J. C. Zeeman TABLE OF CONTENTS 1. INTRODUCTION 1.1 Scope 1.2 Definitions 2. NATIONAL AND INTERNATIONAL ACCEPTANCE OF THE ILL PROTOCOL 3. ILL SCENARIOS AND THE APPLICATION OF THE ILL PROTOCOL 3.1 Scenario 1: Document Supply Using Point to Point ILL: The Canadian" Model 3.2 Scenario 2: Document Supply Via an ILL Utility: The "US" Model 3.3 Scenario 3: Patron Initiated ILL 3.3.1 Scenario 3A: Library as Requester: OCLC Model 3.3.2 Scenario 3B: Library as Intermediary: FCLA Model 3.4 Scenario 4: Document Supply Based on ILL with Circulation Knowledge 3.4.1 Scenario 4A: Requester Checks Status 3.4.2 Scenario 4B: Utility Checks Circulation Status 3.5 Scenario 5: Reciprocal Borrowing 3.5.1 Scenario 5A: Reciprocal Borrowing as Resource Sharing 3.5.2 Scenario 5B: Reciprocal Borrowing as Patron Sharing 3.6 Scenario 6: Commercial Document Supply 4. Z39.50, ILL AND DOCUMENT DELIVERY 5. RECOMMENDATIONS AND CONCLUSIONS 6. REFERENCES List of Figures Figure 1 - Point-to-Point ILL Figure 2 - Point-to-Point ILL with Forwarding Figure 3 - ILL via a Utility as Intermediary Figure 4 - ILL Requests Passed to Other Utilities Figure 5 - Direct Patron Requesting: Utility Manages Transaction Figure 6 - Direct Patron Requesting: Library Manages Transaction Figure 7 - Requesting Library Checks Availability Figure 8 - ILL with Locations: Intermediary Manages Transactions Figure 9 - Reciprocal Borrowing as Resource Sharing Figure 10 - Reciprocal Borrowing as Patron Sharing Figure 11 - Combined Use of ILL and Z39.50 Item Order ACKNOWLEDGEMENTS This report was initially prepared in 1993 for the National Library of Canada as a contribution to the North American Interlibrary Loan and Document Delivery (NAILDD) Project and presented for discussion to the Z39.50 Implementors Group (ZIG). The report was subsequently revised and expanded based on comments received. The author gratefully acknowledges the support of the National Library of Canada, the NAILDD Project and the ZIG. He would also like to express his appreciation to Fay Turner, National Library of Canada, for her editorial support and to Leigh Swain, UDT Programme Director, for publishing this document as part of the UDT Series on Data Communication Technologies and Standards for Libraries J. C. Zeeman Software Kinetics Limited 1. INTRODUCTION In many libraries there is a sense that Interlending (ILL) activities are either in, or rapidly approaching, a state of crisis. There is a feeling that costs are out of control; that demand is increasing inexorably while staff and other resources to meet the demand are constantly reduced. This sense of crisis is reflected in a number of ILL automation initiatives currently under way, especially the North American ILL and Document Delivery project sponsored by the Association of Research Libraries. While these initiatives represent an effort to use technology to find a way out of this crisis, they are also a recognition that communication technology is now sufficiently mature to offer real benefits to both libraries and their users. These benefits include, for libraries: -reduced labour costs -the possibility of reassessing acquisition priorities; -more effective use of existing collections; and -lower costs for shipping and handling physical documents. For library users the benefits include: -access to a much larger "virtual" library through searching union catalogues and other libraries' collections; -greatly improved response times; -simplified research methods through the supply of electronic documents. The National Library of Canada (NLC) has a clear interest in the direction and implementation of these ILL and document delivery initiatives because it has made substantial investments in ILL systems both for its internal use and for the library community at large. The National Library led the development and promotion of the use of electronic data communications to support library resource sharing. Beginning in the early 1980s the NLC began developing a communication protocol to enable it to automate the messaging portions of its ILL operations. This protocol was eventually adopted as an international standard for ILL messaging, as ISO 10160 and 10161. Although the standard has been implemented in Canada, and is beginning to be implemented in Europe, there has been little interest in its implementation in the United States. The protocol is viewed by many American librarians and system vendors as both complex and unnecessary in the light of the ILL services provided by the large bibliographic utilities. Many of the current initiatives there are based on existing Z39.50 implementations and seek to integrate document requesting with Internet based searching tools. This report examines how the ILL protocol fits into the currently available set of library-based networking tools and how its use can be integrated with both discovery tools, such as Z39.50 and the various delivery mechanisms that are beginning to be available. 1.1 Scope The goals of this paper are to: -Describe how libraries and the services of information providers such OCLC and the Canada Institute for Scientific and Technical Information (CISTI) can be supported by the ILL protocol. -Analyze the extent to which the ILL protocol can support patron initiated requests and identify any shortcomings in the protocol in the light of this analysis. -Describe how Z39.50 and ILL can be used to support information retrieval and the subsequent request of an item. The primary tool for realizing these goals has been the description of a number of interlending/document supply scenarios that, for each, attempt to identify what communication facilities are required to be able to support them. In each case the investigation has assessed the extent to which the ISO ILL protocol is sufficient to meet the communication needs, and, when it is not, it has identified what additional communication services are required. This paper does not attempt to provide a comprehensive description of all the ways in which an individual could obtain documents. There are other methods that do not involve a library, these have not been specifically addressed. 1.2 Definitions The following terms are important in the context of ILL. Some of them are used with a specialized meaning within this document. Document: In the most general sense a document is an artifact that forms a record of some activity or event. This definition encompasses written text, recorded sound, recorded images both still and moving, data sets generated by sensors of various kinds, etc. Document Delivery: This term is commonly used to refer to the complete process of supplying a document to its ultimate user, including formulating and issuing the request, as well as managing the physical or electronic delivery of the document. In this sense, the ILL protocol could be seen as a component part of document delivery. In this report, however, a more restricted definition is used, in which document delivery refers only to those processes used to deliver a document to a user after a request has been processed. Document Supplier: The organization responsible for the physical or electronic delivery of a document. This may be a library that supplies items from its collections as part of an interlending agreement, or an organization that engages in supply of documents as a commercial activity. Electronic document: A document created or transcribed onto a medium and in a format that will allow it to be transmitted by electronic means over telecommunications networks. Interlibrary Loan: An arrangement by which a library can make a document that is not in its own collection available to its patron by temporarily acquiring it (or by supplying the patron with a non- returnable version or facsimile of part of the document) from a library that does own it. Interlibrary Loan Protocol: The international standards for interlibrary loan: ISO 10160 and 10161. These are OSI (Open Systems Interconnection) standards for intersystem communication for ILL. The international standards are in two parts, a service definition (ISO 10160) that defines the ILL services made available to applications using the protocol and a protocol specification (ISO 10161) that specifies the content of protocol messages and procedural rules for exchanging them. Intermediary: An organization that acts as the requester's agent in filling an ILL request. When an intermediary is involved, all communication leading to supply of the item is routed via the intermediary rather than taking place directly between the requester and the responder. This is a term from the ILL protocol. Protocol: Used here to refer to a communications protocol, which is a set of agreed rules and procedures governing the form and content of data communications to allow interoperation to take place between different, and possibly mutually incompatible, systems. Requester: A library or individual generating an ILL request to be serviced by a responding organization. In some cases the library is the requester, acting for a patron who is outside the system; in other cases the patron will generate ILL requests directly. This is a term from the ILL protocol. Responder: A library or commercial document supplier that receives an ILL request and may supply the requested item. This is a term from the ILL protocol. 2. NATIONAL AND INTERNATIONAL ACCEPTANCE OF THE ILL PROTOCOL The development of the ILL protocol dates to the early 1980s, when the advent of Bell Canada's Datapac service and its value-added Envoy100 electronic mail services first made it feasible for ILL requests to be transmitted electronically. Besides the speed improvements offered by electronic messaging, the electronic message itself could now be integrated into library systems, enabling automatic processing and record keeping. As the National Library of Canada (NLC) is mandated to support resource sharing on a national scale, a National Standard for ILL messaging was developed, which would be usable by libraries of all types and in various environments. Very few libraries, however, fully integrated ILL into their automated systems. Vendors and librarians both saw development of ILL support as a low priority when there were so many other pressing automation requirements; to most libraries, electronic messaging remained little more than a means of sending an ILL request faster than had been possible before. Although the NLC developed a protocol- based ILL system, few other libraries could afford to treat the custom system development that was necessary to either generate or receive protocol messages as a priority in their system planning. To accommodate these users, the NLC and the Canada Institute for Scientific and Techinical Information (CISTI), the country's largest ILL suppliers, used the "script" facility of the Envoy 100 electronic mail system. These scripts presented the user with an ILL request form and used the input to generate a protocol-based messages that was delivered to the National Library's mailbox. The CISTI script was not protocol based. Because of the ease of use of the Envoy scripts, the near universal coverage offered by Envoy electronic mail and its relative low cost, Canadian libraries were encouraged to obtain dial-up access to Envoy, which they used to communicate with the NLC, with CISTI, which had its own script, and also, without using scripts, with other interlending partners. A different approach was adopted in the United States, where the Library of Congress does not have a leadership role in resource sharing analogous to that of the NLC in Canada. In the United States electronic communication among libraries grew out of the existence of the very large shared-cataloguing systems, such as RLIN, OCLC and WLN. ILL messaging was not, therefore, based on the same distributed mail-oriented model as in Canada, but was centralized at the various utilities. This had the advantage that ILL decision-making could be based on accurate holdings information, but had the disadvantage that ILL operations had to be performed on a terminal connection to a remote system, with a resulting need for maintenance of manual local files, special training, etc. This centralized model of ILL messaging has been extremely successful in the United States, where the utilities have aggressively marketed their services. The success of this approach, however, has meant that alternative models for ILL messaging have been largely unexplored, and ILL work has remained a poorly integrated activity, dependent on terminal connections to the central host. 3. ILL SCENARIOS AND THE APPLICATION OF THE ILL PROTOCOL The following scenarios were originally prepared as a Canadian contribution to a meeting held by the North American Interlibrary Loan and Document Delivery project (NAILDD) in August 1993. Comments have been received from participants in that group, as well as participants in the Z39.50 Implementers' Group (ZIG), to whom the scenarios were presented at their Ottawa meeting in October 1993. The scenarios have been revised and extended on the basis of those comments. The intent in preparing the scenarios has been to examine the communications requirements of interlending and document delivery activities, and relate these to the existing ILL protocol. During the course of developing the scenarios, several weaknesses in the ILL protocol have been revealed, which are addressed further below. The general conclusion, however, has been that the protocol offers sufficient functionality for most ILL communications scenarios. 3.1 Scenario 1: Document Supply Using Point-to-Point ILL: The "Canadian" Model The Canadian approach to supporting electronic communications for ILL has largely been an evolution of traditional point-to-point ILL messaging, in which libraries communicate directly with each other to create and manage ILL transactions. A description of the manual ILL system and its use of electronic communications forms a useful background for the scenarios described below. An ILL transaction starts when a patron determines that he or she needs an item that the home library cannot supply from its own resources and asks for the item to be supplied on interlibrary loan. How the patron determines the need for a document has normally not been within the scope of the ILL department, although other parts of the library, such as the reference service, would often be involved, either by making citations available in bibliographies or by conducting searches for the patron. Certainly the sources for citations were, and remain, widely varied. In the manual system the patron normally fills in a form that is passed to the ILL office. As far as the patron is concerned, this is the end of the matter. Usually, in a few days or weeks, he or she is notified by mail or telephone that the item has arrived and that it is available for collection from the ILL office or the circulation desk. Staff in the ILL office will normally have performed a number of tasks to ensure that the item arrives. They will: -have verified that the item exists; -have verified that the item is truly not available locally; -have discovered one or more locations from which the item can be obtained; -have sent a formal ILL request to the preferred location; -they might have had a negative or conditional reply; -they might have tried other locations. All these tasks will probably have been tracked in one or more paper files maintained by ILL staff. These files are used to correlate incoming items with the requests that they filled; possibly to track outstanding requests, or items in use by patrons; to follow copyright restrictions and policies; to correlate incoming invoices with requests and verification that the items were received, etc. Each ILL office defines the nature, content and arrangement of these local files in accordance with local management, invoicing and audit policies. Verification and location discovery use a variety of tools, both electronic and paper-based. The tools include the local catalogue, union catalogues, national bibliographies, etc. Any or all might be available electronically. Multiple tools may be used to process any particular request, and a significant part of the skills used by ILL staff resides in the knowledge and experience that allow them to judge which tools to use when. Items are supplied by the supplying library as either the physical item owned by the supplier or as a facsimile (generally a photocopy) of all or part of an item. In the first case the item is intended to be returned when the loan period is over; in the second, the facsimile is not intended to be returned to the supplier. In neither case does the library permanently acquire the item, although in the latter case the patron normally does get to keep the copy. The item is normally delivered to the ILL office, where it is correlated with the patron's request, and from where the patron is notified that the item is available. The ILL office tracks the loan of a returnable item, either through files maintained in the ILL office or through the library's circulation system, and communicates as necessary with both the patron and the supplying library. The patron may request that a loan period be extended (a "renewal"); the supplying library might recall an item before the loan period was over; the supplying library might inform the requesting library that an item is now overdue, etc. Diagram not available, please refer to hard copy Figure 1 - Point-to-Point ILL The simplest interlibrary communication in this scenario involves the transfer of a message containing some form of an ILL request from the requesting library to the supplying library, followed some time later by receipt of the item itself. Messaging for both the request and the delivery can be in many forms: surface mail, electronic facsimile transmission, even voice communication by telephone. The common factor in most of these technologies is that messaging is asynchronous: transmission of the message is separated from its receipt by an interval of time, often a large one. Delivery of the item is invariably handled separately from the request. It often uses a different channel or even technology: if the request is sent by mail, the item may be delivered by a courier service; if the request is sent by electronic mail, the item may be supplied by fax, etc. As libraries have moved toward increasingly integrated automated systems, this scenario has remained a valid approach to handling ILL. Paper forms can be replaced with electronic ones, paper files with transaction databases, and paper messages with electronic communications, etc. Many libraries, however, have operational and audit requirements to retain a central ILL function. This provides their users with beneficial services in terms of discovering locations, negotiating costs and providing documents on time. It also provides the library with important benefits: control over its ILL use; feedback for acquisitions activities and policies; and optimal use of local collections. In a fully integrated requesting environment, we can expect to see electronic patron ILL request forms integrated with local citation databases in the OPAC. We can also expect ILL management systems with links to the local catalogue for verification, to electronic mail for messaging, to circulation for loan tracking and to financial management and accounting for invoicing and payment. In addition, integration of requesting channels with delivery channels is becoming increasingly feasible. In a paper-based system, the delivery of a document is a separate activity from the request for its supply. To a large extent, this is remains true in current systems, even when either the request or the delivery is electronic. It will soon be possible, however, to create fully integrated document supply systems that receive an electronic request, process it as appropriate and then deliver the document using the required channel, e.g. electronic mail or file transfer, or possibly remote printing for fax delivery. With electronic messaging, this scenario continues to form the primary Canadian model for ILL. In the Canadian environment, messaging has until recently been based on Envoy 100, the national public electronic mail service provided by Bell Canada. Envoy 100 has been available to libraries since the early 1980s and has been extensively adopted for ILL communication. It is a proprietary messaging system, accessible only via terminal connections using X.25. For this reason, there has been little incentive to integrate ILL messaging using Envoy 100 into other library systems, except by the largest users, such as the National Library of Canada and CISTI. Both the National Library and CISTI have made use of the scripting facilities of Envoy 100 to provide on-line forms for requesting libraries to complete. The National Library's interest in the use of on-line forms and the integration of ILL messaging into its internal systems led to its leading the development of a standardized protocol for ILL messaging. The protocol was initially developed nationally, and ultimately at the international level. Sophistications of this scenario supported by the ILL protocol add additional messages, and require corresponding information to be recorded in local files. There may be responses from the supplying library to the original request: "cannot supply"; "placed on hold for later supply"; "conditions must be met", etc. A conditional offer to lend requires a response from the original requester. The explicit or implicit interlibrary lending agreement between the two libraries may support supplementary ILL services, such as request cancellation; additional message exchanges will be required to invoke these services. Such additional messages do not need to be transferred using the same technology or channels as the original message. The ILL protocol is expressly intended to accommodate the whole range of messaging needed to support this traditional ILL model. Services (i.e. message types) are available to: -communicate with ILL partners to initiate the request (ILL- Request); -respond to a request (ILL-Answer, with "Unfilled, "Retry", "Conditional" "Hold-Placed", "Locations", "Will- Supply" and cost "Estimate" answers); -reply to a conditional offer ("Conditional-Reply"); -cancel a request (Cancel and Cancellation Reply); -indicate the item has been shipped and/or received (Shipped and Received); -track the progress of a loan (Recall, Returned, Checked-In, Overdue, Renew, Renew-Answer); and -report status and problems (Lost, Damaged, Status Query, Status-or-Error Report, Expiry, Message). The protocol also allows a requesting system to manage messaging with multiple potential suppliers, or for a responder to forward a request to another potential supplier, with appropriate notification to the requester. Figure 2 illustrates the communications involved in managing messages with multiple responders for a single transaction. Diagram not available, please refer to hard copy Figure 2 - Point-to-Point ILL with Forwarding The protocol does not, of course, require that all implementations support all these services. Implementations will support those services that are appropriate for the environment in which they operate. For a bare-bones ILL requesting system, such as that illustrated in Figure 1, only the ILL- Request service need be supported, together with a means of recording that a transaction has been terminated through an item having been received or sent. Most traditional ILL offices, however, would likely wish to have access to most of the message types described above as required for individual transactions. By providing a standardized set of ILL services and regulating the sequence in which those services may be invoked (e.g. a Renew request may not be sent after a Recall request has been received), the protocol facilitates the development of automated systems for use in ILL messaging and management. Such systems can automate much ILL record-keeping by maintaining complete transaction databases of both ILL requests initiated and those received. Such databases could be used to satisfy audit requirements, legal reporting requirements, copyright restrictions, etc. In addition they could provide valuable input to selection and collection management activities. They could also be used to track the quality and timeliness of service provided by individual responders, correlate this with cost and lead to more accurate policy-based decisions on ILL partners for individual transactions. There are issues of importance to ILL offices that the ILL protocol does not address. The two principal ones are billing and accounting and delivery of the document. Neither of these omissions is an oversight. Instead, the OSI application layer model on which the ILL standards are based suggests that messaging for billing purposes and for delivery should be the subject of separate protocols that are used in conjunction with ILL or other protocols (such as purchasing or payment) as appropriate. The ILL protocol does, however, allow for the exchange of a rich set of information that allows the ILL transaction to be correlated to billing transactions and financial management systems as well as to the delivered item. The request can indicate whether and how much the patron or library is willing to pay; a separate billing address can be specified; an ILL request can be for cost estimates only; a responder may supply an estimate or make an offer to supply conditional on accepting an estimate. The data elements which would be required to interface ILL to an invoicing application or to integrate an invoicing standard into an ILL application are, to a large extent, already present in the data exchanged for ILL purposes. The request can also specify the delivery mechanism that is preferred, the delivery address, the required delivery time, etc. 3.2 Scenario 2: Document Supply Via an ILL Utility: The "U.S.A." Model This scenario expands on the previous one to incorporate the use of one or more of the bibliographic or ILL utilities in the document supply process. The role of the patron in this scenario is largely unchanged, and the functions performed in the ILL office are largely the same, as are the files maintained there. The principal difference is that the steps of verification, location discovery and initial request can be carried out at a single remote site using a terminal connection to one of the national bibliographic utilities. A consequence of the development of large-scale shared cataloguing systems such as OCLC, RLIN and ISM Library Information Services (formerly Utlas) was the creation of substantial union catalogues at those sites. Given the existence of these union catalogues, a further consequence was the demand to be able to use these resources for ILL requesting. The utilities' response to these demands was to create centralized ILL facilities on their mainframe systems that enable ILL requests to be made for items found in the union catalogue. These facilities are typically based on provision of a centralized mailbox facility with special features to support ILL messaging. To create an ILL request in such a system, a user—normally staff in the ILL department—searches the union catalogue to discover the required item, and invokes a command to create an ILL request for the item. An ILL screen displayed in response to the command displays information about the selected item, enables the requester to select one or more recipients of the request on the basis of libraries indicating they held the item, and allows the input of additional information such as journal article titles and pagination, patron's name, supply-by date, preferred delivery mechanism, etc. When the user completes the request, the ILL system will automatically place the request message in each potential supplier's mailbox in turn. Each supplier is expected to connect to the system on a regular basis to check incoming requests and to respond to these requests on a timely basis. There is generally no mechanism for supporting off-line creation of requests or for delivery of messages to external mail systems; the user must connect to the utility to use the ILL facility. Diagram not available, please refer to hard copy Figure 3 - ILL via a Utility as Intermediary In this scenario, as illustrated in Figure 3, the utility provides a single convenient point of access for the most labour-intensive parts of the ILL requesting process: verification, location discovery and request issuing. The utility may also take on the role of ILL agent, whereby the utility manages interactions with a set of potential responders (a "send-to list"), communicating with each in turn until one responder undertakes to supply the requested item. The use of an ILL utility replaces most of the variety of messaging channels described for the point-to- point scenario with a single channel—messaging managed by the ILL utility. Many libraries will, of course, continue to require access to the other channels for some portion of their ILL messaging: for libraries that are not subscribers to or members of the utility; for urgent requests in which the turn-round time in the utility's mailbox is too long, etc. The single channel does, however, simplify matters for the requesting library considerably. Much of ILL work can now be done by accessing the single system. Note, however, that this access has been, and predominantly remains, terminal based—the utility provides a remote mailbox facility to which users must connect at regular intervals to check mail; mail is not sent directly to users' systems. Neither does the utility normally maintain a database of ILL transactions. An implication of this is that local records of transactions, often in the form of prints of the utility's mail screens, have to be kept in addition to the transactions that are maintained at the utility. Furthermore, however large the utilities' union catalogues become, none will ever be fully comprehensive or global and there will be a continuing need to be able to send requests to other sources not available through the utility or to be able to try multiple utilities. It should also be noted that use of the utilities' ILL requesting systems still only addresses part of the complete document supply problem - the initial request and its response. Physical or electronic delivery of documents, tracking of items during the loan period, invoicing and payment are all outside the scope of these systems, and other channels and management systems continue to be required to complete the transaction as well as to maintain local management and audit information and to issue, verify and pay invoices. The use of the utilities has not, therefore, significantly eased the paper burden of transaction management in ILL offices. The ILL protocol addresses this scenario, and provides mechanisms for improving the services offered by utilities through its support for the ILL intermediary role. The standard defines three basic types of ILL transaction, simple, partitioned and chained. The point-to-point scenario described above corresponds to the simple transaction, and the use of a utility as intermediary in the present scenario corresponds to the partitioned transaction. The chained transaction corresponds to the operation of some centralized ILL agencies such as the British Library Document Supply Centre, where not only requests, but also documents themselves are routed via the agency. This is discussed further below. In the partitioned transaction, which corresponds to the approach historically taken by North American bibliographic utilities, there are at least three participants in any ILL transaction: -the requester (the ILL department issuing the request), -an intermediary (the utility), and -one or more responders (partner libraries) to whom the request is addressed by the utility. The ILL request is created by the requester and passed to the intermediary, and the intermediary passes the request on to individual potential responders in turn until an actual responder is found. The intermediary then responds to the requester. After the desired item has been shipped—directly from the responder to the requester—and the responder has notified the utility that the request has been satisfied, all further transactions take place directly between the requester and the responder; the intermediary's participation ends when a responder has been found. Diagram not available, please refer to hard copy Figure 4 - ILL requests passed to other utilities Note that the standard also permits multiple intermediaries to be involved. This could permit, for instance, one utility to send a request to another utility when no responder has been found by the first utility, as illustrated in Figure 4. This illustrates a request passed from a library to a utility, which communicates with its potential suppliers in an unsuccessful attempt to fill the request. The utility then forwards the request to a partner utility, which in turn communicates with its suppliers. One willing supplier is found that delivers the document to the original requester. Forwarding by intermediaries could also enable hierarchies of ILL utilities to be established, in which regional utilities attempt to satisfy a request before passing the request on to a more general national utility or to other nearby regions. The requester specifies in the request whether partitioning is permitted (although obviously a request directed to a utility would have to permit partitioning), and can include a send-to list of potential responders. The request can also contain a list of responders that have already been unsuccessfully tried. 3.3 Scenario 3: Patron-Initiated ILL The bibliographic utilities provide not only locations, but very rich resources of bibliographic information. Much of their current effort is going into making these resources even richer by adding journal content citation databases, etc. In addition, the steady, relative lowering of the costs of both data processing and telecommunications make the more widespread provision of access to the utilities' databases increasingly feasible. A natural consequence of these trends is that library patrons should be given direct access to this resource. However, this causes an operational problem for libraries, and especially for the ILL office. When a patron discovers a relevant item he or she will want it, and will want to be able to order it easily, for example by pressing a button or issuing a command while connected to the utility's database, just as the ILL staff member does. The typical ILL office, however, is not set up to support this approach very well. Often the patron will have to write down or, in some environments, print the citation and take it to the ILL office. There, staff will do the usual processing of the request, which will often lead to their connecting to the utility, searching the item and issuing the request. But the patron has already done most of this; why ask the overworked ILL staff to do it all again? There are conflicting requirements here. The patron wishes to request supply of an item that is needed, and wishes to do this as effortlessly as possible. The library has an obligation to ensure both that use of local resources is maximized and that ILL is used as little and as cheaply as possible. The patron doesn't want to have to look in more than one place to find an item. The library will normally want to be sure that a requested item is not available locally before requesting it from a remote supplier. The patron does not normally care who supplies an item. The library does, because some sources are more expensive than others, or take longer to supply the item, or have more restrictive policies. The requirements to be met, therefore, are to: -allow the patron to request an item easily while searching the utility's databases, while at the same time -allow the library to retain control over the issuing and processing of the ILL request. There are two approaches to meeting this requirement, described in the sections that follow. 3.3.1 Scenario 3A: Library as Requester: OCLC Model Direct patron requesting while connected to a utility's (or other supplier's) database can be accommodated by a model in which the utility accepts the request from the patron and then communicates with the patron's home library to create a "normal" ILL transaction that the library controls and manages. In this model, the utility sends a message to the patron's home library saying, in effect, "We have been asked by your patron Jane Doe to get item ABC on ILL. Do you approve?". The library accepts or rejects the proposed ILL, using whatever procedures it determines are required. This might include checking the local catalogue for availability. The library might make other changes to the patron's request, such as specifying or changing a send-to list or indicating a cost limit. The library could process the request either through staff action, as in traditional ILL, or by automated means. This latter might include automatic lookup in the circulation database and the patron database to determine availability and what the patron's status and account balance are, etc. Diagram not available, please refer to hard copy Figure 5 - Direct Patron Requesting: Utility Manages Transaction This approach, illustrated in Figure 5, is currently being implemented by OCLC in its patron request system, although without use of the ILL protocol. The ILL protocol does not at present support this approach. The standard requires that all transactions must be initiated by the "requester", the recipient of the document. If the patron's home library is to be the formal requester, that is, is to assume responsibility for a loan initiated directly by the patron at a utility, then the home library must be able to record the fact of the transaction, and also to accept or refuse liability for the return of (or payment for) the item. Additional protocol services will have to be defined to support this requirement. The additional services required would be some form of an "ILL-Approve Request" service invoked by the utility (the intermediary) to propose creation of an ILL transaction and possibly an "ILL-Approve Answer" service invoked by the patron's library to accept or reject the proposed transaction. Alternatively an answer could be in the form of an ILL-Request message or Cancel message as appropriate. This approach has the advantage that it allows the utilities' existing terminal-based search and ILL requesting facilities to be used by patrons, and, depending on the level of automated support desired, relatively little additional development effort would be required to implement the additional ILL services as part of an ILL application in the library. 3.3.2 Scenario 3B: Library as Intermediary: FCLA Model An alternative approach is not to allow the patron to issue requests directly to the utility, but to create a local interface or gateway to remote searching that intercepts such requests and routes them to the home library's (manual or automated) ILL system. This allows the patron's library to minimize the use of the utilities' services, control the use of remote resources, maintain information on what has been requested to feed into selection and budgeting activities, etc. An approach similar to this has been proposed by the Florida Center for Library Automation (FCLA). In order to implement this approach satisfactorily, the local element of the search interface will have be largely transparent to the patron, so that the patron merely issues the command to request an item, and the system does the rest of the work. Where the patron is using the library's system to search the utility, development of such an interface is relatively straightforward, and the simple model of the library as requester as described in scenario 2 would still apply. Increasingly, however, the patron will not be using the library's system to search the utility, but will be using a search client application on a personal computer or workstation. This makes the design of the application significantly more complex, since the user's application will have to manage communication with both the search target and the patron's library. Using data from the search result, the desktop application will have to generate a request to send to the home library's ILL system. These requests could then be used to generate ILL protocol transactions in the library's ILL requesting system. There is no requirement that the messaging between the patron's system and the library's ILL system be protocol based. One possible implementation could be to use the Z39.50 Item Order service to communicate requests between the patron and his or her library. This is described further in section 4 below. A fully protocol-based approach would be to model the patron's system to act as the ILL requester, with the library's ILL system acting as the chaining intermediary to manage separate transactions for the patron request and the request sent to the utility. Using the protocol allows standard ILL messages to be exchanged between the patron's system and the library's ILL office. This offers the advantage that notification of difficulties in obtaining the item or messages during the course of a loan, such as a recall, can be passed to the patron, without the need for a separate messaging mechanism. Diagram not available, please refer to hard copy Figure 6 - Direct patron requesting: library manages transaction The ILL standard fully supports this approach as illustrated in Figure 6. With the ILL office as a chaining intermediary, all messages relating to the transaction are passed through the ILL office—there is no direct interaction between the patron and the library supplying the item. Depending on the policies of both the responding and the patron's home library (formally the intermediary), requested items might be delivered directly to the patron (for example, photocopies might be mailed directly to the patron). Otherwise they could be delivered via the ILL office (items on loan might be delivered only to the patron's library). In the ILL protocol a chaining intermediary does not take an active role in the tracking phase of a loan; it merely acts as a relay for messages such as overdue, renew, recall, etc. If the patron's library wishes to take an active part in managing loans, then it can use a different protocol mechanism to manage distinct ILL transactions, in which it has one transaction with the patron, and a separate ILL transaction with the utility. It would act as the ILL responder in the transaction with the patron and as the ILL requester in the transaction with the utility. This permits the library to take an active part in managing the loan, such as recording the loan in the local circulation system so that overdue notices can be issued, fines levied, etc. While the ILL standard supports both these models, implementing either of them may require substantial development effort on the part of libraries or their system vendors to create desktop requesting applications. These applications will have to search the utilities and, from records retrieved, create ILL messages to send to the local ILL office. Such systems will debar patrons who have only terminal access to the utility from using the ILL requesting facilities currently provided by the utilities; they would have to resort to printing a citation and taking it to the ILL office. These difficulties are such that this approach is likely to be feasible only in a client-server searching environment, such as that provided by use of the Z39.50 protocol. 3.4 Scenario 4: Document Supply Based on ILL with Circulation Knowledge The "traditional" types of ILL described above have assumed that the requester has no knowledge of the item's availability at the potential responder. Union catalogues have provided locations, but no information as to whether the item is immediately available from any particular responder. ILL departments have therefore relied on the experience and intuition of staff to determine the order in which locations should be tried when fulfilling any particular request. The protocol has a number of optional features that support this kind of requesting: forwarding, "send-to" lists, "already-tried" lists, etc. The connectivity explosion of the past several years, however, is beginning to make circulation information at individual libraries readily available through remote access to library catalogues. Clearly, patrons, as well as library staff, will increasingly wish to make use of circulation information in ILL requesting. The challenge for software vendors and system designers lies in integrating union catalogue access with circulation lookup and document requesting into a coherent system that satisfies the needs of both patrons and library management. In the longer term, applications will have to be developed that provide a single user interface for searching and document requesting. The scenarios below describe two possible models for creating such applications. 3.4.1 Scenario 4A: Requester Checks Status In this scenario, all activity relating to searching and requesting is controlled by the requester's system, whether that be the library or the patron. Local or remote catalogues, bibliographies and citation databases may be searched to discover and verify the details of required items; the utility's union catalog is searched for location information, as well as additional discovery and verification; individual library catalogues are searched for availability information. Figure 7 illustrates a version of this scenario in which the patron directly searches the utility's union catalogue, but ILL requests (with a list of locations) are sent to the local ILL office for processing. Diagram not available, please refer to hard copy Figure 7 - Requesting Library Checks Availability ILL requests are sent directly to the supplying library, which is chosen on the basis of knowing the availability of the item at all the potential responders. Normally only a single ILL request will be sent, since lending policy and availability is known at the time of making the request. Alternatively, ILL requests could be routed via a utility to allow the utility to provide value-added services, such as centralized billing. Even here, however, only a single sub-transaction will normally be created, since a positive response to the request is expected. It is assumed that the maintenance of a centralized database of circulation statuses is neither desirable nor technically feasible. The thrust of library systems is increasingly towards keeping this kind of transaction information local. Determining circulation status will therefore require searching individual circulation systems. They could be searched sequentially, in some order determined by the requester, or they could be searched simultaneously. The first approach would allow the requesting library (or ILL system vendor) to develop algorithms that minimize ILL costs by maximizing load balancing or by ensuring the cheapest and/or nearest sources were tried first. The second approach would permit the user to be shown a display of available copies from which he or she could choose freely. 4.2 Scenario 4B: Utility Checks Circulation Status This model retains the ILL function at the utility. There is considerable merit in maintaining a centralized ILL management system at an intermediary. Such a system could maintain load balancing information over the entire network, to ensure that any library's ILL load with the whole system is as evenly balanced as possible, irrespective of transactions with individual libraries. The utility could enhance this by adding ILL account management and invoicing as value-added services, so that individual ILL responders need only bill the utility and ILL requesters would only receive a single invoice for ILL services, from the utility, no matter where requests went. This model does, however, require the utility to carry out the circulation status checking required to make informed ILL decisions. This implies, further, that the utility will have to move from being a relatively passive recipient of messages in the communication network to actively initiating connections with member libraries in order to initiate and manage document requesting activities. The consequences of this for telecommunications management at the utility could be profound. It also requires that the utilities maintain large databases of ILL transaction information. The cost of meeting these two requirements may prove to be prohibitive for the utilities. Diagram not available, please refer to hard copy Figure 8 - ILL with Locations: Intermediary Manages TransactionsIn this model, illustrated in Figure 8, the user (again, either patron or ILL department) performs a search of the utility's union catalogue, and, having found an item of interest, indicates that it is to be the subject of an ILL request. This request is sent by the user's system to the home library, which performs another search, asking for availability for a given item. The utility performs Z39.50 searches at some or all of the locations for the item and displays the availability results for the user to create a send-to list. The utility then sends an ILL-request to the selected location. This request may be either an ILL protocol message sent via electronic mail, or since the Z39.50 connection is already open, an ILL protocol message transmitted using the item order extended service of Z39.50. Note that because this model implements services at the utility, relatively simple end-user systems can be supported. Access could be provided via Z39.50 client systems on workstations, but also via terminal access to the utility using the highly developed communications networks currently supported by the utilities. 3.5 Scenario 5: Reciprocal Borrowing This scenario represents the inverse of the document requesting process we have been considering previously. In the earlier scenarios the patron and the patron's home library ultimately decide between them whether or not an item is requested. In reciprocal borrowing the patron already has the required item in hand and the "foreign" library makes the decision to supply or not based on a direct request from the end user. A typical scenario for reciprocal borrowing might be as follows: The patron approaches the circulation desk in a "foreign" library with a book that he wants to borrow. The circulation clerk wands the patron's library card and the bar code in the book; the system says it will take a few moments to authorize the transaction. After a short delay (equivalent to the delay at a bank ATM) the transaction is approved, the book is checked out in the normal way and the patron leaves with it. When he is finished with the book, the patron may return it to his home library or to the foreign library he borrowed it from. There are two general strategies for implementing support for reciprocal borrowing in an automated environment, the "resource sharing" or ILL strategy, and the "patron sharing" strategy. Which is chosen by particular consortium depends to a large extent on the financial and contractual obligations that libraries enter into when establishing reciprocal borrowing. 3.5.1 Scenario 5A: Reciprocal Borrowing as Resource Sharing This can be modeled as patron-initiated ILL, although it demands that the messaging be done in real time and that the ILL application be integrated with both the circulation system at the "responder" and the patron system at the "requester". It also implies the use of some kind of "portable" library card or ticket that uniquely identifies the patron within the whole consortium and not just within his or her home library. Diagram not available, please refer to hard copy Figure 9 - Reciprocal Borrowing as Resource SharingModeling reciprocal borrowing as an ILL protocol transaction implies that the patron's home library accepts responsibility for the return of the item. The patron is answerable only to his or her home library, irrespective of where the loan was actually made. Fines and charges, therefore, will be levied by and will be paid to the home library. Exactly the same ILL services are used in this scenario as in scenario 3a. The difference is that now, rather than the patron initiating the request, the "responding" (i.e. foreign) library's circulation system is communicating with the "requesting" (i.e. home) library's ILL system to initiate an ILL transaction. Because of this, real-time responses will be required. The whole sequence of communication can be transparent to both the user and the circulation clerk. The sequence of services used in this scenario is shown in Figure 9. The attempt to charge out the item to a non-local patron will result in an ILL-Approve Request protocol message being sent to the patron's home library. This will be answered with an ILL-Approve Answer message, either positive or negative. If the answer is negative, the patron will be told that he or she cannot borrow the item. If the answer is positive, the item will be charged out in the library's circulation system, and an ILL Shipped message will be sent to the patron's home library to record the state of the transaction. Note that in the lending library's circulation system the item is recorded as being on loan to the requesting library, and not on loan to the patron. When the item is returned, the library checks the item in and sends an ILL Checked-in message to the patron's library to terminate the transaction. One benefit of this approach is that patron information is never distributed beyond the patron's home library; as far as the other consortium's members are concerned, all transactions are between libraries, as in traditional ILL. As discussed under scenario 3a, the ILL protocol does not at present fully support this model. Additional services will be required to allow the lending library to initiate an ILL request and to allow the patron's home library to respond appropriately. 3.5.2 Scenario 5B: Reciprocal Borrowing as Patron Sharing This model is radically different from any of the above. In this approach, any one library's patron is, in effect, a patron of all the consortium libraries. The patron is responsible for the return of the item to the library from which it was borrowed and not to the patron's home library. Here it is not physical items that are being shared amongst consortium members, but information about patrons. This is in fact fairly straightforward to implement using existing protocols, since only a search to obtain patron information is involved. The Z39.50 protocol can easily accommodate this kind of remote patron lookup, with transfer of a standardized patron record. It is important to note that the ILL protocol has no part to play in this scenario. Figure 10 illustrates the communications involved in the patron- sharing approach to reciprocal borrowing. It should be noted that the apparently identical communication activities are implemented by very different protocol messages and result in the transfer of very different data. Additional facilities may be required to inform the patron's home library of any delinquency on the part of the patron, and further facilities would be needed if the home library requires notification of every circulation transaction involving its patrons. If the latter is truly a requirement, the ILL model of reciprocal borrowing would seem to be more appropriate. Notification of delinquency could probably be most efficiently handled by mechanisms involving (automatic) generation of electronic mail messages to the home library, where they would be used to update the patron file with the delinquency information. The home library would not have to notify the patron of an item becoming overdue, etc., since this is handled by the foreign library. Diagram not available, please refer to hard copy Figure 10 - Reciprocal borrowing as Patron Sharing Since this model involves the exchange of personal information, there is a greater need for secure communications here than in any of the ILL-based scenarios. 3.6 Scenario 6: Commercial Document Supply Commercial document supply is not strictly a separate scenario. In any of the previous scenarios the responder may be a commercial document supplier rather than an ILL partner. This change could be largely invisible to the various requesting systems involved, assuming the commercial suppliers supported the ILL protocol for receiving requests. In cases where a utility is acting as an intermediary, even the ILL protocol need not be used between the utility and the supplier. Other protocols, such as the X12 Purchase Order, could be used for communication between utility and vendor irrespective of the protocols used between the requester and the utility. A common commercial arrangement at present is for a utility, such as OCLC, to act as a "retailer" for documents supplied by one or more "wholesalers". In this arrangement the requester (a patron or library) searches citation databases made available by the utility, and, when using a terminal connection, can invoke the "order" option for any item or items found. Some systems that provide documents from more than one supplier (for example OCLC) will respond by showing all the sources that supply the item and what the prices are and require the user to choose the preferred supplier. The retailer will obtain billing information, such as an individual user's credit card number, if necessary, and will send an order message, using a proprietary protocol or an EDI standard such as the X12 purchase order, to the supplier's system. The supplier normally sends a photocopy or fax of the item directly to the user. This corresponds very closely to the partitioned model of ILL, although there are a few significant differences. Most important is the requirement for the intermediary to respond to the request with a list of possible suppliers and costs. Although the ILL protocol supports the sending of a cost estimate in response to an ILL request, this answer terminates the transaction, which is not the case in the document supply scenario. An ILL conditional answer could be used, since this requires a response, and the pricing information could be included in a responder-specific-results parameter. The protocol's Conditional answer message, however, contains only the single Yes/No; there is no mechanism to include responder- specific information. Such a mechanism would have to be developed to enable the ILL protocol to support this approach. This would require an additional message type, or the addition of parameters to the ILL conditional answer. One approach could be to specify a new type of ILL-Answer, an "Options" answer. This would contain all the options and allow the user to choose one. Another option when using Z39.50 for search access would be to use a Z39.50 search to retrieve supplier information relating to a specific item (such as a search directed at the logical "Current Prices" database), and only issue the ILL-request (probably as a Z39.50 Item Order) once pricing information for the item has been received. This, however, requires close integration of the two protocols and careful user interface design in order to replicate the functionality of the current terminal-based systems. 4. Z39.50, ILL AND DOCUMENT DELIVERY Z39.50 is the United States National Standard for Information Retrieval (the international equivalent is ISO Search and Retrieve, ISO 10162 and 10163). The main aim of the standard is to support intersystem communication for performing searches of databases at a remote system, and for retrieving records found by a search. Although the standard was primarily developed to enable remote searching of library- oriented databases and retrieving bibliographic records, it has been specified in a sufficiently general way to allow it to be used for searching of other kinds of databases and for retrieval of other types of records. A record could, for instance, be a chapter of a book retrieved from a full-text database, or it could be an image of a journal article associated with citation information in a commercial vendor's document database. Use of Z39.50 for retrieval of records such as this may, in the future, go a long way to obviating a substantial proportion of the current use of ILL. For well into the next century, however, much of the information contained in bibliographic systems will consist of document descriptions that are not linked with the documents themselves, and which cannot therefore be used to retrieve documents within a Z39.50 association. Nevertheless, an inevitable consequence of the use of Z39.50 to discover the existence and location of documents is a desire to be able to conveniently issue requests for supply of the document. This requires some means of using citations retrieved from a Z39.50 search to generate ILL requests and possibly other forms of document order, such as X12 purchase orders. It had been assumed by the designers of Z39.50 and ILL that this would be accomplished, in OSI terms, by developing applications that use multiple communications protocols concurrently to provide the services required by the user. A searching and ordering application might, for instance use both the Z39.50 protocol and the ILL protocol to communicate as required with searching and interlending partners. More complex applications could be constructed using additional protocol building blocks. For instance, document delivery could be integrated into the application by adding support for a file transfer protocol to allow the required documents to be delivered electronically. However, most North American implementers of Z39.50 have not created fully OSI-compliant applications, but have implemented the protocol directly over a TCP transport layer. This is an architecture in which it is awkward to support multiple protocols sharing a single communications channel, and in which it is impossible to negotiate at connection time the set of protocols to be used over any given connection. In addition, many implementers are reluctant to commit to implementing what they see as excessively complex protocols in order to achieve relatively simple goals such as issuing a request for a document. To accommodate these implementers, the Z39.50 Implementers Group (ZIG) agreed to the use of the Extended Service mechanism to support simple document requesting. The Z39.50 Extended Services facility provides a protocol mechanism whereby target systems can offer services that have an inherent lifetime that is longer than or not related to the life of the Z39.50 session in which the service is requested. Typically these will be services performed in batch mode at the target, such as off-line printing, or services that have a continuing life, such as the maintenance of a saved result set or the periodic execution of a query. Since document requesting is a functionality that many commercial database providers support, an Item Order extended service has been specified in the 1995 version of the Z39.50 standard. The initial thrust came from implementers who already provided document requesting features in their proprietary interfaces and wished to continue to offer this service in their Z39.50-based client-server products. These proprietary requesting services provide little beyond facilities to request an item already identified through a search and to provide credit card payment information. The Z39.50 document request facility was originally seen as providing the same level of functionality. The library community was concerned, however, that a document ordering extended service should be able to support their requirements for both ILL requesting and commercial document ordering. It was therefore agreed at a joint meeting of the North American ILL and Document Delivery Implementers Group (NAILLD) and the Z39.50 Implementers Group (ZIG), held in Gainsville, Florida, in January 1994, that Item Order would allow the use of the contents of the ISO ILL-Request message. The Z39.50 - 1995 standard describes a mechanism for supported extended services and specifies, amongst others, an Item Order extended service that allows an origin system to submit an order request to the target and subsequently search the extended services database to discover information about the status of the order. The request can identify the item either by reference to a record position within a result set (e.g. record 5 within the result set named "my-result-set") or by supplying a complete ILL Request message. It also provides for the transfer of additional information relating to the order, such as contact information, as well as billing information, such as a credit card number. The status information that is available from the target may be based on the ILL Status-Or-Error-Report specified in the ILL protocol. The Z39.50 Item Order extended service can therefore be seen as providing a separate and alternative protocol mechanism for supporting a limited subset of the ILL services (ILL-Request and Status-Or-Error- Report). Requester and responder systems can be designed which would use either protocol or both as appropriate. Figure 11 illustrates some of the breadth of interoperability that could be achieved in environments in which such dual stack systems have been implemented. The primary use of this extended service in the short term is expected to be to provide journal article ordering facilities to individual searchers of the remote host. Payment will primarily be via credit card. It is, however, quite feasible to develop fully conformant ILL systems that use the Z39.50 Item Order extended service to transfer the initiating ILL-Request message and then use other protocol mechanisms for exchanging any subsequent messages. Diagram not available, please refer to hard copy Figure 11 - Combined use of ILL and Z39.50 Item OrderThe service could well prove useful to libraries, in particular for receiving and managing requests from patrons. The Z39.50 Item Order service could be used in the FCLA model (section 3.3.2) to receive requests from users that subsequently generate transactions in the library's ILL system. This would allow the library to implement relatively simple end- user workstation tools for searching. Libraries could also use Item Order as part of combined search and request applications; any subsequent messaging required would use the ILL protocol. 5. RECOMMENDATIONS AND CONCLUSIONS As remote searching becomes more widespread through the use of Z39.50, libraries will come under increasing pressure to support patron-initiated requesting. For most patrons the state information required to be kept by fully conformant ILL systems is largely irrelevant. For these users, the Z39.50 Item Order service is an appropriate mechanism for initiating requests, whether these requests end up as protocol- based ILL requests passed between libraries, or as orders for processing by a commercial document request system. Libraries, however, are likely to have a continuing need for formal interlibrary loan arrangements. In fact, the combination of constantly diminishing resources and constantly improving remote access is likely to lead to substantially heavier use of interlibrary loan and a consequent need for improved systems to support interlending. Many North American ILL professionals, however, do not currently perceive that there are benefits to be gained from implementing standards-based communications protocols for inter-system ILL communication. The proprietary ILL services offered by the bibliographic utilities, and particularly by OCLC, appear to meet the current needs for integrated location discovery and request generation. While these services will meet short term needs, they do not adequately address the increasingly burdensome requirements for local record keeping, nor do they offer much scope for integration of request generation with the local catalogue system or integration of request answering with the local circulation system. Additionally, the current generation of utilities' proprietary ILL systems only supports the processing phase of an ILL transaction, leaving support of the tracking phase to out-of-band communication using voice or person-to-person electronic mail. The scenarios presented above demonstrate that the ILL protocol can be used to support the vast majority of document requesting scenarios. Several areas of weakness were identified, however. The principal omissions at present are facilities for: -Responder initiated transactions; -Presenting options to the requester. The international standards community should consider addressing these areas of weakness in order to enhance the functionality supported by the protocol. If, however, the user community, and particularly vendors of library systems, remain reluctant to implement the protocol, the standards developers may need to reconsider whether a continued large investment in the protocol is cost-effective in the light of continuing pressure on resources. Unfortunately, there is not an immediately apparent alternative approach that could be adopted instead. Although the Z39.50 Item Order Extended Service has attractions for implementing patron based requesting, it does not form a basis for supporting the full range of ILL transactions needed by the vast majority of libraries. Since the principal consumers of the international resource sharing activities are and will continue to be libraries, the aim must be to foster solutions that enable the whole of the problem to be addressed. One approach might be to encourage the development of a lightweight ILL profile that will enable vendors to implement ILL requesting that conforms to the protocol, but does not require the complexity involved in implementing the full protocol. One use of such a profile could be to specify the ILL data elements to be transferred to an ILL utility as part of a Z39.50 Item Order. Other parts of the protocol would be for use directly between libraries once the utility has fulfilled its role of locating a supplier. In addition, the community should initiate one or more pilot projects with a view to determining the most effective means of integrating document requesting with document delivery in the rapidly evolving Internet environment. Such a pilot project should explore the merits of and mechanisms for integrating ILL requesting and electronic delivery of documents using electronic mail as the preferred delivery vehicle. REFERENCES ANSI Z39.50- 1995: Information Retrieval Service and Protocol. American National Standard Information Retrieval Application Service Definition and Protocol Specification for Open Systems Interconnection ISO 10160: 1993 Information and Documentation - Open Systems Interconnection (OSI) - Interlibrary Loan Application Service Definition ISO 10161: 1993 Information and Documentation - Open Systems Interconnection (OSI) - Interlibrary Loan Application Protocol Specification ISO 10162: 1993 Information and Documentation - Open Systems Interconnection (OSI) - Search and Retrieve Service Definition ISO 10163: 1993 Information and Documentation - Open Systems Interconnection (OSI) - Search and Retrieve Protocol Specification To order a copy of this report: IFLA International Office for UDT, c/o National Library of Canada 395 Wellington Street, Ottawa, Canada, K1A 0N4 Fax: (819)994-6835 E-Mail: ifla@nlc-bnc.ca