NISO Circulation Interchange Protocol (NCIP) Standard
Principles and Guidelines for Development
1999/11/04
To submit comments on this draft, please visit the following URL:
www.ladenton.com/niso/comment.html
1. Statement of the Problem
Circulation processes and services are evolving in directions that increasingly require disparate computer applications to exchange information about library users, the items they wish to use, the owners of the items, and the relationships among these three entities.
Without an agreed-upon standard for interchanging circulation information, interoperability among disparate systems has been ad hoc and proprietary. The cost of such solutions is high for individual libraries and in any case these solutions provide for only a limited exchange of information.
A widely implemented standard protocol for the interchange of circulation information between and among disparate circulation applications, and between circulation applications and interlibrary loan (ILL) applications could solve this problem.
To submit comments on this draft, please visit the following URL:
www.ladenton.com/niso/comment.html
2. Proposed Standard and Its Purpose
The proposed NISO Circulation Interchange Protocol (NCIP) standard defines a repertoire of messages and associated rules of syntax and semantics for use by applications a) to perform the functions necessary to lend items; b) to provide controlled access to electronic resources; and, c) to facilitate co-operative management of these functions. This standard is intended specifically to address conditions in which the application or applications that initiate the lending of items or control of access must acquire or transmit information about the user, items, and/or access that is essential to successful conclusion of the function.
The standard protocol will support the following application areas. It is recognized that the standard might be used in other areas as well.
• DIRECT CONSORTIAL BORROWING — "Direct consortial borrowing" services allow users of one library to request and borrow items from another library within a consortium. The proposed protocol will facilitate the transfer of user and item data between disparate circulation systems, thereby allowing a library to manage traffic for non-local patrons and/or provide local control of items belonging to another library. The commitment of libraries to the access model, and the resulting growth of regional resource-sharing consortia, has created a need for circulation systems to interoperate in this way.
• CIRCULATION/INTERLIBRARY LOAN INTERACTION — The proposed protocol will facilitate the interaction between interlibrary loan systems and circulation systems. Many libraries want to use their circulation systems to track all loans to a user so that items belonging to the local collection and items borrowed for that user via interlibrary loan can be recorded together in the user's circulation record. Widespread use of the protocol will allow libraries to handle notifications for pickup, listing of charges, overdue notifications, etc., in the same way, whether items are owned locally or borrowed from another library.
• SELF-SERVICE CIRCULATION — Several vendors have supplied libraries with self-service devices that allow users to check out or check in their own materials without assistance from library staff. In addition, these devices have supported fine/fee transactions and supplied some user account information. 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 to self-service applications. The NCIP standard proposed here will also support the deployment of self-service applications by building on experience obtained from the broad use of the 3M SIP.
• ACCESS TO ELECTRONIC RESOURCES — The proposed protocol is expected to be applicable to new applications that manage electronic resources such as electronic books, serials, sound recordings, etc. As with circulation and interlibrary loan, libraries will want to use their circulation systems to manage access to electronic resources by a user, irrespective of the type or source of the electronic resources.
To submit comments on this draft, please visit the following URL:
www.ladenton.com/niso/comment.html
Activities required to support these applications are identified in Appendix A. These activities will be mapped to protocol services in the next phase of the committee's work (see also Section 6).
3. Scope of Proposed Standard
This standard defines a protocol that is limited to the exchange of messages between and among computer-based applications to effect circulation and to support controlled access to certain electronic resources or other library services. The standard is not intended to define circulation or other functions, but to facilitate communication between and among such functions as implemented by developers of automated systems. This communication may be based upon agreements previously established by the cooperating libraries to govern that relationship. However, this standard also will permit these relationships to be established upon first interaction between two agencies, or to be established at each interaction on a case-by-case basis.
To submit comments on this draft, please visit the following URL:
www.ladenton.com/niso/comment.html
4. Standards Environment
This proposed standard is being developed within the context of a variety of existing standards (see below), as well as with an awareness of existing applications. Wherever possible, existing terminology and definitions will be used, duplication will be avoided, and every effort will be made to permit developers to meld standards into a single application.
Circulation
Interlibrary Loan
Other
To submit comments on this draft, please visit the following URL:
www.ladenton.com/niso/comment.html
5. Technical Assumptions and Design Principles for Proposed Protocol
5.1 Nature of the Protocol
Simple Protocol: To further the goal of wide and rapid adoption of the proposed standard, the committee has endeavored to keep the technical requirements for implementation as simple as seemed consistent with the purpose of the protocol the standard defines.
Confirmed Service: The proposed protocol will be a confirmed service employing pairs of messages termed "initiation/response pairs". Each message and the current state of the connection provide sufficient contextual information for the application receiving the message to process it successfully. The messages will be based on many of those defined in the 3M SIP version 2.0 with additional data elements, messages, and enhanced syntax and semantics to support the broader scope of the NISO Circulation Interchange Protocol (NCIP).
Connection-oriented Transport: Because the proposed protocol will be a confirmed service, it will require use of a connection-oriented transport mechanism. The connection employed to transmit protocol messages between applications provides the mechanism for relating a response message to its initiation message and for indicating a time-out event. Because of this fact, the state of the connection has significance within the scope of the protocol (see Appendix B, "Messaging State Tables").
For example, a responding application will only be able to determine that the initiating application has timed-out when the initiating application closes the connection. (It is expected that in some cases the responding application will use this fact to "back out" any database updates it performed during processing of the initiation message.) Similarly, an application waiting for a response message is informed by a closed connection that no response message will be forthcoming.
Application Roles: An application that initiates a connection is termed the "initiating application," and the application that accepts the connection is the "responding application." Applications are not restricted to a single role in general; however, they are restricted to a single role within the context of a given connection.
An example of conformant behavior is: Application "Circ A" initiates a connection to application "Circ B." At the same time "Circ B" initiates a connection to "Circ A" (or to a third application) for a related (or unrelated) purpose. In the context of the former connection "Circ B" is the responding application, while in the context of the latter connection "Circ B" is the initiating application.
Messaging: Once a connection is established, the initiating application may send an initiation message. The responding application must respond with the associated response message, and it must respond over that same connection. If a response message is received, the initiating application may send a subsequent initiation message over the same connection.
Time-out: Initiating applications may time out if a response message does not arrive within a reasonable length of time; responding applications may time out when a connection has been idle for an excessive length of time. The standard will not define time-out intervals. Applications that time out must close the connection (this serves to trigger a state transition in the other application).
Example sequence of events:
5.2 Messaging State Tables
The Messaging State Tables in Appendix B define the behavior of the initiating and responding applications with regard to messaging over a single connection. These tables do not govern the status of the circulation function being performed by either application. The committee will further refine these tables as the protocol is defined.
5.3 Message Syntax
The syntax of the messages in the proposed standard (i.e., the component data elements and their data types and structure) will be described initially in ASN.1 because of its strong data-typing capabilities. The committee will provide an XML description instead of or in addition to the ASN.1 if work on XML data definitions has proceeded to a point where this seems judicious. ASN.1 is used only for data description and the eventual choice of encoding method will not be prejudiced by the use of ASN.1.
5.4 Transport Protocol and Encoding
The proposed standard will not define a transport protocol or an encoding method for the NCIP. The committee expects to inaugurate a parallel Implementers Group to speed definition of a profile for the NCIP, which will include specification of a transport protocol and an encoding method.
To submit comments on this draft, please visit the following URL:
www.ladenton.com/niso/comment.html
6. Time-Table for Development of Standard
Current Calendar
1999 November 30 Comments on Principles Document due from all interested parties
1999 November 30 First draft of Services Definitions
1999 December 12-14 Fourth Committee Meeting, San Diego
1999 December 31 Final version of Services Definitions
2000 February 18 First draft of Protocol Specifications
2000 March 3 Comprehensive list of Data Elements
2000 March 12-14 Fifth Committee Meeting, Raleigh/Durham/Chapel Hill
2000 May 7-9 Sixth Committee Meeting, Minneapolis
2000 August 18 First complete draft of Standard submitted to NISO for comment and vote
7. Committee Membership
Karen Anspach, EOS International
John Bodfish, Ameritech Library Services
Robert Daugherty, University of Illinois at Chicago
Janifer Gatenby, GEAC Computers (from 1999 November)
Patrick Gignac, (GEAC Computers through 1999 October)
Mary E. Jackson, Association of Research Libraries
Jerry Karel, 3M Company
Mark Needleman, Data Research Associates, Inc.
Sally McCallum, Library of Congress
Julie Blume Nye, State Library of North Carolina
Patricia Renfro, University of Pennsylvania
James E. Rush, formerly PALINET (retired)
William Schickling, Gaylord Information Systems
Barbara Shuh, National Library of Canada
Patricia Stevens (chair), OCLC, Inc.
John Wardell, CPS Systems, Inc.
Sandy Westall, Innovative Interfaces, Inc.
Mark Wilson, The Library Corporation
8. For Further Information, Contact:
Committee AT
National Information Standards Organization
4733 Bethesda Avenue, Suite 300
Bethesda, MD 20814-5248
Phone: 301 / 654-2512
Fax: 301 / 654-1721
e-mail: nisohq@niso.org
url: www.niso.org/commitat.html
APPENDIX - Activities to be Supported by Standard
The proposed standard protocol is intended to support the following four classes of activities. These classes help to organize the activities logically; they are not mutually exclusive. Moreover, the list of activities may need to be expanded or modified as more detailed work in mapping of activities to protocol services (as indicated in the timetable in Section 6 of this document) progresses.
Exchange of User Information
- Request User Information
- Send User Information
- Update User Information (includes financial transactions)
Exchange of Item Information
- Request Item Information
- Send Item Information (unsolicited)
- Track Item (send item/receive item; return item/receive item; routing of item e.g., in case of
misdirection)
- Send Pull Request (ask that an item be retrieved from the stacks)
Exchange of Transaction Information
- Check Out Item
- Check In Item
- Renew Item
- Fine/Fee Assessed
- Fine/Fee Paid
- Place Reserve (Hold)
- Remove Reserve (Hold)
Request Notification
- Overdue Notice
- Recall Notice
- Fine Notice
- Fee Notice
APPENDIX B — Messaging State Tables
The Messaging State Tables define the behavior of the initiating and responding applications with regard to the messaging over a single connection. These tables do not govern the status of the circulation function being performed by either application. A blank cell in the tables represents the combination of an incoming event and a state that is not defined for the protocol. The terminal state for this protocol is not represented in the tables, as there is no "messaging state" immediately after transition to the terminal state.
The initiating application’s messaging may be in one of two states: Idle and Waiting. The responding application’s messaging may be in one of two states: Idle and Processing. The Idle state means that the connection exists but no response message is outstanding. The Waiting state means that the connection exists and a response message is outstanding. The Processing state means that the connection exists and the application is processing an initiation message.
The initiating and responding state machines enter the Idle state upon successful establishment of a connection.
Incoming events:
INITreq Application requests permission to send an initiation message.
RESPreq Application requests permission to send a response message.
CLOSEreq Application requests permission to close the connection.
INITind Application has received an initiation message.
RESPind Application has received a response message.
CLOSEind The connection is no longer valid.
TIMER The timer has expired.
Outgoing events:
INIT Application shall send initiation message.
RESP Application shall send response message.
TIMER Application shall close the connection because its timer has expired.
CLOSE Application shall close the connection.
Predicates:
p1 Returns true if the identifier of the message matches the MESSAGE.Id protocol variable.
Variables:
MESSAGE.Id Has the value of the identifier of the last message transmitted (in the initiating role) or received (in the responding role).
Initiating Application Messaging State Table:
|
Event |
IDLE |
WAITING |
|
|
1 |
INITreq |
set MESSAGE.Id var set timer INIT WAITING |
|
|
2 |
RESPind |
p1 signal error #1 TERMINAL |
p1 clear timer IDLE |
|
3 |
RESPind |
^p1 signal error #1 TERMINAL |
^p1 signal error #2 TERMINAL |
|
4 |
INITind |
Signal error #4 TERMINAL |
signal error #4 TERMINAL |
|
5 |
CLOSEreq |
CLOSE TERMINAL |
|
|
6 |
CLOSEind |
TERMINAL |
signal error #3 TERMINAL |
|
7 |
TIMER |
TIMEOUT TERMINAL |
ERROR # meanings:
1: Response message received while in IDLE state.
2: Response message received is not an appropriate response for immediately preceding initiation message.
3: Connection was closed while waiting for response message.
4: Initiation message received.
Responding Application Messaging State Table:
|
Event |
IDLE |
PROCESSING |
|
|
1 |
INITind |
Clear timer PROCESSING |
Signal error #1 TERMINAL |
|
2 |
RESPreq |
p1 RESP Set timer IDLE |
|
|
3 |
RESPind |
Signal error #2 TERMINAL |
Signal error #2 TERMINAL |
|
4 |
CLOSEreq |
CLOSE TERMINAL |
|
|
5 |
CLOSEind |
CLOSE TERMINAL |
Signal error #3 TERMINAL |
|
6 |
TIMER |
TIMEOUT TERMINAL |
ERROR # meanings:
1: Initiation message received while processing an earlier message.
2: Response message received.
3: Connection was closed while still processing an earlier message.
Final
JER/19991104
To submit comments on this draft, please visit the following URL: