International Coalition of Library Consortia (ICOLC)

Guidelines for Technical Issues in Request for Proposal (RFP) requirements and Contract Negotiations

(January 1999)

INTRODUCTION

The licensing and use of electronic information resources continues to expand and, in some cases, become the sole or dominant means of access to particular resources. As such the reliability and performance of vendor hardware/software platforms through which many of these resources are accessed is of critical importance.

The participating consortia of the ICOLC have a responsibility to their library members to ensure that vendor platforms are robust and reliable; that they are connected to the Internet with adequate capacity to serve their customers; that they are technically compatible with the primary commercial web browsers; that they are ADA compliant; and that they are making adequate preparations toward Y2K compliance.

This document addresses the nature of the vendor’s content and accessibility and the issues of service, quality, and response time. Based on problems identified during negotiations with the vendor before a contract is executed a variety of actions may be required, including system mirroring and the addition of network or system capacity. These actions may be specified as part of the contract. The contract may include commitments by the vendor should future problems arise.

The issues raised are complex and their treatment in vendors’ systems is evolving rapidly. By design this document does not attempt to deal with them in technical detail nor in many cases in a prescriptive manner. There are a variety of options that will be preferred by consortia. It is the challenge to each vendor to negotiate the specific solutions with each consortium within the vendor’s own range of capabilities.

I. Content Formats

In the past many vendors provided ASCII text, the most straightforward electronic file format available. However, the rapid acceptance of the World Wide Web as the distribution channel of choice for electronic information and the proliferation of full text or full content information services have given rise to the use by content vendors of a variety of electronic file formats and new kinds of information delivery systems. Some vendors scan pages of text and deliver them as image files; others key text into databases, store the data in ASCII then apply HTML dynamically for the WWW; still other vendors create postscript files and deliver them in PDF. So, as vendors begin delivering not just screens or streams of ASCII to the users’ desktop but external applications and new file formats it becomes increasingly important to discuss a variety of technical issues related to "content" during the contract negotiation.

Following are content format issues that should be discussed with the vendor:

A. Use of plug-ins and embedded applications. The use of Java, Javacript, and plug-ins can limit the accessibility of the vendor site to particular browsers. External Java or Javascript applications are software programs that execute on the end-user’s desktop system. This means that the user’s system resources (memory, processor speed) may not be adequate to use a vendor’s service. Plug-ins (such as Acrobat) place the burden of installing additional software on the end-user. Poorly engineered Java applets and little used plug-ins quickly translate into a support issue for libraries. Freely available plug-ins(e.g., Acrobat Reader) or non-freely available plug-ins provided by the vendor is the preferred practice. Any plans for or restrictions that need to be placed on the use of Java, Javascript, and plug-ins need to be negotiated with the vendor.

    1. Support for Netscape and Microsoft Internet Explorer (MSIE). The vendor should guarantee that the site is accessible to Netscape and MSIE. The vendor should specify the versions of Netscape and MSIE supported by their systems. Any long-term contract should specify how compatibility with browser technology will evolve.
    2. Use of standard HTML. The contract should specify a version of HTML with which the vendor’s system complies. Long-term contracts should specify how compatibility with future versions of HTML will evolve. The current version of the HTML specification is 4.0.

D. ADA (Americans with Disabilities Act). Federal law requires that most services be accessible to the disabled.

The majority of screen-reading software or other types of software used by the disabled to access Internet sites rely on non-graphical interfaces. There is software available to support access to sites with graphical interfaces, but it does not yet seem to be sufficiently widespread for consortia to expect it will be owned by a large portion of disabled users.

To provide ADA compliance, the vendor may seek to provide a text interface available through telnet. However, this is probably a legacy interface that the vendor or library may not be planning to continue or enhance. For this reason, accessibility via text-based browsers should be developed in accordance with ADA standards and with World Wide Web Consortium (W3C) guidelines.
    1. Capturing Content. Users should be able to capture contents in one or more ways including printing, emailing, and downloading, as appropriate to the type of information and in ways that are acceptable regarding use of browsers or additional software. Content should be printed without the need of special printing software. If special printing software is needed it should be compatible with your user environment and is easy and affordable to get.
    2. Use of embedded multimedia (images, sounds, movies) files. Unless multimedia files are integral to the product the vendor should use them sparingly. The use of numerous non-essential multimedia files can place a burden on the vendors own system if it has not been properly engineered to store and deliver such files. The use of numerous non-essential multimedia files will tax the end-users system. Many vendors provide "high bandwidth" and "low bandwidth (text only) sites as options.

II. Platforms

There are many issues involving the hardware, software and network technology used by the vendors to store and deliver content. How the system is designed (architecture), its capacity to serve users, how the system is maintained, how access to the system is controlled, and how well the system responds to requests for information are all issues of critical importance during contract negotiations.

The following are platform issues that should be discussed with the vendor:

    1. System Architecture.
    1. Z39.50 Interface. Z39.50 should be required if this protocol is used by a consortium to provide integrated access to multiple vendor systems with bibliographic content. Restrictions, such as record syntax, services, and attribute sets to be used by the vendor, should be specified in an RFP or contract.
    2. HTTP. The contract should specify the version of HTTP with which their system complies. Long-term contracts should specify how compatibility with future versions of HTTP will evolve. The current version of the HTTP standard is 1.1.
    3. Stateful vs. Stateless Interfaces. Either of these two conditions may be appropriate depending on how the vendor has designed its system and on the need to maintain and track an individual user’s session. Vendor web sites can be set up to maintain either stateless or stateful connections. Where the vendor’s system maintains a stateful connection between clients and servers the following are issues to be addressed during contract negotiations:
    1. The timing out of users. An adequate time should be negotiated with the vendor.
    2. Because in a stateful system it may be difficult for a user through a browser bookmark to monitor changes in content, for example, a new table of contents or article of an electronic journal, the vendor should provide a mechanism to alert users to newcontents.
    1. Mechanism for direct access to contents. Many vendor systems are made up of multiple databases consisting of various content types (bibliographic information, complete articles, complete journals, images, etc.). Libraries construct pointers from local web sites to these various contents. This requires vendors to construct their systems so as to allow for the use of fixed URLs that point to specific content in the vendor’s system or the vendor needs to supply to the consortium the means for building a script that will take users directly to the particular database..
    2. Year 2000 Compliance. The vendor should be required to certify that its system is compliant for resources that are considered critical.
    1. Access Control. All vendors do not handle access control in the same way. The consortium should state its desired approach to controlling access to electronic information being served from vendor-hosted platforms. IP authorization and user authorization (login and password) are the two most common methods of identifying valid users on a system at this time.
    2. Security/Privacy.
    1. If the vendor system allows the user to purchase information or services it will be essential to determine whether the vendor provides adequate security. Even if the vendor is providing access control through a login and password protected account this does not in any way protect the information (such as credit card numbers, account numbers, passwords) being transmitted. Some form of encryption will be necessary for transactions that involve the end-user sending sensitive information through a web browser to a web server. Inquire as to the vendor’s use of Secure Sockets Layer (SSL) and SHTTP (secure hypertext transfer protocol).
    2. Cookie Tracking. As part of the non-technical portion of the contract there may be the need to limit the ability of the vendor to distribute data on the use of their site. In addition, it is important to be aware of the use of advertising on vendor sites where an ad will cause its own cookie to be loaded on the user’s hard drive. This represents its own risk to privacy by enabling an external application to write to a file on the user’s hard drive that information is available to other web sites.
    3. The confidentiality of individual user data is addressed in the previously issued "Guidelines for Statistical Measures of Usage of Web-based Indexed, Abstracted, and Full Text Resources", found also at www.library.yale.edu/consortia.
    1. System Management. The following issues should be raised in an effort to determine an overall picture of system availability under normal conditions and during periods of unexpected service denial or interruption.
    1. Vendor should provide advance notification (in the contract if possible) of all scheduled downtime. Vendor should provide immediate notification of all unplanned downtime.
    2. Service Response. The vendor should guarantee response time to service calls, e.g. 1 day.
    3. System Monitoring. The vendor should provide 24 hour system monitoring. This insures that the smallest increment of time will elapse between an unplanned service disruption and the vendor’s awareness of the problem.
    4. Statistical Reporting. The vendor should be required to provide statistics on the use of the system. This is addressed in the previously issued "Guidelines for Statistical Measures of Usage of Web-based Indexed, Abstracted, and Full Text Resources", found also at www.library.yale.edu/consortia.
    5. Technical Support Contacts. The vendor should be required to provide a technical support contact in addition to sales contacts and administrative contacts. The contract should specify the contact information such as an email address, phone number, fax number and hours of availability.
    6. Notices of Changes in System Design -- The vendor should guarantee at least three months notice of any changes in the design of their system that would require changes by the consortium members to access the site such as the versions of web browsers and URL linking.
    1. Response Time.

1. Prior to discussions about response time the vendor and the consortium should consider the following conditions that affect the process of determining the probable performance of the vendor’s system.

a) Local library bandwidth and its level of utilization. Before evaluating the adequacy of the network capacity of the vendor, it is essential to be familiar with the adequacy of local network capacity. What may be perceived as poor performance of the vendor’s system may in fact be problems that can be traced to situations such as insufficient network capacity, poor network design, local hardware problems.
    1. Nature of your user activity. Designing a performance measure requires prior determination of the type of use of a system that will occur, including:
    1. The number of simultaneous users.
    2. The number of simultaneous users who will be searching, viewing, or printing at a given time.
    3. The mix of queries to be used (e.g. number of single term versus

Boolean searches, number of natural language queries).
    1. Network distance from the consortium to the vendor. Through the use of network utilities like traceroute, it is possible to determine the path through the Internet from the consortium to the vendor. While a vendor can always buy more network capacity from their ISP (Internet Service Provider) they can do nothing about the number of networks your traffic passes through on its way to their site. It may be these intermediary networks that cause problems with performance rather than the vendor’s own network, or the network of the local consortium.

2. The system’s performance will need to be measured against a standard for adequate performance. This standard is not likely to be a single time. It should describe the response time expected at peak and off-peak time and the different responses expected at those times for both complex and simple queries, or for retrieval of information items, e.g. journal articles. These times should be represented by a vendor as average response times. An acceptable standard for response times should be negotiated with the vendor.

The following issues should be discussed with a vendor to clarify the response time that should be expected from a system. Appropriate standards and ongoing reporting for uptime and response times can be negotiated for inclusion in a contract. When appropriate consistency in reporting time periods with the requirements set forth in "Guidelines for Statistical Measures of Usage of Web-based Indexed, Abstracted, and Full Text Resources" is recommended.
    1. Uptime and failure during the previous year. The vendor should describe the uptime of the system for the previous year, or for the time since the system has become operational if less than a year. How often has the system failed during this time and what is the duration of the average and the longest system failure.
    2. Percentage of network capacity used. The vendor should describe the percentage of their network capacity being used to provide service to their current customer base.
    3. Performance during peak loads. The vendor should be asked to identify how fast their system has performed during peak loads.
    4. Target response times for a system. The vendor should be asked to identify how fast they want their system to perform during peak loads.

Adopters of This Statement

This statement was adopted in principle by member representatives of the "International Coalition of Library Consortia" (ICOLC) whose institutions are listed below. This statement does not necessarily represent the official v iews of each consortium listed. All consortia listed are in the United States unless otherwise noted.

Consortia whose member representatives adopted this statement:


AMIGOS Bibliographic Council, Inc.
Arizona Universities Library Consortium (AULC)
BCR
Big 12 Plus
British Columbia Electronic Library Network (Canada)
California Digital Library (CDL)
The California State University
Chesapeake Information Research Library Alliance (CIRLA)
China Academic Library & Information System
The Colorado Alliance of Research Libraries
Committee for Institutional Cooperation (CIC)
Commonwealth Virtual Library
Council of Australian University Librarians(CAUL)
Council of Library Directors of the University System of Maryland
Council of Prairie and Pacific University Libraries (COPPUL) (Canada)
Florida Center for Library Automation
Hellenic Academic Libraries Link (Greece)
GALILEO
Illinois Cooperative Collection Management Program (ICCMP)
Illinois Library Computer Systems Organization (ILCSO)
INCOLSA
Israel Center for Digital Information Services
Louisiana Library Network
MERLIN
MIRACL
Missouri Library Network Corporation
MOREnet
Northeast Research Libraries Consortium(NERL)
Network of Alabama Academic Libraries(NAAL)
New England Law Library Consortium (NELLCO)
New York Consortium of Consortia(NY C of C)
Novanet
NYCRL
OhioLINK
Orbis
PALINET
Pennsylvania Academic Library Consortium, Inc. (PALCI)
PORTALS
SCELC - Southern California Electronic Library Consortium
TexShare
The Triangle Research Libraries Network (TRLN)
University of Texas System Digital Library
Utah Academic Library Consortium
VIVA (The Virtual Library of Virginia)
Washington Research Library Consortium
About the International Coalition of Library Consortia (ICOLC)

The International Coalition of Library Consortia (ICOLC) first met as the "Consortium of Consortia" (COC) in 1996. The Coalition is an international, informal group currently comprising over 100 library consortia in North America, Europe, Australia, Israel, China, and South Africa. The coalition membership serve primarily higher education institutions by facilitating discussion among consortia on issues of common interest. The ICOLC conducts meetings throughout the year dedicated to keeping its members informed about new electronic information resources, pricing practices of electronic providers and vendors, and other issues of importance to consortia directors and governing boards. The Coalition also meets with the information provider community, creating a forum for discussion about product offerings and issues of mutual concern.
More information about ICOLC can be found at http://www.library.yale.edu/consortia.
For further information about this document, please contact: