OSI for Libraries: Standards to Services (1992)

6. BRIDGING THE TECHNOLOGIES

6.1 TCP/IP vs. OSI is it an issue?

This is especially true in the bibliographic community where:

• libraries are in the business of providing a variety of services. Clients, both individuals as well as other libraries, must continue to be served, even though they may not be ready to adopt the same computer communication standards as the library providing the service.

• libraries already use a variety of communication modes including postal services, public electronic mail networks, proprietary networks, academic research networks or leased lines. A library may use one or several of these modes using procedures which have been refined over the years and is therefore reluctant to make the move to new technologies.

• vendors of library systems are reluctant to implement OSI application level protocols because of the major changes that are likely to be required to their software products. Bibliographic applications are quite complex and any changes would require considerable investment.

For a number of years there was a consensus that, ultimately, networking based on OSI standards would supersede TCP/IP. This would be primarily the results of government policy, through GOSIP (Government Open Systems Interconnection Profiles), and also because of the greater functionality offered by the OSI applications such as X.400, FTAM, and Virtual Terminal.

It is no longer certain, however, that this will necessarily be the case. Since 1990 there has been a very rapid growth in the size of the TCP/IP Internet. In particular, the use of TCP/IP for wide area networking is now almost universal in the North American academic community, and has increasing presence in the European academic community (Quarterman, 1990). This is significant because it means that most of the active research into networking and interoperability issues is being carried out in a TCP/IP environment. Additionally, the U.S National Research and Education Network (NREN), the planned, high capacity network of the latter 1990's, is almost certain to be based on TCP/IP, at least initially.

The likely continued existence of two mutually incompatible networking architectures is therefore an issue which library administrators and planners must be aware of and which system designers and implementors must be prepared to accommodate.

6.2 Bridging Mechanisms

There are, fortunately, several mechanisms whereby OSI protocols such as ILL, SR, X.400 and X.500 can be implemented with the TCP/IP suite of protocols. One way of achieving this involves the use of OSI standards for the upper three layers (i.e. Session, Presentation, and Application) in conjunction with ISO Transport protocol class 0 and TCP/IP protocols for the lower layers. This "transport bridge" approach would allow various systems that incorporate OSI applications such as ILL and SR to interoperate with each other over a TCP/IP network; it will not permit interworking of OSI applications with TCP/IP applications. However, only a single network infrastructure would be needed to support both TCP/IP and OSI applications.

Another method, less satisfactory but easier to implement, has been adopted for the first generation of Z39.50 implementations. This is to transfer Z39.50 messages directly over TCP and ignore the OSI presentation, session and transport layers altogether. The principal disadvantage of this is the loss of the negotiating capability offered by OSI. OSI enables systems to negotiate at the beginning of a session what application services are going to be used, what record formats and encodings will be transferred. When Z39.50 messages are transferred directly over TCP, none of this negotiating capability is available, and communicating parties must know by prior bilateral agreement what the exact parameters of the communication will be.

The same kind of difficulty does not exist for ILL. Because the ILL standard has been designed to be independent of the protocol layers below it, ILL messages can be sent over OSI, TCP/IP or proprietary communication networks. This flexibility does not limit the ILL protocol to one type of communications environment. Nevertheless, libraries that wish to engage in ILL exchanges must have at least one communication network in common.

Another bridging mechanism is a gateway. If a library or system vendor is unwilling to change a system, such as a union catalogue database, because of the complexity of such an undertaking and the cost, an application gateway can be placed between the system and the OSI application. The gateway would receive OSI messages, translate them to the format used by the non-OSI system, receive its replies and reformat them to generate OSI messages. Although this solution leaves the local system unchanged, it does introduce a complex processing level that may degrade response time and require additional processing power.

Gateways are already available that permit non-X.400 electronic mail systems to interoperate with X.400 systems. Specifications for developing X.400 gateways have been defined and help to ensure the gateways of different manufacturers will be able to interoperate not only with X.400 but with other gateways mounted on electronic mail applications.

Another possible approach is the dual-stack application. This is already being adopted by at least one implementor of the Z39.50 protocol (the University of Florida Center for Library Automation) which has a contractual commitment to develop an OSI application, and also wishes to implement a TCP application to allow communication with other implementors. Such an approach will allow the single system to communicate with partners that use either protocol suite. With a relatively small amount of additional development, such a system could also act as an application relay, which receives messages from a partner that uses one suite, e.g. TCP, and forwards them to the ultimate recipient that uses an incompatible suite (e.g. OSI).

In the area of interlibrary loan, a transition period will exist in which libraries will continue to use a variety of technologies including terminals, computers, and protocol-based systems to generate ILL messages. During this period, libraries using ILL protocol-based systems will be less concerned with the communication networks used to transmit ILL messages than with the format the messages are received in. Libraries that have acquired protocol-based systems will wish to receive all messages in the protocol format so that these messages, regardless of sender or originating system, can be managed and processed in the same manner, i.e. through the ILL system. However, other libraries will continue to use a variety of systems to send ILL messages that do not conform to the ILL protocol.

One way of streamlining operations is for the receiving ILL protocol-based system to reformat all incoming messages to conform to the protocol format. This is only possible if the incoming message has an identifiable structure that can be parsed and converted to resemble a protocol message. This implies that each protocol-based ILL system must have customized programs to convert the different message formats used by sending libraries.

Another possibility is to provide libraries that do not have protocol-based systems with a facility or mechanism to format ILL messages in the requisite protocol format which can then be sent to protocol sites.

To facilitate this type of communication between protocol and non-protocol sites, the National Library of Canada developed a set of standard electronic mail messages that conform to the ILL protocol message formats (Turner, 1990a). These messages are created on a terminal by ILL staff responding interactively with a prompting routine known as an electronic script. This script is accessible on a widely used Canadian public electronic mail system ENVOY 100. The user responds to a set of prompts presented by the ENVOY 100 script, e.g. library identification, address, author of requested item, title of item and date of publication. The script then automatically reformats the user's input, adds the protocol transfer syntax encoding and delivers the ILL message to the recipient's ENVOY 100 electronic mailbox. The protocol-based system retrieves the message from the mailbox and performs some minor reformatting. The message can then be processed as if it had been sent by another protocol-based system. However, because the message originator is not a protocol site but only a script user, the originator's control and recording of transaction steps and the tracking of the requested item must still be handled manually.

For libraries that do not wish to work interactively with the script and incur the associated telecommunication charges, the National Library of Canada has prepared documentation to enable libraries to format the messages off-line using a personal computer. Again, it is important to note that local message preparation by a non-protocol ILL system does not have the same capabilities of a protocol-based ILL system. However, script-based messaging and local message preparation permit the co-existence of and limited networking among protocol and non-protocol sites. This again illustrates ways of accommodating the different technical capabilities of the library community.

6.3 Implications for Libraries

However, as libraries look to the applications they wish to run on these networks, the OSI suite provides a richer set of bibliographic as well as generic functions such as X.400, FTAM and X.500. The choice of telecommunication service and thus protocol suite, should, as far as possible, be based on how the library's required applications can be supported using the protocols and products currently available.

OSI applications running on TCP/IP lower layers will most likely be the solution for bibliographic communications. In the absence of an OSI telecommunications backbone, TCP/IP will furnish the communications path for OSI applications such as ILL and SR. This hybrid solution will also serve to promote the use of OSI bibliographic protocols by libraries.

The greatest danger is that libraries will be forced to use different networking systems to communicate with different partners: OSI to communicate with commercial suppliers such as booksellers; TCP/IP to communicate with other libraries, bibliographic utilities, etc.

In reality, however, the question of which protocol suite should be used for library applications becomes moot: the issue will largely be decided for libraries. A library does not operate in a closed environment, and few will have the luxury of being able to choose a networking approach on the basis of technical merit alone. In the vast majority of cases the choice will be made for libraries, either by their funding body or sponsoring agency, by the vendor of their automation system or by other partners that they wish to communicate with such as bibliographic utilities, commercial suppliers, or ILL consortia.