Miscellaneous Background Discussion on Agenda Items for Dublin Meeting of IPIG, 2-3 December 1999

Agenda Item 3a: Generalized IPIG-ILL-Request-Extension

Linda Driver: 1999/11/18

At a previous IPIG meeting, we talked about generalizing some of the extensions. I noticed that there is some overlap between the new BL-Collection extension and the OCLC-ILL-Request-Extension.

RLG also has similar needs to identify material types not handled well in the protocol. We also need to communicate information about payment methods, which are not handled at all in the protocol.

Could we collaborate on a single generalized extension for this purpose? I won't be able to attend the meeting, but I hope that you'll discuss the possibility.

The OCLC extension has the following:

OCLC-ILL-Request-Extension ::= SEQUENCE {

client-department [0] ILL-String OPTIONAL,

payment-method [1] ILL-String OPTIONAL,

uniform-title [2] ILL-String OPTIONAL,

dissertation [3] ILL-String OPTIONAL,

issue-number [4] ILL-String OPTIONAL,

volume [5] ILL-String OPTIONAL,

affiliations [6] ILL-String OPTIONAL,

source [7] ILL-String OPTIONAL

}

The BL extension has the following:

BL-collection ::= IMPLICIT ENUMERATED {

conference-proceedings (1),

dissertation-or-thesis (2),

music (3),

newspaper (4),

official-publication (5),

patent (6),

technical-report (7),

translation (8)

}

I would rather see a single IPIG-ILL-Request-Extension that could address the need for additional material types, payment methods, and other special needs. Wouldn't this be more useful than each of us developing our own extensions? We could all use the same IPIG-ILL-Request-Extension and not have to differentiate which extension to use--e.g. OCLC extension vs BL extension vs RLG extension, etc.

 

We all have the same basic needs. Let's find a single solution.

 

Kevin Gladwell responded:

I would also like this to go on the agenda. However to merge the OCLC extension with the BL extension would not be easy as they are trying to achieve different things e.g. OCLC dissertation parameter requires that bibliographic details of the dissertation are included, at the BL we just need to know that it is a dissertation.

Linda - it would be useful to know what RLG needs including.

----------------------------------------------------------

Agenda Item 3b: Clarifications Review

KEY:

G=Info covered in Guidelines; retire Clarification

C=Keep as Clarification

P=Info covered in IPIG Profile; retire Clarification

G01 Use of client-id in SHIPPED APDU

C02 Integer Values for Extension.identifier

C03 Predicate "p5"

G04 Cancel State

C05 Will-Supply-Results.supply-date: not IMPLICIT ISO-Date

G06 Responding to a Flawed APDU

G08 Handling Multiple Conditions in ILL-ANSWER

C09 Sequence Validation and Repeated APDUs

G10 No Delivery or Delivery of Wrong Item

G11 iLL-service-type

C13 The Forward Service and the notification-note

P14 Most-recent-service-note in ILL transaction history?

Agenda Item 3c: RE: Defect Report 05

Craig Wright, 1999/11/19 passed on this comment on DFR 05 (from Harold Cheney?):

Defect report 05 incorrectly asserts that its changes will be transparent to implementors who have not made a systematic distinction between the processing and tracking phases of a transaction. Prior to this defect report, it could be argued that a single state table was functionally equivalent to separate processing and tracking state tables, because every common cell was identical, and the RETURN variable protected the cells that were in only the tracking phase. But that is no longer true with this defect report, since there are cells that are only in the processing phase table. It is probably beyond the scope of the defect report to say how single-table implementation should implement the specified behavior, but the defect report should not say that it doesn't apply to single-table implementations.

Agenda Item 5: PatronRequest/RequestSubmission Extension

Randy Menakes (1999/11/11)

I would like to discuss means for interaction between protocol-based ILL applications and non-ILL applications at the upcoming IPIG meeting. Dena Bovee from OCLC has asked for discussion of the PatronRequest APDU. I understand this to be a 'Request Submission' message that allows one application (like a PAC), to load an ILL request into an ILL system. (Is that correct, Dena?) We at Ameritech have also been discussing standardized means for an external application to issue 'Request Status Query' and 'Request Cancellation' messages.

 

Intermediary-related questions:

Randy Menakes (1999/11/11):

  1. Vendors are beginning to implement intermediary capabilities into their discrete systems. Do we need to do any co-ordination to insure that our systems can interact when chaining/partitioning cross vendor boundaries. (Is 'protocol compliance' adequate to insure interoperability, or does the IPIG need to impose guidelines through profiling.
  2. Have we agreed that forwarding can remain out of scope of the IPIG because other topologies (chaining, partitioning, and referral) can handle all situations, effectively eliminating the need for forwarding. Ed Davidson said that the IPIG may have agreed not to do forwarding, but that "our customers didn't"t. I think we need to hear, then, what the customers require and why forwarding may be the only solution.
  3. Do we really need to start, once again, a discussion of a Send-to-list extension. ( I guess that depends largely on the outcome of a discussion of forwarding.)

___________________________