If you haven't signed that RFID contract yet, you may want to set down your pen and check one thing....is the chip in your vendor's RFID tag capable of locking and password-protecting your content as well as the AFI and EAS registers? If not, don't sign that contract. Here's why....
You are here
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.