IPIG Meeting, 4-5 June 1998. Agenda Item 11.3
Jim McDonald, OCLC, posted the following message on the non-protocol message extension to the IPIG Mailing List on 18 February 1998. He noted that he had looked into the possibility of sending the patron requests instead of requester notification messages and found it was not feasible.

Non-Protocol messages needed to support OCLC ILL

Requester Notification.

This is needed to support ILL requests that have been created interactively, or from FirstSearch via the ILL Direct Request(IDR) service, where the requesting institution is profiled as a OCLC Distributed ILL requester. This message will consist of an ILL-Request apdu, with a requester-notification extension. The critical element must be set to TRUE, and the requester-id must match the receiving institutions system-id. When a requester receives this message, the ILL Protocol machine should be bypassed and the data should be sent to the ILL application. The ILL application is then expected to do everything associated with an ILL-Request service except sending the apdu. The transaction-Id will have already been created. The requester should send a cancel apdu if the transaction-id assignment is a problem. This message can only be sent if the ILL staff has either set up a ILL Direct Request Profile record specifying that requests should be sent directly to the lender, or if an ILL request was created interactively on OCLC ILL.

Requester-Notification-Extension DEFINITIONS ::=
  -- the object identifier for this extension, registered with
  -- the ILL Registration Authority, is 1.0.10161.13.?   if registered
as a public object,
  --                                                    or
1.0.10161.13.1000.2.3 if registered as a private object

 BEGIN

 IMPORTS ILL-String FROM ISO-10161-ILL-1;

 Requester-Notification-Extension ::= SEQUENCE {
   note                            [0]   ILL-String
}

END

Patron Request

This is needed to support ILL review records that have been created interactively, or from FirstSearch via the ILL Direct Request(IDR) service, where the requesting institution is profiled as a OCLC Distributed ILL requester. This message will consist of an ILL-Request apdu, with a patron-request extension. The critical element must be set to TRUE, and the requester-id must match the institutions system-id. When a requester receives this message, the ILL Protocol machine should be bypassed and the data should be sent to the ILL application. The processing of this data is not specified.

Patron-Request-Extension DEFINITIONS ::=
  -- the object identifier for this extension, registered with
  -- the ILL Registration Authority, is 1.0.10161.13.?

 BEGIN

 IMPORTS ILL-String FROM ISO-10161-ILL-1;

 Patron-Request-Extension ::= SEQUENCE {
   note                       [0]   ILL-String
}

END

Service Request

This is needed to support OCLC ILL system commands that have been performed interactively, where the institution is profiled as a OCLC Distributed ILL user, and the command corresponds to an ILL-Service that should have been performed at the Distributed ILL system. This message will consist of an apdu, with a service-request extension. The critical element must be set to TRUE, and the requester-id(for requester apdus) or responder-id(for responder apdus) must match the receiving institutions system-id. When this message is received, the ILL Protocol machine should be bypassed and the data should be sent to the ILL application. The ILL application is then expected to do everything normally done for that service request.

The following apdus may be sent with the service-request extension.

Service-Request-Extension DEFINITIONS ::=
  -- the object identifier for this extension, registered with
  -- the ILL Registration Authority, is 1.0.10161.13.?

 BEGIN

 IMPORTS ILL-String FROM ISO-10161-ILL-1;

 Service-Request-Extension ::= SEQUENCE {
   service	[0]    IMPLICIT ENUMERATED {
                	sHIPPED 		(3),
                	iLL-ANSWER 		(4),
                	cONDITIONAL-REPLY 	(5),
                	cANCEL 			(6),
                	rECEIVED 		(8),
                	rECALL 			(9),
                	rETURNED 		(10),
                	cHECKED-IN 		(11),
                	rENEW 			(13),
                	rENEW-ANSWER 		(14)
                	},
    note	[1]  ILL-String
                    }
END