1. An Introduction to NCIP October 2, 2002 Mark H Needleman Sirsi Corporation NCIP Implementers Forum Revised January 2, 2008 Lynne Branche Brown Innovative Interfaces, Inc. NCIP Implementers Group

2. Scope of the Standard zA repertoire of messages & associated rules of syntax and semantics zBetween and among computer based applications zDoes not define circulation functions or policies zDoes not define user interface

3. Functions Supported zDirect consortial borrowing zCirculation/InterLibrary Loan Interaction zSelf-service Circulation

4. NCIP Structure zPart 1: Protocol Definition zPart 2: Implementation Profile 1 zXML DTD and Schema zVendor Application Profiles NCIP Documentation has multiple parts:

5. Circulation Interchange Part 1: Protocol zDefines the Services zDefines the Messages zDefines the Data Elements zDefines the error codes zDefines the extensibility mechanism zProvides some lists of enumerated data types zProvides a simple state table

6. Circulation Interchange Part 1: Protocol, con’t zDefines the concept of profiles zProvides a template for building Implementation and Application Profiles zProvides guidelines for activities of maintenance and registration agencies zNot bound to any particular technologies

7. Circulation Interchange Part 2: Protocol Implementation Profile 1 zDefines the message encoding (XML) zDefines the underlying Transport Protocols - HTTP/HTTPS and TCP zDefines Character Set - Unicode/UTF-8 zDefines some behavior rules zProvides an encoding of enumerated datatypes

8. XML DTD and Schema zProvides the XML encoding of the messages zUsed by a parser or application to ensure received message is valid

9. Vendor Application Profiles zDefine how to use NCIP within a particular application domain zConform to an Implementation Profile zDescribes application area and participating applications zDefines the business rules zDefines required services zDefines required and conditionally required data elements

10. Vendor Application Profiles, con’t zDefines an event table and messages sent and received when those events occur zMay provide additional enumerated data types zDefines transport protocols zMay define security and privacy requirements zMay provide additional implementation guidelines

11. Vendor Application Profiles MAY NOT zRedefine data elements specified in the protocol zAdd additional messages zDefine new objects zDefine additional transport protocols zAdd data elements to messages zMake required data elements optional zSpecify a data type inconsistent to how its defined in the protocol or implementation profile

12. Technical Architecture z3 Service Types z3 Object Classes

13. 3 Service Types zLookup y“Tell me these things about this object.” zUpdate y“Please take this action.” zNotification y“I have taken this action.”

14. Service Definitions zEvery “Service” is a pair of messages: yan “Initiation Message” yand a “Response Message” zEach message provides complete context for it to be understood yThe protocol is designed NOT to require any particular sequence of services.

15. 3 Object Types zUsers zItems zAgencies (Libraries) zTransactions are associations between one or more of the objects

16. Lookup Service Type zLookup Agency zLookup Item zLookup User zAuthenticate User zLookup Version

17. Lookup Service Type zLookups are about a unique thing zThey do not support discovery or searching.

18. Update Services zTypical Update Transactions: yRequest Item and Cancel Request Item yCheck Out Item and Undo Check Out Item yRenew Item yRecall Item and Cancel Recall Item ySend User Notice yCheck In Item

19. Update Services zObject maintenance: yCreate Agency and Update Agency yCreate Item, Update Item and Update Request Item yCreate User and Update User yCreate User Fiscal Transaction zCreate Services used for new objects zUpdate Services include modify and delete

20. Notification Services zTypical Notification Transactions: yItem Requested and Item Request Cancelled yItem Checked Out yItem Renewed yItem Recalled and Item Recall Cancelled yUser Notice Sent yItem Checked In

21. Notification Services zObject maintenance: yAgency Created and Agency Updated yItem Created, Item Updated and Item Request Updated yUser Created and User Updated yUser Fiscal Transaction Created

22. Notification Services zItem Shipped zItem Received zCirculation Status Change Reported zCirculation Status Updated

23. Notification Response zNotifications occur after the fact - no ability to say “don’t do that” zOnly possible responses: yDid not understand message yUnderstood message

24. Mandated Action zFlag on Request Messages zUsed to turn a request into a de facto notification zMay require out of band handling

25. Syntax and Encoding zXML DTD zUTF-8 encoding of Unicode (UCS-2) yASCII is valid in this encoding. yBut other systems are NOT restricted to ASCII, and you should be prepared to receive such data.

26. Scheme/Values zMechanism for extensibility zProvides mechanism for NCIP to make use of other standardized lists zSome defined in NCIP Protocol zProvides ability for locally defined values

27. Schemes and Values zTwo kinds of Schemes: yClosed xMust be supported in order to conform xCannot be extended yOpen xCan be extended zFor many (but not all) data elements NCIP provides some lists that must be supported for interoperability purposes

28. Use of other Standardized Lists zLanguage Codes xDefined by ISO 639-2 Bibliographic Language Codes zCurrency Codes yDefined by ISO 4217 Codes for the representation of currencies

29. Allow for Extensibility z Bibliographic Record Identifier Code: xANBN xBGF xBNBN xCARL: UNCOVER xCN xLCCN xNLM TCN xOCLC xRLIN

30. Allow for Local Practice y Agency User Privilege Type (Public) xAdult xChild xSenior xStaff xYoung Adult yAgency User Privilege Type (Academic) xFaculty xGraduate xPostdoctoral xStaff xUndergraduate

31. Scheme Defintion zScheme names are URI’s zValues within any Scheme must be unique zOnce published, the list of Values must not change in any way - if changes are made a different URI is defined

32. Example Scheme/Value http://www.librarylist.org Needleman Library http://www.needleman.com/patrons Platinum User.

33. Datatypes zEach PCDATA element has a datatype associated with it zDatatypes are subset of those defined in W3C XML Schema Language: xdateTime xstring xpositiveInteger xnonNegativeInteger xInteger zIn DTD datatypes defined using #FIXED attributes zNCIP Schema uses “real” datatypes

34. Headers zEach message has a header yInitiation messages have an Initiation Header yResponse Messages have a Response Header zHeader provides for security and identification yFrom System and Agency yFrom System and Agency Authentication yTo System and Agency

35. Unique Id’s zAgency Id’s yRegistration scheme to ensure uniqueness yValue in Scheme zUser Id’s, Item Id’s and Request Id’s are compound; they include the Agency Id

36. Element Id’s zLookup initiation messages (except Lookup Version and Authenticate User) must include “Element Id” elements. zThese are used to specify “these things,” as in “Tell me these things about this object.” zElement Id can be used to ask for data about the object in other messages as well

37. Use of Element Id zOne of these for each object class: yAgency Element Id yItem Element Id yUser Element Id zEach of them has a corresponding Closed Scheme zIdentifies which elements of the object are desired in a Lookup service (or other relevant messages)

38. Element Id in a Request http://www.niso.org/ncip/v1_0/schemes/ite melementtype/itemelementtype.scm Bibliographic Description

39. Optional Fields in Response Mark Needleman 1st St Louis 2003 A Nobel Prize Winning Novel

40. Application Roles zFor a given connection, there is: y 1 and only 1 initiating application (e.g., self-service machine), and y1 and only 1 responding application (e.g., circ system). zInitiators may NOT send a second message until the first is responded to. zResponders may NOT send initiation messages EVER on that connection.

41. Application Roles zApplications MAY establish multiple connections at the same time. zThe Standard is written in terms of “initiating application” and “responding application”; this is always in the context of a given connection, not in the broader context of the application as a whole

42. Application Roles zInitiating application waits for the response message or a timeout. zApplications may keep the connection open in an “Idle” state in anticipation of exchanging a series of message pairs (to avoid the costs of establishing a connection for each exchange).

43. State Tables zDo NOT govern the state of the circulation transaction zDO govern the state of the exchange of the initiation/response message pair yInitiating application is in IDLE or WAITING state yResponding application is in IDLE or PROCESSING state

44. Messaging State Tables zINITIATOR RESPONDER IDLE WAITING PROCESSING IDLE Initiation Message

45. Messaging State Tables zINITIATOR RESPONDER IDLE WAITING PROCESSING IDLE Response Message

46. Transport Protocol Requirements zConfirmed Service yInitiation/Response message pairs yThe Response message confirms the service. zThe transport layer must indicate that the peer has disconnected.

47. Supported Transport Protocols zInitiator chooses from these 3: yTCP/IP yHTTP yHTTPS zResponder must reply on same connection - and thus using the same protocol with which it got the initiation message

48. Behavior Rules zDefinition of Success zOmission of requested elements zInclusion of unrequested elements zUpdate processing zError identification zMessaging errors zProcessing errors

49. Omission of Requested Items zApplies to entire Lookup Service Type and to “piggy-backed” lookups on Update Services. zPermits omission of some of the data the initiator asked for. zExample: Initiation message requests user’s date of birth but policy at responder does not allow it to be revealed

50. Inclusion of Unrequested data zSome elements in the messages are defined so the requester can specify what information it wants to get back yElement Id fields yInformation about holds on at item zResponder may not include such elements if not requested by Initiator

51. Update Processing zResponding application will behave as if all deletions requested were performed before all additions requested in the same message zIf an update to one element causes an update to another element not specifically asked - a Notification message may be used to inform the other side yExample - change of birthday causes user category to change

52. Errors zMessaging Errors zProcessing Errors

53. Messaging Errors zIndicate lack of understanding of the message: yInvalid XML yXML not conformant to the DTD yUnknown scheme

54. Processing Errors zIndicate inability or unwillingness to perform the action requested yUser Delinquent yUnknown item yItem does not circulate (Checkout) yMaximum renewals exceeded (Renewal)

55. Security zEncryption yHTTPS zAuthentication of Systems and Agencies zApplication Profiles can defined other security requirements and mechanisms

56. Support for Future Versions zVersion Attribute on each message to identify version - attribute contains the URI of the DTD or Schema it conforms to zLookup Versions to find out what versions the other side supports zResponder may (but is not required to) respond with list of supported versions if it gets a message in a version it does not support