SIP2 over https
SIP2 further development: To provide ability to develop more versatile and agile self-service concepts and processes for the staff, it would be useful to take into use ‘SIP2 over HTTPS’ in Alma. The basic message between library automation and Alma would still be in accordance with the standard 3M/NISO, but message pairs would be encapsulated in XML.
Pertti Föhr
shared this idea
This depends on the adoption of http by self check machine vendors. We will need to collaborate with such a vendor.
-
Daniel Sandbecker
commented
The linked guidelines are really misguided. The XML-embedding is plain overhead and would require any implementation to use both XML-parsing and SIP2-parsing (and the same for encoding) while providing no benefit what so ever over using HTTPS with plain SIP2.
Essentially it provides two attributes to the message, "login" and "password", and a choice between three elements to define if the message is a "request", a "response" or an "error". The SIP2-message is still plain SIP2, not SIP2 semantics expressed in XML, which would have been the only way XML might be useful here.
- That a particular message is a request or a response is already implicit by the SIP2-message and made explicit by the HTTP-protocol.
- Errors are expressible both in HTTP (both client errors and server errors) and SIP2 (checkums for validation of the message and semantical errors in the response flags).
- Options for authentications is present both in the HTTP protocol (basic auth, authorization headers) and in the SIP2 message format (field "AC" == terminal password).Please Ex Libris, if you implement SIP2 over HTTPS, do *not* follow the linked guidelines, but just use the plain SIP2-messages as the body of HTTP-requests/-responses.