NISO Circulation Interchange Protocol (NCIP - Z39.83) Implementation Group Website

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.