ILL Protocol Implementation Test Beds
Misc. Forms for Implementors
For More Information,
the ILL Application Standards
Library and Archives Canada
Interlibrary Loan Application Standards Maintenance Agency
Interlibrary Loan Application Standards: IPIG Suggestions for Change
This page lists areas of concern within the Interlibrary Loan Application Standards, where changes to the protocol may be required. These have been identified by members of IPIG who also act as the ILL ASMA Advisory Committee. However, before any formal Amendments are prepared for submission to ISO committees, more analysis and discussion within the advisory group are required. After formal amendment documents have been prepared, related topics will be purged from this list.
- "expiry-date" & "need-before-date": Time required as well as Date?
The protocol has defined Search-Type.expiry-date and Search-Type.need-before-date as implicit ISO-Date (format: YYYYMMDD). This was sufficient physical delivery was the only option and the delivery of requested items was expressed in terms of days, weeks or months. With the advent of electronic document delivery, the requirements for expressing the expiry date have moved to another level of granularity. System users need to be request the need for items and the expiry of requests in terms of both date and time (i.e., by 12 noon tomorrow), but the protocol does not allow for this and some modifications to the protocol standard will have to be made.
- Use of Local Time vs. Universal Time
The definition of ISO-time indicates that, in the ILL protocol (ISO 10161-1:1997 Clause 9.1.2, lines 701-706), it is the "local time of the person or institution invoking the service" that is to be used. However, in the current international interlending environment, it is desirable to supply time as Universal Time Co-ordinates (UTC) and let the local systems convert the time back to local time.
The definition of "ISO-Time" also indicates that ISO-time conforms to ISO 8601. However, the length of ISO-time is fixed at 6 characters (HHMMSS) and thus there is no way to append the additional character "z" to indicate that the time has been stated in UTC.
As a first step, the IPIG profile will state that implementors are to use UTC for all date and time stamps. And thus, the use of UTC will be implictly understood by all IPIG profile users, rather that explicitly expressed in the ILL apdus.
All instances of Time in the ILL Application Protocol Specification would need to be amended so that this can be explicitly expressed.
- Protocol Service: Unconfirmed or Confirmed?
Should the protocol be a confirmed service protocol?
What are the issues concerning this?
- Handling of Information on Errors in Delivery
There are delivery errors (no delivery, delivery of the wrong document) which are not covered in the ILL protocol specifications? Are these scenarios within scope of the protocol specification? If so, how should they be handled? Is there a requirement for another APDU or an enrichment of a current APDU?
- Delivery-Address/Delivery-Service: Inconsistency in treatment?
Is there an inconsistency between the treatment of the data parameters Delivery-Address and Delivery-Service. Delivery-Address is a CHOICE while Delivery-Service is a SEQUENCE?
Although the user can specify more than one Delivery-Service. physical-delivery within the ILL-string, if desired, one cannot specify both physical and electronic delivery details
(to be used by the responder as alternatives). Because Delivery-Service is a CHOICE of physical-delivery or electronic-delivery, the requester cannot specify physical-delivery service(s) as an alternative to (several) electronic-delivery-services.
For instance: the requester might want to say "send it to me via Ariel or
Fax but if you cannot do either of those then courier or post it to me." It would not be unusual for the supplier to try hard to Fax an item but continuously fail (machine out of paper?). So a fall-back physical delivery route is a real necessity for practical ILL.
The ILL Application Service Definition (ISO 10160 Clause 22.214.171.124.7 Delivery Service says
"If electronic delivery of the item is required or desired, ..."
The "desired" implies that the requester may have a preference for electronic delivery but not a necessity. The ASN.1 in the Protocol Specification does not currently permit this flexibility to be expressed. This inconsistency could be corrected by changing the Delivery-Service from CHOICE to SEQUENCE.
A related change of the text in ISO 10160 Clause 126.96.36.199.7 would then be required to indicate that the preference "...is one of the electronic-delivery-services then physical-delivery".
This coding was added in Amendment 1 to ISO 10161:1993, and parallels the coding for the "Supply.Details.shipped-via". However, the circumstances are not parallel. While one can specify only actual delivery service used to ship the requested item, there is a need to specify a potential physical transportation mode along with the one or more electronic delivery services which the requester requires or desires.
Addition to enumerated list for ILL-ANSWER.Results-Explanation.Unfilled-Results.Reason_Unfilled
To some IPIG implementors, there appeared to be no place for a responder to indicate, as a reason why a request is unfilled, that the iLL-service-type specified in the ILL-REQUEST is not supported.
This message would be used by applications that do not support a specific type of ILL service, such as a library that does not provide cost estimates or locations, or a document supply company that does not supply loans. It is in keeping with the pattern established in the enumerated list of indicating the non-support of other ILL functions.
Current Canadian implementors indicated that they use the value policy-problem. This value, by definition, indicates that there is no policy in place to permit the completion of the request. It requires, in addition, eye-readable explanatory text that is carried as a note.
- Responder Optional Messages
(for diagnostic purposes)?
ISO 10160:1997 Clause 188.8.131.52.12, contains the parenthetical phrase "(for diagnostic purposes)". By the inclusion of this phrase, the reason for specifying the Responder Optional Messages is limited to use as a diagnostic. This limitation is questioned. For this reason, the wording of this clause should be reviewed.
- Intermediary Receiving Conditional Response of "NO"
Within the protocol, there doesn't appear to be a way to handle the continuation of a transaction when an intermediary receives a conditional answer "NO" from a requester, without terminating the transaction. In fact, the protocol specification indicates quite precisely in ISO 10161-1:1997 Clause 8.3.2, that the transaction terminates.
"An ILL-ANSWER.indication with a value of CONDITIONAL is to be mapped onto the main ILL-transaction ILL-ANSWER.request.
It is not clear to the current editors why this restriction was placed on the protocol, although it may have been an attempt to keep the protocol simple. There are scenarios where this action would be quite valid (for example, when an intermediary has not exhausted a list of potential suppliers to whom the ILL-REQUEST could be sent).
However, the changes required to handle continutations of the transaction appear, on first examination, to be substantial (a new predicate et al). Therefore, this is added to potential changes for the next edition of the standard, rather than attempting patchwork at this time.
A subsequent CONDITIONAL-REPLY with the value NO is to be mapped onto the sub-transaction. Note that in ths case the intermediary may not initiate a new sub-transaction with another responder."
- Retract a SHIPPED Transaction?
Would like to be able to retract a shipped transaction, to allow for the situation where you may need to specify that you have shipped an item more than once. -- Suggested by Jacob Hallen at the IPIG meeting, Lacey WA, Dec. 1998.
- Status-reports won't change history
Would like to treat the STATUS-OR-ERROR-REPORT.Status-Report the same way as a STATUS-QUERY. That is, do not record the service as most-recent-service."
The most-recent-service would remain as the one prior to the status-report. Or, if the Status-Report was provided in response to a STATUS-QUERY, the most-recent-service would remain as the one prior to the STATUS-QUERY.--Suggested by Mark Wilson at the IPIG meeting, Lacey WA, Dec. 1998.
- Handling Estimate information
Some vendors would like the means to carry estimate information as machine-comprehendible strings. There was some attempt to develop a parsable string, but it was recognized that the data supplied was too diverse for a simple extension of code to handle it well. In the interim, the parameter is left as an ILL-String, free text and human-readable. -- Final word on this was e-mail from Barb Shuh dated 27 January 1999; see also input from Jacob Hallen, Richard Wilson and Ed Davidson.
- Client-Id required in SHIPPED APDU?
ISO 10160 Clause 184.108.40.206 specifies that the client identification parameter is mandatory if it was present on the initial ILL-REQUEST indication. There are two concerns for this spec.: this information is redundant, as the Requester should know the identity of its clients and be able to correlate specific ILL-transactions with the clients who have requested the item. As well, there are concerns that the inclusion of this information may contravene privacy legislation in certain jurisdictions.
Should the clause be revised to remove the mandatory requirement? --Issue first raised by Michael Carroll, RLG, 25 August 1997.