Harmonization of Library Protocols

I just got back from attending my first NCIP Standing Committee meeting at OCLC headquarters in Dublin, Ohio.  It turned out to be a far better experience than I could have imagined. The people working on this committee are dedicated to making NCIP the "go-to" protocol for communications with the ILS/LMS. My objective going there was to possibly challenge that idea insofar as my intention was to introduce them to the Library Communcation Framework (LCF) - a protocol being developed in the U.K. by people who aspire to make LCF the library "go-to" protocol.

But instead of resistance to LCF, the NCIP folks were open to learning more about the problem that LCF is trying to solve to see if it might suggest a direction that NCIP might need to go.  I explained that LCF was largely driven by RFID vendors who were too limited by SIP2.  It is my sense that the LCF folks don't really understand all that NCIP is designed to do, nor do they understand how open the NCIP folks are to extending support for new RFID functions.  They may also just generally be suspicous of all things NISO.

So, allow me to talk more about why I now believe that NCIP is where we should be focusing our energies when it comes to a standard library protocol. 

Even though SIP2 is the most pervasive library communication protocol, NCIP2 can do everything that SIP2 can do.  Plus it can do it with encryption and it is lots more flexible than SIP2. NCIP can also do everything SIP3 can do.  While SIP3 fixes some of the more egregious problems with SIP2 (extensions, lack of encryption), it is still not extensible like NCIP is. SIP is a protocol that needs to be sunsetted. When NISO accepted SIP3 from 3M, they just muddied the waters and made it that much more difficult for NCIP to gain momentum.

NCIP got a bad rap because the first version didn't work very well. It was a big, monster (especially compared to SIP2).  But version 2 fixed that issue. NCIP 2.01 (current version) is highly extensible, secure, flexible, and very manageable.  Even so, vendors have shunned it in favor of SIP2 except when they couldn't avoid it.

SIP2 doesn't support services related to resource-sharing so that's where you find NCIP.  NCIP is used between ILS and ILL software ("C-ILL") and also between ILS and ILS ("Direct Consortial Borrowing"). But, like SIP, NCIP can also be used to support self-service.  And there is a lot of overlap between the needs of self-service devices and resource-sharing systems. 

For example, "Check In Item," "Check Out Item," "Lookup Item," "Lookup User," and "Renew Item" are services that are part of NCIP's core services for ILS-to-ILS , ILS-to-ILL, as well as self-service communications. Once a vendor writes support for these five services, they are well on their way to supporting NCIP.  If they add support for just four more services ("Create User," Create User Fiscal Transaction," Undo Checkout Item," and "Update User" they could stop fussing with SIP entirely.

AND.  Having developed support for the five core NCIP services, they could also support ILS-to-ILL and ILL-to-ILL communication by adding just four services specific to resource-sharing. 

There's more about NCIP that makes sense in this day and age regarding encoding and transport and other things that are bit beyond me still but the point is that they are designed with state-of-the-art Internet technologies in mind.  SIP is not.

The point is that we need to urge all of our vendors (self-service, ILL, discovery, and RFID) to support NCIP.  That's the direction we should be going. You may end up using SIP2/SIP3 for a while longer but ultimately NCIP is where its at for all of the above communciation needs.

NCIP has the possibility of being the de facto protocol for all library communications.  Just as a set of services and messages have been defined for ILS-to-ILS, ILS-to-ILL, and ILS-to-Discovery communications, we could also use it for specific RFID communications (e.g. Inventory Device-to-ILS, or RFID Acquisitions and Receiving Communications).  The LCF has given us an excellent roadmap for where we need to extend the NCIP schema.  LCF defines the service, data elements, and messages we need to leverage RFID technology. I want to take LCF's contributions and build upon NCIP. That's what makes sense to me.

Now, putting the people who developed LCF into a room with the people who've developed NCIP is my next big challenge.