California Digital Library
Technical Requirements for Database Vendors

June 5, 2001

Latest revision: April 21, 2007

Overview
1.	Fail-safe operations
2.	Information Security
3.	Terminology
4.	Expectations for problem resolution
5.	Usage load
6.	Data integrity
7.	Perpetual access
8.	Preservation responsibility
9.	Access authentication
10.	Access mechanisms
11.	Presentation of data
Watermarking
Quality of digitized materials
Campus branding
12.	Documentation
For end users
For CDL staff
13.	Statistics
14.	Linking to content
Linking to articles
Linking to CDL’s Request service
Linking to UC’s Melvyl Catalog holdings
15.	URL verification
16.	Use of content
17.	Privacy
18.	Downloading into citation management software
19.	Notification of changes to the resource
20.	Compliance with the Americans with Disabilities Act (ADA)
21.	Special Accounts for training and for development/Troubleshooting:
Training account
Development/troubleshooting account
22.	Accommodation for Metasearch: Federation and Aggregation
Federation
Aggregation
23.	Current awareness feature
24.	User self-registration
25.	Online help
Appendix I: Authentication
The future of authentication at UC
UC's Preferred Solution for Authentication
Shibboleth: Benefits to Vendors
Appendix II: Platform Support
Appendix III: Use of the OpenURL standard
OpenURL: UC's preferred solution
OpenURL: Format
UC Requirements
Appendix IV: Downloading and citation management software
The citation management software problem
Z39.80: UC's Preferred Solution
Z39.80: Benefits for Vendors
Appendix V: Online help
Appendix VI: Current awareness services
Specific CDL Requirements for current awareness services
Appendix VII: User self-registration

Overview
When selecting vendors for Abstracting and Indexing databases, CDL aims not only to maintain existing standards for access and service, but also to improve, whenever possible, on existing arrangements.  Moreover, by choosing our technologies and vendor relationships carefully now, we hope to lay the groundwork for future improvements. To that end, the following document sums up the major technical issues of our decision-making process, and offers vendors insight into our preferred solutions, why they're important to UC, and what their implications are for prospective vendors.
Preferred vendors will provide the CDL opportunities for input on development priorities.  CDL sets a high standard for vendors that ultimately benefits all academic customers and leads to more competitive products for the publisher or vendor.  CDL is willing to work closely in the development and implementation of new features and functionality for existing products as well as co-development on new, cutting edge products that fit CDL’s own strategic plans.  These opportunities could take place via a users group, focus groups, working with the vendor’s director of development, or discussions with the development planning team.  
1.	Fail-safe operations 
Delivery mechanisms must be fail-safe operations.
•	Resources must be mounted on stable sites; one way to accomplish this would be redundant installations with access via more than a single network path. 
•	Resources should be served by high-speed machines on networks with large bandwidths.
•	Resources should be accessible from Internet2-connected sites 24 hours a day, 7 days a week, with 99.9% reliability.  
•	Vendors should notify CDL of any unexpected outages via email to the CDL Support team list or by phoning the CDL Helpline at (510) 987-0555 as soon as possible after the outage occurs. 
•	Scheduled downtime should not occur during “prime time” hours for our users.  Prime time for the University of California is 8am to 11pm (Pacific time) Monday through Friday, and noon to 11pm (Pacific time) on Sunday.
•	Notification must be provided to the CDL Support team list preferably one week in advance of (and at a minimum 2 working days before) scheduled downtimes. Placing a notice of scheduled maintenance on the product home page is not sufficient; we require proactive notification of anticipated downtime.
•	Vendors should provide a system status page that is hosted on a server not used to provide access to content.  See the OCLC Support home page “System Alerts” page for an example.  The vendor system status page should report both planned and unexpected outages.  
Please state strategies employed for providing such fail-safe operations. Also, please provide statistics for the last two years showing the downtime for the resource, including the frequency and duration of both scheduled and unscheduled outages, indicating averages and worst-case statistics.
URLs and links cited:
CDL Support team list email address: cdlsupport-l@ucop.edu
Sample vendor status page: http://www.oclc.org/support/default.htm
2.	
Information Security
Vendors should provide and maintain licensed data and any personal data collected from end users in a secure manner. These security provisions must meet or exceed the guidelines that the University of California (UC) requires for the UC computing environment, as set forth in the “UCOP Business and Finance Bulletin: IS-3: Electronic Information Security”. Please provide an overview of your data security measures, including information on the security of data, communications security, and any measures employed to handle Intrusive Computer Software.
Please provide a copy of your end user privacy policy. 
URLs cited:
UCOP Business and Finance Bulletin: IS-3: Electronic Information Security 
http://www.ucop.edu/ucophome/policies/bfb/is3.pdf
3.	Terminology
Vendor proposals should also include clear definitions of key technical terms used, e.g., concepts such as “session” or “simultaneous use.”
4.	Expectations for problem resolution
Access problems reported to the vendor by the CDL or UC campus staff 
Access problems should be resolved as soon as possible. The vendor must clearly indicate the mechanism for resolving problems that occur outside normal business hours.  If problems, such as problems with access, become complex and /or difficult to resolve, the vendor will keep the CDL apprised daily of possible solutions and a timeline for resolution of the problems.  
Access problems reported by the vendor to CDL
CDL has established procedures for immediate investigation of access or downloading violations.  Campus and CDL technical staff will work with the vendor to identify source, remedy any problem, educate campus users, and document activities. 
The vendor should immediately report any suspected irregularity to CDL’s License Manager, Curtis Lavery (curtis.lavery@ucop.edu or 510-987-9262) and to CDL’s technical contact, Margery Tibbetts (margery.tibbetts@ucop.edu or 510-987-0581). In the event that these staff members are unavailable, please contact the CDL Helpline (510-987-0555). 
5.	Usage load 
Systems must be capable of handling typical UC usage.  If possible, UC will provide average user statistics for the same or comparable database.
6.	Data integrity 
Data should be as accurate and up to date as possible and appropriate for the resource.
•	Currency: Abstracting and indexing databases should be updated within a week of receiving the new data from the provider. 
•	Completeness: Indexing should adhere to documented editorial guidelines that clearly state whether any parts of publications will not be indexed or whether certain titles will be selectively indexed based on subject.  Missing material (e.g., articles and images) that should have been included should be added in a timely fashion at no additional cost.
•	Corrections: Vendors should supply a mechanism for reporting errors in the data to the database publisher, and provide a documented policy for how often and by what mechanism errors will be corrected.
•	Backfiles: Corrections or changes made to backfiles should be documented as performed.
7.	Perpetual access 
Vendors should provide perpetual online access to licensed electronic content, meaning that CDL has use of the material to which it previously subscribed, and allows users to continue to access that data in the event the subscription is cancelled.  The vendor should be able to tailor access rights to purchased materials by IP address or other authentication mechanism, as well as by title, and year. 
8.	Preservation responsibility
Preservation is not the same as perpetual access. For preservation, the content should be archived in a secure manner so that it remains usable and faithful to the creators’ original intention and permanently available. It should not be isolated in an obsolete format. Vendors should implement a trusted digital preservation repository to safeguard the long-term integrity of the content.  The preservation repository should comply with the emerging standards for digital preservation such as the Open Archival Information System (OAIS) Reference Model.  In addition, vendors should be familiar and comply with “Trustworthy Repositories Audit & Certification (TRAC): Criteria and Checklist.” The Checklist serves to identify digital repositories capable of reliably storing, migrating, and providing access to digital collections.  Print is not an acceptable archival format for electronic content. Electronic works should have a permanent identifier for citation and linking purposes. 
URLs cited:
Open Archival Information System (OAIS) Reference Model:
http://nost.gsfc.nasa.gov/isoas/ref_model.html 
Trustworthy Repositories Audit & Certification (TRAC): Criteria and Checklist: 
http://www.crl.edu/content.asp?l1=13&l2=58&l3=162&l4=91 
9.	Access authentication
Access should be designed to allow our licensed user community to get to the resource from anywhere with a minimum of effort on our part or that of the user, and with minimal disclosure of identity information. The legacy method of authentication uses IP addresses.  Vendor systems should be able to accommodate IP-access authentication via campus proxy servers or VPN.  Special requirements for access via campus proxy servers should be well documented.  It is important that we have the option to authenticate either once per session or at every document accessed.
The CDL will provide an initial list of IP addresses for the UC community, with quarterly updates.  The list indicates which addresses represent proxy servers.  We require that vendors notify us via our CDL Support team list when the IP addresses list has been activated or updated so that we can begin testing to ensure that access is working.  We do not announce a new resource to our user community until this testing is complete. Delays and problems in activation or updates will be taken into account when UC makes decisions on new products or renewals. Because the IP method is labor intensive, error prone, and often frustrating for our users, we are actively seeking new solutions, particularly those that stress federated identity management and privacy protection.  For more information, see Appendix I: Authentication below.
Links cited:
CDL Support team list email address: cdlsupport-l@ucop.edu
10.	
Access mechanisms
Access to the resource must be simple, and should involve standard formats, protocols, codecs, and applications already in widespread use (e.g., HTTP, HTML, PDF, GIF, XML, MP3, MPEG, etc.).  We discourage specialized client applications, but when required for access to the resource, they should be available at no charge, be available for multiple platforms, and be easily acquired and implemented.  Users should not be presented with a login/password screen when access is controlled by other means, e.g., IP address. For more information, see Appendix II: Platform Support below.
Systems that impose simultaneous user limits must provide a mechanism for the user to overtly logoff from the resource and free the resource for other UC users. It is unacceptable for vendors to rely on a passive time-out action to free up restricted ports.
11.	Presentation of data
•	The presentation of the data should unambiguous. 
•	Users should not be presented with a login/password screen when access is controlled by other means, e.g., IP address.
•	No “free trials” of new databases should be added to the CDL package without express approval of the CDL. 
•	 “Dual licenses” The publisher/vendor should not cause authorized users to enter into a potentially binding agreement with the publisher (e.g., a “click-through” license) independent of the institutional agreement with the University as a condition of use of its product. 
•	The ability to present additional service options must be available via an OpenURL link to the CDL OpenURL server. See Appendix III: Use of the OpenURL Standard. 
•	The OpenURL icon must be customizable.
•	The Open URL icon should appear for all of the appropriate display formats, e.g., for each occurrence of the cited reference/bibliography for an article.
Watermarking 
Watermarking of digital images or text should be invisible to the human eye, and should not degrade the quality of the image or text. Watermarks are intended to protect the owner’s rights and must not contain any user related information, for example, a UC account number or the user's IP address.
Quality of digitized materials
Digital reproductions of data, text, images, or media files should be of comparable quality to the original item. Vendors are expected to provide color digitization of images when a color image is used in the print version. Images of low quality that do not contain the details in the original image, scanned text that is done at too low of a resolution to be legible, or OCR created text that does not accurately reproduce the original prose are not of use to the academic community as teaching or research tools. Preferred vendors will meet or exceed the requirements as set forth in the “CDL Guidelines for Digital Images,” the Digital Library Federation’s “Benchmark for Faithful Digital Reproductions of Monographs and Serials,” and the Collaborative Digitization Program’s “Digital Audio Best Practices.”

Campus branding 
Users should be presented with the message “Access paid by [campus library name]” using the following official campus library names:
•	The UC Berkeley Library
•	The UC Davis Libraries
•	The UCSD Libraries
•	The UC Irvine Libraries
•	The UCLA Library
•	The UC Merced Library 
•	The UC Riverside Libraries
•	The UCSF Library
•	The UCSB Libraries
•	The University Library, UC Santa Cruz
If only one message can be provided for the whole University of California, users should be presented with the following message: “Access paid by the University of California Libraries.”
URLs cited:
CDL Guidelines for Digital Images
http://www.cdlib.org/inside/diglib/guidelines/GDO.pdf
Digital Library Federation’s Benchmark for Faithful Digital Reproductions of Monographs and Serials 
http://www.diglib.org/standards/bmarkfin.htm 
Collaborative Digitization Program’s “Digital Audio Best Practices.”
http://www.cdpheritage.org/digital/audio/documents/CDP_DABPv2_1.pdf
12.	Documentation
For end users
All aspects of the resource and access to it should be well documented. There should be online help functions (see Appendix V: Online Help) and a prominently placed link to the vendor’s technical assistance/user support resources.
For CDL staff
To set up a new account the vendor should provide the following information as soon as database license titles is agreed upon:
•	Date access is scheduled to begin 
•	Platform used, e.g., CSA Illumina
•	Technical contact (including email address and phone number) for problems, questions, etc.
•	Account number and administrative username and password where applicable
•	URL for access to a menu of all UC licensed databases on the platform
•	URL(s) for access to each database licensed; if the URLs are campus specific, the campus specific URLs should be supplied 
13.	Statistics
Vendors should provide regular, periodic statistics, at least quarterly although we prefer monthly, that conform to the COUNTER Codes of Practice for Journals and Databases created by Project Counter, (Counting Online Usage of NeTworked Electronic Resources).  UC prefers conformance to Release 2 of the code. For further information, see COUNTER (Counting Online Usage of NeTworked Electronic Resources).
UC cannot license electronic products for which there are no statistics provided for searches, sessions (optional), turn-aways (where applicable), broken down by site (institutionally-defined set of IP addresses) and database title. 
Licenses may include each UC campus and the Office of the President, as well as our two associated laboratories (Ernest Orlando Lawrence Berkeley National Laboratory and Lawrence Livermore National Laboratory).  The UC Office of the President is an administrative unit for the system as a whole and must have access to CDL-licensed material.  CDL’s “Vendors and Content Providers” web page has a list of University of California campuses with FTE. 
Access to statistical reports should be provided monthly via a web-based reporting system that is updated in a timely manner. In addition, these data should be available in flat files containing specified data elements that can be downloaded and manipulated locally (e.g., Excel spreadsheets). Additionally, vendors should become familiar with the NISO Standardized Usage Statistics Harvesting Initiative (SUSHI). 
URLs cited:
COUNTER: http://www.projectcounter.org/code_practice.html 
CDL’s Vendors and Content Providers: http://www.cdlib.org/vendors/
UC Campus sites with FTE: http://www.cdlib.org/vendors/#enrollment
NISO Standardized Usage Statistics Harvesting Initiative (SUSHI) 
http://www.niso.org/committees/SUSHI/SUSHI_comm.html 
14.	Linking to content 
All documents contained in the electronic resource should be easily discovered and located from any license held by the CDL or UC campuses when in electronic form, or in print form from any of the UC campuses. 
Linking to articles 
CDL’s preferred method is via an OpenURL link that takes the user directly to the article. If OpenURL is supported, any database-generated links to publisher or other full text sites should be able to be suppressed. To create item level links the metadata provided in the OpenURL should include:
o	ISSN or ISBN
o	Volume
o	Issue
o	Page
o	Date
We also use CrossRef to discover DOIs.  
Linking to CDL’s Request service 
The Request service allows users to initiate an Interlibrary Loan request from citation(s) found in the database search result. To fully support Request and other OpenURL based services implemented for the UC community, CDL has created a set of metadata requirements. For more information see Appendix III: Use of the OpenURL Standard .
Linking to UC’s Melvyl Catalog holdings
Linking to UC’s Melvyl Catalog holdings is done via OpenURL.  
15.	URL verification 
The California Digital Library is in the process of moving away from the use of persistent identifiers (PIDs) to link entries in catalogs to licensed resources and is implementing OpenURL links. Until this process is completed, the CDL will periodically validate PIDs to assure that they still resolve to the correct URLs. If the licensor’s site maintains a robots.txt entry indicating that it does not permit programmatic access to the site, the CDL will assume permission to run its validation tool for the PIDs that CDL has assigned to the licensed content. No reconfiguration of licensor’s robot’s text file is needed.
16.	Use of content
Interlibrary Loan should be allowed as directed in US Code Title 17 Chapter 1, Sec. 108 Limitations on exclusive rights: Reproduction by libraries and archives. The licensing institution should be able to provide copies of an article to fill an interlibrary loan request from another institution, using the same criteria used for print journals. There should be no additional record keeping beyond that of copyright compliance by the borrowing library. The lending library should be able to post an electronic version of the article to the ILL web site for an ILL patron to view.  Items posted for ILL remain in place for a limited time, and access to the item is controlled by login / password. Once the item has been viewed, or if the expiration date has arrived without the user viewing the item, it is removed from the posting site. 
URLs cited:
US Code Title 17: http://uscode.house.gov/download/title_17.shtml 
17.	Privacy
Confidentiality of individual users must be maintained.  User data should not be reused or sold to third parties without permission. At minimum, the vendor’s policy should conform to the ICOLC Privacy Guidelines For Electronic Resources Vendors.
Elements that should be addressed in the vendor’s privacy policy include:
•	who collects user information and who has access to it 
•	what information is collected 
•	why the information is collected
•	the duration for which the information is retained 
•	when the policy was devised and when it might be revised 
•	where the privacy policy originated and how to contact its originators 
Please provide a copy of your current privacy policy. 
URLs cited:
ICOLC Privacy Guidelines: http://www.library.yale.edu/consortia/2002privacyguidelines.html
18.	Downloading into citation management software 
Preferred vendors will support the National Information Standards Organization (NISO) Z39.80 Standard Format for Downloading Records.  For more information about Z39.80, please see Appendix IV:  Downloading and Citation Management Support.
19.	Notification of changes to the resource 
Major changes to the resource should be fully documented and announced at least three months in advance via email to the CDL Support team list.  Ideally, such changes would occur on a regular basis, e.g., twice a year, in January and June, so that notification to users and instructional and publicity materials can be prepared in advance.
•	Changes in delivery, including access mechanism, site, or URLs, require advance notification.
o	For global changes, such as changing the database platform the CDL requires a minimum of six months notice. Notification should be sent via email to the CDL Support team list.
o	For global changes involving migration to a new site, dual access must be maintained for a minimum of three months.
o	The full extent of the changes should be documented and announced at least three months in advance. 
o	Vendor technical staff must be available for consultation and problem resolution.
o	Any aspect that impacts service to users, e.g., OpenURL service should be included in the notification.
•	Changes in access: This includes changes in format, display and indexing of the content.  Search mechanisms should allow for differences in data produced over time so that search results do not inadvertently omit relevant items due to changes in indexing.
•	Changes in content coverage: Changes in content coverage: 
o	The full extent of the changes should be documented and notification sent to the CDL Support team list at least six weeks in advance regarding:
•	Titles to be dropped from indexing
•	Titles ceasing publication and date of last indexed issue
•	Titles added to the indexing stream and level of coverage, e.g., cover-to-cover or selective indexing
•	Changes in content loading schedule: The CDL should be notified via email to the CDL Support team list as soon as it is established that there are problems with content loading that may result in delays of one week or more for addition of new content.
•	OpenURL support: Changes in the level of OpenURL support, including data added or dropped from the OpenURL, e.g., moving from version 0.1 to version 1.0 of the OpenURL standard. Notification of major changes, e.g., new syntax, should be sent as soon as the final specifications have been established.
•	Functionality: Notification should be sent to the CDL Support team list at lease three months in advance of the addition of new functions and of functions that are removed or substantially changed.
•	The user interface: Notification should be sent to the CDL Support team list at lease three months in advance of substantial changes to the look and feel or placement of key features.
•	The network address: Notification should be sent to the CDL Support team list at lease six weeks in advance of any changes to the network address used to access the database. Redirect services should be provided.
•	System Status: As mentioned earlier in the Fail-safe operations section, vendors should provide a system status page that is hosted on a server not used to provide access to content.  This page should report both planned and unexpected outages.  
Links cited:
CDL Support team list email address: cdlsupport-l@ucop.edu
20.	Compliance with the Americans with Disabilities Act (ADA)
The CDL is committed to providing resource access to members of the UC community with disabilities. UC has a comprehensive interest in ADA compliance, and offers a wealth of ADA-related resources at UCLA's Disabilities and Computing Program.  Preferred vendors will comply with World Wide Web Consortium (W3C) “Web Content Accessibility Guidelines” and Section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Please describe your level of compliance to the above guidelines and regulations..
URLs and Links cited:
UCLA's Disabilities and Computing Program: http://www.dcp.ucla.edu 
Web Content Accessibility Guidelines: http://www.w3.org/TR/WCAG10/ 
Section 508 Standards: http://section508.gov/index.cfm?FuseAction=Content&ID=12
21.	Special Accounts for training and for development/Troubleshooting:
Training account
Vendors should provide the CDL with separate training accounts with the same defaults and data as the end user account, that have no expiration date, and that accommodate CDL and campus library staff use.  UC users are best served when training accounts are always available, requiring no permissions or negotiations in advance. For resources involving port limits, the use of separate accounts would eliminate the chance that training sessions might limit access for other legitimate users. Separate accounts clarify usage statistics, helping both CDL and vendors gain a more accurate statistical picture of true user activity.
Development/troubleshooting account
Vendors should provide the CDL with a separate development / troubleshooting account to use for OpenURL set-up and maintenance as well as other development activity, e.g., metasearch set-up and testing and for troubleshooting user problems.  This account should include all databases licensed from the vendor at the systemwide and local level. The development account should be a separate account so that the usage on this account is not included in the end user statistics.
22.	Accommodation for Metasearch: Federation and Aggregation
The trend in bibliographic discovery is to move away from visiting each separate vendor interface and move toward use of a single search box.  CDL believes it is in the vendor's interest to expose their content in as many places as possible, since vendors:
•	retain all their existing revenue streams; and
•	continue to safeguard access to the full text, since vendors still control authentication/authorization/delivery
As a benefit, users enjoy increased findability and vendors enjoy increased promotion and use of their content.
Metasearching can be achieving in one of two ways: federation or aggregation.
Federation
CDL is moving to the use of focused federated search portals that search multiple remote databases with a single query.  The federated search software will launch the search using the existing end user account. CDL’s development efforts are based on the NISO MetaSearch Initiative.
Methods of accessing a vendor site from CDL’s federated search application are listed in order of preference.
1.	Z39.50
2.	SRU (preferred) or SRW
3.	NISO Metasearch XML Gateway (MXG) protocol (based on the NISO-registered SRU protocol)
4.	Proprietary XML gateway
Aggregation
Scholarly content is aggregated into a single index that is made available in centralized services such as Google Scholar, Microsoft Live Search Academic, and WorldCat.org.  In this approach, a centralized service (e.g., Google Scholar) obtains permission from the content provider to index the content locally, either by harvesting metadata or by crawling the full text content.
Increasing numbers of users are benefiting from these aggregated services.  CDL strongly encourages content providers to allow their content to be included in these services, which are taking an increasingly prominent role in the searching behavior of end users.
URLs cited:
NISO MetaSearch Initiative: http://www.niso.org/committees/MS_initiative.html
NISO Metasearch XML Gateway (MXG) protocol:
 http://www.niso.org/standards/resources/MI-MXG_v0_3.pdf 
23.	Current awareness feature
UC users rely on current awareness services (aka AutoAlerts, Update, RSS feeds) to keep up with the literature in their field. This service allows users to submit scripts of one or more searches that run at pre-selected intervals in the selected database and retrieve records added to the database since the last run of the script.  Results from these searches are automatically mailed to the user's electronic mailbox.  Please consult Appendix VI: Current Awareness for specific requirements.  
24.	User self-registration 
This function allows users to set various preferences on the vendor site, for example, create a set of search results, store their email address, preferred display format, etc.   It enables users to easily identify themselves in order to create, view and modify their preferences.  Please see Appendix VII: User Self-Registration for specifications.
25.	Online help 
Online help is increasingly important as many users work off-campus.  Good online help also aids librarians in training and assisting users in person.  Based on experience with many vendor help systems, we have developed a checklist of desirable characteristics.  Please consult Appendix V: Online Help for more information.

Appendix I: Authentication
The future of authentication at UC 
A flexible authentication mechanism is crucial to UC's plans to enhance library services, and the choice of vendors for licensed electronic resources must reflect this priority.  Our current system employs a large network address space with multiple domains, managed in a distributed fashion; each campus Network Operation Center (NOC) registers its own address space with InterNIC and manages those addresses locally. In addition, some campus units choose to contract with external ISPs for specialized services such as modem pools for dial-up and proxy services. These services require the use of IP addresses that are not registered to UC in the InterNIC database, but are dedicated to use by UC faculty, staff, students, and library patrons.  Not surprisingly, UC has found this method increasingly cumbersome, and we are now seeking alternative mechanisms for authenticating valid users, wherever they may be located.
UC's Preferred Solution for Authentication
UC is seeking to implement access control mechanisms that simplify the authentication protocols that we employ in support of our enterprise.  Methods for authenticating users should facilitate access by authorized users no matter where they are physically located. Access to products should not require individual passwords or user IDs, and UC must be allowed to use proxy servers to allow remote access for authorized users when necessary. Vendors who persist in requiring individual passwords, user IDs, or IP address authentication to access their products will accordingly appear significantly less attractive as the university weighs its options.
The most promising alternative to IP-based authentication is the Shibboleth protocol. A project of Internet2, Shibboleth is developing architectures, policy structures, practical technologies, and an open source implementation to support inter-institutional sharing of web resources subject to access controls. In addition, Shibboleth is developing a policy framework called InCommon that will allow federated inter-operation amongst the higher education community and the vendors that market online services to the community.  UC is committed to compliance with the access security policy framework promoted by the InCommon Federation, and would expect vendors to make a similar commitment, ensuring an appropriate level of security for licensed resources, and privacy for personal information about users.   
The CDL preferentially contracts with vendors who are working to implement resource access through the use of Shibboleth.  Many vendors have implementation plans in place, and significant community resources exist to facilitate the migration to Shibboleth.  Shibboleth software is standards-based and open source, so there are no license fees, and the software itself is not difficult to install and maintain. For more information on UC’s implementation of Shibboleth, UCTrust, see UCTrust: The University of California Identity
Management Federation.
Shibboleth: Benefits to Vendors
Recent trends in telecommuting, distance education, and the globalization of scholarship suggest the university's need to accommodate remote users will grow exponentially in the coming years. The early adoption of Shibboleth may very well preempt large-scale access problems as your clientele--and the sophistication of its access needs--grows. 
Shibboleth allows currently valid users to access resources regardless of their physical location.   At the same time, the protocol provides vendors with a more authoritative and up-to-date assurance that the user is a verified member of the UC community, which in turn makes it easier to identify and exclude users whose status has lapsed. 
Once ubiquitous, the use of Shibboleth will undoubtedly prove a more cost-effective and efficient means of validating users' status, and will relieve both parties of the need to maintain the extensive IP address tables. 
URLs and links cited:
Shibboleth Project:  http://shibboleth.internet2.edu/
Shibboleth target server: http://shibboleth.internet2.edu/guides/deploy-guide-target1.2.html 
UCTrust: The University of California Identity Management Federation: http://www.ucop.edu/irc/itlc/uctrust/

Appendix II: Platform Support
Many of our users access databases from different platforms, including those available on Microsoft, Macintosh, and Linux operating systems. In order to reach all University of California users, vendors should offer file formats that are accessible on each of these platforms. In addition, vendors should utilize applications that are supported for the most current and most recent previous major releases of each Microsoft and Macintosh operating system release. The same support level should be maintained for vendor created applications.
Many of our users access databases from remote locations, 24 hours a day. In order to provide streaming media databases to our remote users, vendors should utilize streaming media protocols that are supported on a wide variety of proxy servers. Any special instructions, such as port opening or tunneling protocols, should be given explicitly in advance of launch for approval by proxy server administrators.

Appendix III: Use of the OpenURL standard
OpenURL: UC's preferred solution
It is vital that product sites be OpenURL-enabled.  The OpenURL standard (see NISO Standards Committee AX) for the transportation of metadata between an information resource and a local linking service such as SFX allows the local service to provide custom hyperlinks for its user community.
Use of the OpenURL standard is preferred over proprietary vendor solutions. 
OpenURL: Format
The OpenURL should contain:
•	the address of the local linking service (the BASE-URL)
•	a vendor ID
•	a database ID
•	identifiers (e.g., DOI, PubMed ID, etc.) and/or sufficient metadata (e.g., ISSN, volume/issue, pages, author, title, date) to uniquely identify the object and/or a unique key that can serve as a pointer to metadata in the resource that initiated the OpenURL (this can be used to retrieve the item's complete bibliographic data).
For more specific information on how to OpenURL-enable resources, see 
http://www.niso.org/committees/committee_ax.html.
UC Requirements
To fully support services implemented for the UC community, CDL has created a set of metadata requirements for OpenURLs sent to the CDL SFX server. The thresholds in this document must be met to provide all of the CDL supported services, including UC’s online Interlibrary loan service, Request, which requires more metadata than other services.
UC has named its OpenURL service “UC-eLinks”.  Either this name as a text link or the UC-eLinks icon should be used in the vendor’s interface rather than SFX or a vendor’s label.  The name or icon should appear on all citations. 
URLs cited:
NISO Standards Committee AX: http://www.niso.org/committees/committee_ax.html 
UC-eLinks icon: http://ucelinks.cdlib.org:8888/sfx_local/sfx.gif 
CDL metadata requirements: http://www.cdlib.org/vendors/Metadata_requirements.pdf 

Appendix IV: Downloading and citation management software
The citation management software problem
The incompatibility of vendor downloading formats is a growing obstacle to the interchange of information between abstracting and indexing services and our users' citation management software.  Although most sources of electronic bibliographic records offer some means of exporting their data, most choose displays and download formats unique to their own product.  Our users report rising levels of dissatisfaction at this disparity.  Ultimately, the costs are borne by the research community in the form of inefficiencies and errors. UC prefers to contract with vendors who are willing to move toward a single, uniform downloading format.
Z39.80: UC's Preferred Solution
Accordingly, UC prefers a standard for a cross-platform, cross-vendor scheme of structured record preparation for export from one computer and import to another, and plans to conform to accepted National Information Standards Organization (NISO) practice. 
In late 1999, NISO drafted the Z39.80 standard to provide precisely this functionality for downloading.  Z39.80 offers a simplified yet highly structured record format. While designed to facilitate any use of bibliographic data in client software, it is primarily aimed at use with the many software packages that convert data from online sources into fully formatted bibliographic citations.  For information on the Z39.80 Standard Format for Downloading Records, please see the NISO Standards Committee AJ web page and the most recent draft of the proposed Z39.80 standard.
Thomson Gale enabled support for Z39.80 in their new InfoTrac platform released in 2005.
Given that users will come to rely on this uniform solution, it is important that all vendors in the online information industry adopt a similar policy.
Z39.80: Benefits for Vendors
While transition to Z39.80 may involve conversion costs, the larger benefits of keeping up with industry standards will likely more than compensate vendors.  Ease of data access and manipulation are primary selling criteria for information consumers.  Early adopters of Z39.80 can expect to gain a competitive advantage in the marketplace. The resulting ease of use may well attract new consumers as well as increase demand among existing clientele.  Finally, reducing the number of download formats will ultimately allow all industry participants to redirect staff and technological resources toward product quality. 
URLs cited:
NISO Standards Committee AJ: http://www.niso.org/committees/committee_aj.html
Most recent draft of proposed Z39.80 standard: http://www.niso.org/standards/resources/drft4rev.html

Appendix V: Online help
Many of our users access databases from remote locations, 24 hours a day.  In such circumstances, in-person help may not be available or convenient.  Vendor online help, then, becomes increasingly important to our users.  Vendor online help is most effective for users when it is
1.	Organized and accessible in several ways: Help should be organized by task or function, by index or glossary, be searchable, and be context sensitive.
2.	Context sensitive: Help should be specific to the situation or action just taken. 
3.	Easy to navigate between Help and previous activity: Help should appear in a new, smaller window that “stays on top” so that users may consult help while working on the search form, display options, etc. 
4.	Database specific: Help should describe options that apply only to the selected database or it should be clear when a feature is generic to the vendor vs. specific to a database. Features unique to a database should be easily discovered. 
5.	Searchable:  For example, if users want to know how to rank results in the database, it is most useful if, in the help system, users can type in the term rank results and be guided as to how do this in the database.
6.	Glossary:  The user should be able to locate the definition of a specific term; the glossary should be easy to discover. 
7.	Built in “how-to” search or tutorials: Tutorials, available from the search screen, that guide the user through the system, allow for searching specific terms, and provide some indication of how long each section of the tutorial is (e.g., 3 screens, five minutes) are extremely useful.  
8.	Error messages:  Messages should be comprehensible and helpful; for example, zero results prompts for a display of search tips. 
9.	Self-instructing: The user interface should guide the user such as providing sample searches shown on the initial and following search screens, if appropriate, as well as in help text. 
10.	Adaptable training materials: The vendor should provide materials such as online user guides that are adaptable by the home institution. 
11.	Feedback: Option for the user to provide feedback should be highly visible, with the ability to send online comments both to the home campus and to the vendor. It is also desirable to provide a link to a designated page on a library’s web site (at least one per campus) which offers the user choices for getting help via live reference, email, phone, or in person.
12.	For each index in the database there should be database specific 
•	Explanations of what is searched, e.g., “The keyword index looks for terms from the Title, Abstract and Subject fields”;
•	Indication of the portion of the database searched by the index, e.g., 1994-present, if the index does not search all years of the database. This should also appear with the index name in any search forms or menus, e.g., Subject (1967- );
•	Examples of the syntax to be used for the index, e.g., “When searching for the author Andrea P. Anderson, format your search as Anderson, A P”; 
•	Links from the index description to any controlled vocabulary used by the index.

Appendix VI: Current awareness services
Specific CDL Requirements for current awareness services
The Vendor System should:
1.	Support user self-registration (see Appendix VII: User self-registration) for current awareness service and not require the CDL to assign specific end user accounts for access to this service.
2.	Support the creation of a script of one or more searches that can be scheduled to run without user intervention.
3.	Run search scripts automatically against the specified database(s) at a specified interval.  
4.	Mail the results of automatic searches to one or more user-defined electronic mailboxes. 
5.	Support all display options that are supported for search results in the vendor web interface. This should include a tagged data format so that a user may load the data into bibliographic file management software. 
6.	Make it possible for users to designate an existing search (e.g., the current search or a search available in the Previous Searches) to be executed as an automatic “update” search. 
7.	Allow the user to edit the search scripts once submitted. 
8.	Allow the user to delete a script and its associated search results at any time. 
9.	Have search scripts run for a specified time period, preferably one year, with an option for the user to renew them.  Scripts should not expire during June, July, August, or September.  Scripts that would normally expire during these months should expire in October so that users who are away during the summer do not return to find that their scripts have expired. 
10.	Alert the user via email that an update is about to expire. If the system supports storage of personal information between sessions, it is desirable that a notification also be placed in the profiled user’s work area. 
11.	Include URLs that accompany records in an update. 
The following items are desirable, but not required.
1.	Ability to disable the “update” feature for certain public locations and / or for certain databases. 
2.	Option for user to assign an email subject line to the automatic “update” search.
3.	Option for user to assign a name to the automatic “update” search. 
4.	Option for user to supply an email annotation that would be attached to each delivery of search results. 
5.	Option to select whether or not to receive reports of searches that retrieve zero results. 
6.	Possibility for search results to remain accessible for at least 4 weeks after the weekly search has completed.  Users should be able to access the results via the same identification mechanism used to edit existing "update” searches. 
7.	Option for the profiled user to be notified that an automatic search has completed at the time of logon to the database. 
8.	Option for user to select whether to receive the update results by email and / or by notification at logon (for profiled users). 
9.	Ability to send the results of an “update” search to a user work area to be accessed by the profiled user who submitted the search. 

Appendix VII: User self-registration
This function allows users to set various preferences, for example, create a set of favorite journals, create a current awareness search, etc.   It enables users to easily identify themselves in order to create, view and modify their preferences, such as settings for their current awareness searches.
The specifications below are those used for this function in CDL’s Melvyl Catalog.  Methods for allowing users to self-register may vary as long as they generally conform to the method described below.  The “forgot password” routine is optional but experience has shown that users will need and appreciate this capability.
1.	To create a profile, the user must establish a User ID and Password.  These may consist of 3 to 12 alphanumeric characters. The user is asked to enter the password twice to confirm.
2.	On the same page, the user may enter an email address if they want to use the Update (current awareness) service.  
3.	On the same page, the user is presented the option of answering one of three possible “password bypass” questions.  User's answer to the question may be up to 15 alpha characters long, is not case sensitive, and is stored in the administrative database. 
4.	On Sign In page, user is required to enter User ID and Password.  Sign In page contains the “Forgot Password?” link.
5.	If user selects the “Forgot Password?” link from Sign In page, the user is taken to a page that includes the password bypass question, as well as the opportunity to enter their User ID and a new password.
6.	If user's answer to password bypass question is positively matched against the stored answer, user receives confirmation that a new password has been established. User is signed in and is granted access to previously established profile.  If password bypass question is not answered correctly, system returns message that a match could not be made and that user must establish a new profile.