Extensions

SIP2 explicitly provides for extensions: Unknown field identifiers are to be skipped, not treated as an error. Everything described here rests on exactly that.

This profile follows three rules:

1. Every field of its own begins with X. SIP2 assigns no identifiers with that initial letter, so a collision with the protocol is ruled out – today and later.
2. No fixed field is altered. Length, order and meaning of the fields without identifier stay as SIP2 describes them. Touching them shifts the entire message for every foreign device.
3. Every field of its own is dispensable. A device that knows none of the extensions works fully – it receives less information, but never wrong information.

The extension fields#

XK and XL – type of identifier#

The SBC standard knows three identifiers side by side for an item: the barcode number, the accession number and – since RFID – the serial number of the transponder. The same applies to the patron card.

SIP2 has exactly one field for this: AB for the item, AA for the patron. Which of the three it holds cannot be seen from the message. As long as a library uses only one kind, a setting in the library system is enough. But as soon as a device works in mixed operation – barcode scanner and RFID reader – the approach fails: A twelve-digit transponder UID can be formally valid as a barcode number and then hits a different item.

XK and XL remove the guesswork. If the information is missing, the setting in the library system still applies – older devices run unchanged.

XP – PIN#

For checking, SIP2 knows only AD, the patron's password. In practice these are two different things: a password with which the patron signs in to the online catalogue, and a short PIN they enter on the numeric keypad of a unit.

Carrying both in the same field forces the library system into an either-or setting. With XP a library can offer both.

XZ – transaction number#

The transaction number is the key under which a checkout is held in the library system. A device does not need it to work – but anyone clarifying a disputed transaction finds it instantly. It therefore belongs on the receipt and in the device's log.

XH and XD – account information in brief#

Both could be derived from the item list – but a device would have to request and evaluate the complete list to do so. That is a lot of effort for two figures that appear on every account screen; on an account with sixty items it is noticeably much.

XE – character set#

SIP2 names code page 850 as its character set and adds that anything else must be "mutually defined" by device and library system – a way of doing so during operation is not part of the protocol. In practice this means two settings in two places, and woe betide if they disagree. Set wrongly, it shows up as mangled umlauts in titles and patron names.

XE turns this into a question and an answer. The device states what it can do in the system status, the library system answers with what applies. If the field is missing, Windows-1252 applies – which is why two systems that know nothing of it still understand each other.

Two provisions make UTF-8 safe in the first place, and both are set out in the message structure: Fixed fields stay ASCII, and the checksum runs over bytes. UTF-8 therefore changes nothing about the way of counting – an umlaut weighs two bytes there, and exactly those go into the sum.

XM – operating mode#

A library system in its daily closing is reachable but not ready for transactions. SIP2 has no value for this intermediate state: It can only be imitated by setting checkout and check-in to N individually – but then the device faces the same picture as with a library that offers no self-service at all.

XM tells the two apart. With MAINT the device knows it may ask again later and can tell the patron it will work again shortly.

XS, XU and XF – identification of the library system#

These three fields are attached to every response and tell the device whom it is talking to. That helps first of all with troubleshooting: The trace states which version answered. Beyond that, XU makes it possible to recognise a device that is too old before it sends messages the other side cannot understand.

XSbvssip/3.0.541|XUX3.0.400|XFcheckout,returns|

Checklist for manufacturers#

Anyone developing a device against this profile should work through these points:

• Does the sequence number of the response match the one sent? Responses with a differing number are to be discarded, not evaluated.
• Is the checksum verified and 97 sent on error?
• Are unknown field identifiers skipped rather than treated as an error?
• Is BX from the system status evaluated instead of sending unsupported commands on the off-chance?
• Is AF displayed unchanged instead of phrasing messages of one's own?
• On checkout, is the security deactivated only after a 1 in the result flag?
• Is the device's own clock set by the date/time sync from response 98?