SIP 3.0 Ready for Implementation

SIP3 has just been released and it provides many new messages which means communication between ILS/LMS and your self-check, sorters, security system, PC management system....will be easier to implement and you'll have more options.  That is IF your ILS vendor supports it!  

So, make sure you start adding a requirement for SIP3 support to your procurement documents.

Here's what's new:

• allow creation / registration of patrons from self-service devices
• allow patrons to update their PINs / Passwords from a self-service device in the library
• allow patrons to update their home addresses and phone numbers
• support for handling electronic resources
• support for staff overrides on self-service circulation
• support for sortation systems
• support for PC Management systems
• added some other new messages simplify implementation and clarify usage
• added Undo Checkout and Undo Check-in messages to simplify implementation. It has been confusing for many developers to send a Check-in w/cancel flag to cancel a Checkout and send a Checkout w/cancel flag to cancel a Check-in. This was confounded by the fact that many ILS vendors did not support cancelling a transaction and would then proceed as a standard check-in (if cancelling a checkout) causing the patron to be removed from the hold list.
• added Off-line Checkout and Off-line Check-in messages to support off-line processing
• added Unsupported Message Response to indicate that the message request is not supported by the library system
• added Grouped data.  Data can now be grouped to provide all information required for a specific event. For example, a fee consists of the following fields: fee identifier, currency code, fee amount, and fee type. These fields can now be grouped together to simplify the passing of multiple fees on a single request or response message. Each set of group data starts with a group identifier and ends with a group end field.

I've attached the two parts of the protocol.  Part I describes the messages that are part of the protocol.  Part 2 describes the transport mechanism.  Libraries should familiarize themselves with Part 1 to they know what the new capabilities are.  SIP 2.0 and SIP 3.0 are not compatible so you'll need to migrate from one system to the other. 

My hope is the SIP 3.0 doesn't go the way of NCIP which was essentially ignored by the library community.  Granted, there were some practical problems with NCIP 1.0 that NCIP 2.0 has addressed. But still, the vendors need to hear from libraries. They need to know how important the new functionality made possible by these new standards and protocols is...otherwise, why would they bother to implement them.

So, take a look at Part 1 and think about what you could do differently with some of those messages that you can't do now.  Or, maybe you can do it now but it doesn't work very well.  

Let your vendor know that SIP 3.0 functionality is important to you.