Your LMS decides. The kiosk only asks
RFID equipment holds no borrower data and no lending rules. It reads a tag, asks your library management system whether the transaction is allowed, and applies the answer. The conversation runs over SIP2, NCIP or a REST API. That is the whole architecture, and understanding it removes most of the misunderstandings that arise with an LMS vendor during a project.
Who talks to whom, from tag to catalogue
An RFID project stacks four layers. Knowing which one holds the decision is what keeps a specification honest.
SIP2 in practical terms
SIP2, the Standard Interchange Protocol version 2, was published by 3M in the 1990s and became the de facto standard for self-service. It is plain text over TCP, conventionally on port 6001, structured as numbered request and response pairs with two-letter field identifiers.
A checkout is message 11, the answer is 12. A patron status enquiry is 63 and 64. A check-in is 09 and 10. Inside the message, AO carries the institution identifier, AA the patron, AB the item and AJ the title. That is genuinely all there is to it, which is both its strength and its weakness.
Three things follow, and they matter at procurement time.
SIP2 has no native encryption. Borrower identifiers and item identifiers cross the network in clear text. On a closed local network that is usually accepted; across sites or over any public link it is not. Ask explicitly how the link will be protected, whether by a VPN, a TLS tunnel or a dedicated VLAN, and get the answer in writing.
Character encoding is the classic failure. SIP2 predates general Unicode adoption. Accented titles, and any title in a non-Latin script, are where a working demonstration meets a disappointing production run. Test with real titles from your catalogue, including the awkward ones, before acceptance.
Implementations differ. SIP2 is a standard that vendors have extended in their own directions. Two systems both described as SIP2-compliant will not necessarily support the same optional messages. Renewals, holds handling and fee payment are where the differences show up.
What NCIP adds
NCIP, standardised as ANSI/NISO Z39.83, is XML over HTTP and covers a broader functional scope, including inter-library circulation. It is more modern and more expressive. It is also less uniformly deployed, and its application profiles mean that two NCIP implementations can differ as much as two SIP2 ones.
Our practical advice: do not choose between them in the abstract. Ask your LMS vendor which of the two they actually support in production, for the specific operations you need, on the version you are running. That answer decides, not the protocol's reputation.
The question to ask your vendor, in writing
One question, five parts, and it saves months.
- Which interface do you expose on our current version: SIP2, NCIP, REST ?
- Which operations are supported: issue, discharge, renewal, patron status, holds, fees ?
- Is there a licence cost or a limit on the number of connected devices ?
- How is the link secured, and what is your position on clear-text transport ?
- What is your lead time to enable it, and who performs the acceptance test ?
Interface activation on the LMS side is, in our experience, the critical path of most projects. It is not difficult work; it is work that has to be scheduled by somebody who is not us and not you.
Systems we have worked alongside
In France and the Benelux, the systems that come up most often are Koha, Decalog, Orphée NX, Syracuse, Nanook, PMB and Bokeh. Internationally, Alma and Sierra. The Lyngsoe staff workstation datasheet additionally lists Aurora, Bibliofil, Book-it, Cicero, Integra, Library, Micromarc, Quria, Voyager and Axiell as proven integrations.
A system absent from that list is not thereby incompatible. The list reflects integrations the manufacturer has performed, not a restriction. What matters is whether your system exposes one of the three interfaces, and on your version.
Our French pages document each of these systems individually. If you are running one of them and want the detail in English, ask us and we will send it.
Related pages
RFID standards
What ISO 28560 parts 1, 2 and 3 actually specify, how ISO 15693 differs from it, what the French IDRABIB…
Read →Accessibility
Published WCAG, Section 508 and EN 301 549 conformance for Lyngsoe Central Management and Sorter Controller,…
Read →How a project runs
The seven stages of a library RFID project, what decides the timeline, and the two steps that are always…
Read →The questions that come up every time
Does the equipment store borrower data ?
It processes an identifier in order to ask the LMS a question, and it logs transactions for statistical purposes. Whether those logs allow a borrower to be identified, directly or by correlation, is a question for your data protection officer, and it should be settled before go-live rather than after.
What happens if the LMS is unavailable ?
The kiosk refuses the transaction rather than recording one the catalogue knows nothing about. Some vendors offer an offline mode; it creates reconciliation work afterwards, so we would rather you chose it knowingly than discovered it.
Is SIP2 obsolete ?
It is old and it is limited, and it remains the most widely and consistently implemented interface in the field. In practice most installations still run on it. NCIP and REST are better answers where your vendor supports them properly on your version.
Who pays for enabling the interface ?
That depends on your LMS contract. Most vendors enable SIP2 without a surcharge; some charge per connected device. Ask before you write the specification, because the answer can change how many kiosks you can afford.
Tell us about your library
Collection size, annual transactions, the LMS you run and your timescale. Four figures are enough for us to say what is relevant to you, and what is not.