ISO 10160/10161-1 Review White Papers

Undo Functionality

• Randy Menakes (Group Leader)
• Kerry Blinco
• Ed Davidson
• Lyse Pérusse

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. There are a few situations when a transition will move from state A to state B, and then back to state A. For example, a transaction on the Responder side can move from PENDING to CONDITIONAL and back to PENDING (upon receipt of a C-REP+). But in general, state transition is one-directional. 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.

The ILL Protocol Implementors Group believes that the next version of the Protocol should investigate whether allowance might be made for undoing state transitions. To discuss this, we need to consider two different situations:

1. The undoing of a state transaction when the request is now in a terminal state.
2. The undoing of a state transaction when the request is now in a non-terminal state.

Terminal State considerations

Several factors make it impossible to back a transaction out of a terminal state. Once an APDU from a Responder moves the transaction into a terminal state, the Responder can no longer predict behavior on the Requester side. Consider the following example:

1. Responder responds to an ILL-Request with an ILL-Answer/Unfilled
2. Responder realizes that the message should have been ILL-Answer/Will Supply

The Responder may wish to undo the results of the receipt of the ILL-Answer/Unfilled on the Requesting side, but the Transaction has already moved to a terminal state of NOT SUPPLIED. The Requester application may have already sent a (referral) request for the same item to another provider. Furthermore, the Protocol states that a request in a terminal state may be deleted or otherwise made inaccessible to the peer. When this occurs, the request is no longer available for undoing.

Terminal states for the requester are:

• NOT-SUPPLIED
• CANCELLED
• RECEIVED (non-returnables)
• RETURNED
• LOST

Terminal states for the responder are:

• NOT-SUPPLIED
• CANCELLED
• FORWARD
• SHIPPED (non-returnables)
• CHECKED-IN
• LOST

Terminal states for the intermediary are:

• NOT-SUPPLIED
• CANCELLED
• FORWARD
• SHIPPED

Since one requirement of a new version of the Protocol is that it be backward compatible, this aspect of terminal state behavior seems inviolable. The only 'workaround' for these is probably to devise additional states (and corresponding APDUs) that would represent non-terminal versions of these states. LOST seems a likely candidate for this treatment, with the definition of a new, non-terminal state such as 'APPEARS LOST'. This state would be 'recoverable'. For example, the state tables would permit receipt of a Checked-in APDU if the item shows up at the Responder side. Each terminal state should be examined to determine whether a parallel, non-terminal state should be defined.

Non-Terminal State considerations

• Sending a Shipped APDU for the wrong item (returnables only)
• Sending a Received APDU for the wrong item (returnables only)
• Sending a Recall APDU by mistake
• Sending an Overdue APDU by mistake

Although support for undoing these non-terminal states may be feasible, it's likely that the already complex state tables will be made considerably more complex.

Forwarding and Intermediary considerations

To date, the IPIG has declared the Forward Service and most Intermediary behavior out of scope. If the Group chooses to investigate adding 'Undo' functionality to a new version of the Protocol, it will have to take Forward Service and corresponding Intermediary behavior into account, since it will undoubtedly prove to be the most complex impediment to expanding the Protocol to permit reversal of state transition.