ISO 10160/10161 Review:

Decision at ISO TC46/SC4 Meeting, October 2004: Because the DIS ballot on the ILL Protocol revision produced several negative votes due largely to the incompatibility between it and the previous version, work will be undertaken to assure upward compatibility over the next 6 months and then a second DIS ballot will be conducted. SC4 document N 567 and N568 (on the SC 4 document log) are the final reports on the first DIS ballots.

Supporting Documents for the Revision:

Editorial Comments (for draft of 31 August 2001):

Access to these documents is restricted to members of the Advisory Committee for the Interlibrary Loan Application Standards Maintenance Agency and is password-protected. Contact the ILL ASMA for further information on the work of this group.

ISO 10161 Information and documentation -- Interlibrary loan application -- Part 2: Protocol implementation conformance statement (PICS) proforma

Latest Version

Interlibrary Loan Application Standards: IPIG Suggestions for Change

ISO 10160/10161-1 Review White Papers

At the Mountain View meeting of IPIG (26-28 April 2000), the group spent an afternoon brainstorming, identifying issues that should be considered during the revision of the ISO ILL Protocol. In all, eight areas of potential change were identified. No attempt was made to discuss the merits of each at that time. Instead, ad hoc groups were formed to study each area and prepare white papers to provide background information covering both sides of the issues surrounding each topic. With this background information in hand, IPIG as a whole can begin to consider the implications of these potential changes at the next meeting in Ottawa (August 23-25). The ad hoc groups are working towards a deadline of 31 July 2000 for the posting of the white papers. IPIG, as Advisory Committee to the ILL ASMA, will made recommendations on any revisions to the protocol that will need to be addressed by the Maintenance Agency when preparing the next edition of the ILL Application Standards.

The work done here will be reflected only in the next generation of ILL systems to be developed sometime midway through the first decade of this new millenium.

The eight areas identified are listed below. Group leaders have prepared brief summaries of the areas to be discussed. Other developers of Interlibrary Loan systems are welcome to participate in these online discussion groups. Contract the group leader (identified by *) to ask to be added to a discussion group.

Contact info for Group Leaders:

• Dave Richards: br.drr@rlg.org
• Joe Zeeman: joe.zeeman@columbatech.ie
• Randy Menakes: randy@exlibris-usa.com
• Mark Needleman: mneedleman@dra.com
• Kerry Blinco:  K.Blinco@ibm.net

White Papers

Supporting Communication Services

Dave R.*, Craig W.

The standard requires support for BER-encoded ASN.1 as the message transfer syntax, and optionally allows use of EDIFACT encoding for communication with older implementations. It is probably time to remove the EDIFACT option from the standard.

The standard is largely silent on how messages are to be transferred between systems. IPIG has profiled both use of MIME mail (required) and direct communication via TCP connection (optional). While the standard should not exclude use of other mechanisms in the future, should it be prescriptive about how to use these two transport services?

Should SMTP Delivery Service Notifications (DSN) and Message Disposition Notifications (MDN) be utilized to provide confirmation of email transport? (MDNs provide for acknowledgement of e-mail acceptance, rejection, etc. from an e-mail client. DSNs provide acknowledgement of success/failure from a message transfer agent.)

Confirmed vs Unconfirmed

Joe Z.*, Mark N., Eric F.

Undo functionality

Randy M.*, Kerry B., Ed D., Lyse P.

The concept of “undo” in the ISO 10160/10161 implies undoing or reversing a change in the state of an ILL-transaction. Version 2 of ISO 10160/10161 does not allow for the undoing of most state transitions. The state tables make no allowance for return to a prior state because an operator error was made, or because of an unanticipated occurrence, like the discovery of material that had been declared LOST in Protocol terms.

This paper will investigate whether the protocol should allow for undoing state transitions. Two situations are to be considered:

• The undoing of a state transaction when the request is in a terminal state.
• The undoing of a state transaction when the request is in a non-terminal state

Ease of Implementation

Mark N.*, Art Z.

ISO ILL has been specified using ASN.1/BER. The messages are described in the abstract using ASN.1 and one of the mechanisms for encoding them is BER. There has come to be a perception (at least among certain communities) that this has contributed to the difficulties in implementing the ILL protocol. ASN.1 is sometimes thought to be arcane, difficult to understand and outdated technology. It requires specialized compilers or other tools to process, and since the ILL protocol also uses an older version of the ASN.1 standard, there is a sense that it may become increasingly more difficult to find tools that support ASN.1. BER produces an encoding stream that does not easily lend itself to human consumption, requiring specialized skills and training to be able to read and debug. There is also the major concern that, as time goes by, it will become increasingly difficult to find technical people who understand ASN.1, or to train people in it since they may feel, that since it is outdated and non mainstream technology, that is not a good career move to get involved with it.

This paper will examine these and other issues involving the ease of implementation of the ISO ILL protocol and discuss some of the tradeoffs between continuing to use technologies like ASN.1/BER in the next version of the ISO ILL protocol, or migrating to more current encoding technologies like XML. Other issues that may not be directly related to the issue of encoding technologies will also be examined. The goal of the paper will be to raise and discuss all of the issues that may be related to how hard it is to implement the ISO ILL protocol given its current nature and structure.

Security / Authentication, Encryption

Dave R.*, Jacob H., Art Z.

The standard does not address authentication of message senders.This is likely to be an issue for some users of systems implementing the protocol. Libraries also have safeguarded the privacy of patrons; encryption of ILL messages is needed to support this aim.

For email transport, secure MIME (S/MIME) provides a framework based on digital certificates that supports authentication, non-repudiation, and encryption. Analogous security mechanisms for direct TCP connection could be provided by SSL. Should the standard specify how these are to be used?

Optional messages

Joe Z.*, Barb S.

Version 1 and version 2 of the protocol both include a number of protocol messages whose delivery to the partner system is declared to be optional, even though the services themselves are required to be revoked. These optional messages have led to significant complications in the protocol in order to accommodate their potential absence, and have been a major contributing factor in the perceived complexity of the protocol from an implementation point of view. This white paper will seek to address the following questions.

• What is the original rationale for the optional messages?
• Has the environment changed sufficiently (since the early 1980’s) to invalidate the original rationale?
• What requirement is there for backward compatibility?
• Does there still need to be any accommodation for lost/out of sequence messages?
• How would the state table look if there were no optional messages?

Operational Models

Joe Z.*, Kevin G.

The ILL protocol currently supports at least 4 models for the operation of an ILL network or consortium:

• Simple point-to-point messaging involving only two parties at a time
• Point-to-point messaging in which the receiving party may forward a message onto a third party
• Intermediary-based messaging in which the intermediary system undertakes to find a responder for a request (partitioning)
• Intermediary-based messaging in which the intermediary system plays a role through the lifetime of the transaction.

This white paper will address the following questions around the operational models of ILL to be supported in the next version of the standard.

• Does the standard need to continue supporting all these models
• Are there functioning systems out there that use a different operational model?
• Do these need to be supported by the standard?
• Can any other standards meet any or all of these operational models?
• Can we use our current assumptions that network bandwidth and networks charges are not an issue to simplify the operational model of the standard?

• What are the protocol implications of any change in the underlying operational models?

Support of automation

Kerry B.*, Ken V., Lyse P.

For the purposes of this white paper, automation includes

• interaction of the ILL application with the Protocol Machine, such as automatic invocation of events in response to incoming messages and state changes generating state changes and protocol messages in response
• interaction of the ILL application with the Protocol Machine to identify situations where human intervention is required and an operator should be alerted:
• interaction of the ILL application with the Protocol Machine to provide support for efficient application operator workflows
• interaction between ILL Protocol Machines required to support the above

The capability of developers to build ILL applications that maximise automation is limited by the features of Version 2 of ISO 10160/10161. Implementors groups have attempted to address some of these limitations by defining scenarios and defining guidelines that restrict the use and content of protocol messages, or define the interpretation of sequences of protocol messages.

This white paper will identify areas where changes/additions to the Protocol could improve support of automation and discuss issues arising from these changes/additions. The areas addressed may include:

• Protocol messages that do not force a change state but require attention by a human
• Use of ILL-Message, or repeat protocol message with a change of note used for commonly occurring events
• The Requester can not now resend/update initial encoded request information to update the initial request, either to change the service requested or fix errors in the initial request
• The Requester can not now resend/update initial coded request information in response to negotiations between the Responder and the Requester to change the terms of supply
• The authority of a response can not be qualified so that the Requester can decide how to act on the response
• Conditions where not only the State, but the value of responses determines the next action on a request
• Instances where the Protocol is silent.