What is NCIP?

The following information is taken from the Foreword to Circulation Interchange Protocol: Part 1, pp. vi-viii

Both the rapid evolution of Web-based library services and the growing number of resourcesharing arrangements among libraries require an open standard for the exchange of circulation data. These applications must exchange data about library users, the items they wish to use, the owners of the items, and the relationships among these three entities. In the absence of an agreed-upon standard for exchanging circulation data, interoperability among disparate applications has been ad hoc and proprietary. The cost of such solutions is high for individual agencies and in any case, these solutions often provide for only a limited exchange of data because proprietary solutions limit the number of implementations that can participate in the exchange.

This Standard is intended to address the growing need for interoperability among disparate circulation, interlibrary loan, and related applications. Interoperability between self-service applications and circulation applications, between and among various circulation applications, between circulation and interlibrary loan applications, and between other related applications, has been the principal focus of this Standard. All key terms used in this Standard are defined in Section 4 or Section 6.

The demand for self-service applications led to the development of the 3M Standard Interchange Protocol (SIP) which has become the de facto standard interface for self-service applications. This Standard supports the deployment of self-service applications by building on experience obtained from the broad use of the 3M SIP.

This Standard has been developed within the context of a variety of existing standards, as well as through an awareness of existing applications. Wherever possible, existing terminology and definitions are used, duplication is avoided, and every effort has been made to permit developers to meld standards into a single application.

The Protocol

The protocol specified in this Standard (NCIP) defines and specifies a set of objects, a set of services, messages that support those services, a set of data elements used in the messages, and a pair of state tables governing the exchange of messages over a single connection. NCIP is a connection-oriented, sessionless protocol.

• Connection-oriented - Circulation processes happen in real time, often with the user present and awaiting service. A connection-oriented protocol facilitates a timely interaction between applications and allows the application requesting a service to know with confidence that a message was received by the partner application.
• Sessionless - The lifecycle of a particular circulation activity provided by an agency to a user is often extended over days, weeks, or months. It is impractical to maintain sessions between two applications. This environment is unlike information retrieval where a single service involves related exchanges within a brief period of time.
• State of the message - The protocol does provide a simple state table that governs the exchange of messages within a connection. This table does not govern the order of messages across the lifecycle of any particular circulation exchange between a user and agency or agencies.

Extensibility

NCIP is intended to support multiple applications and to evolve with technology and library practice. This requires an extensible framework that includes the protocol and two types of profiles.

• The Standard - This Standard describes the services, data objects and data elements at an abstract level. The protocol defined herein may be deployed using different encoding and transport implementation methods.
• Implementation Profiles - Each implementation method is described in a separate Implementation Profile that specifies how messages are exchanged. Specifications include message, character, and data encoding; required components and behavior; network transport; network security; scheme registration; and provision for extension. Note: Implementation profiles were originally called Cross-Application Profiles.
• Application Profiles - Application Profiles describe how the protocol would be used to support a specific application with a given set of practices and policies. An Application Profile includes a description of services that must be supported. Each profile also provides an event table that maps specific external events and circumstances to the use of particular services specified in the protocol.

This total framework will provide the stability required for longevity of use along with the flexibility necessary for NCIP to adapt to changing usage and technology. It will also allow it to be used across multiple applications.

• Evolving technology and usage - Separating services and data objects from actual implementation details will allow the NCIP to be implemented with new technology without needing to redefine services or data objects.
• Multiple applications - Practical implementation of the NCIP will vary among and even within broad application areas. If each application were to follow its own rules, interoperability would inevitably suffer. The application profiles allow for detailed specification of the use of the NCIP within a particular application area. Two implementors exchanging messages have a common set of rules to determine what messages must be sent in a particular circumstance.

Of equal importance in thinking about extensibility is balancing the requirement for supporting the wide variation in local circulation practices and policies with support for interoperability among libraries and other organizations. Investigation showed that much of local practice and policy data is encapsulated in enumerated lists that capture descriptive elements for both items and users. The values in those lists vary from library to library, even among libraries of the same type. As a solution to the need to support variation in local library practice, the NCIP uses a schemevalue pair instead of a single primitive data element for all such enumerated lists. The scheme name identifies the specific enumerated list that is being used. The value element provides a specific entry from this list. Each scheme is identified by a URI to guarantee a unique name for the scheme.