    UDT Series on Data Communication Technologies and Standards for Libraries Models for Open System Protocol Development : A Technical Report (1994)4. WORK IN PROGRESS4.1 Extension of SR and ILL ProtocolsThe SR protocol supports basic search and retrieve in the information environment, but many additional services are needed to fully cover the current and planned capabilities of sophisticated retrieval systems. Work is ongoing in defining these additions to the protocol, a number of which are described below. They are in various stages of adoption; some in final ballot, others in working draft form.
The ILL protocol, which covers three activity models, was more extensive in its first version than SR. One area not treated completely was document delivery. It was expected that document delivery would be a separate protocol, however, basic document delivery services are now being progressed for addition to the ILL protocol. This is described below.
The services in the present SR standard are confirmed services, i.e., each service consists of a request and a response. Furthermore it is the Origin system that requests the service. The Access-control and Resource-control services are modelled differently. The Access-control service is always invoked by the Target system.
Resource control is actually a set of services: Resource-control, Solicit-resource-control, and Resource-report. The Resource-control service is invoked by the Target as part of an active operation, the Solicit-resource-control service is invoked by the Origin as part of an active operation, and the Resource-report service is invoked by the Origin to initiate an operation.
Access-control is a confirmed service (i.e., a request followed by a response), but in contrast to the existing SR services, it is invoked by the Target, which sends an Access-control request, and the Origin sends an Access-control response. The request does not initiate, nor does the response terminate, an operation; rather, the access control request and response are part of the operation that they interrupt.
For example, suppose a Target has databases DB1 and DB2, and an Origin has established credentials, during initialization, to search DB1 but not DB2 (the Origin has the proper credentials to search DB2, but has not established them with the Target, nor has the Target demanded those credentials, because considerable resources might be required to perform this authentication and it is not yet determined that the Origin wants to search DB2). Sometime during the association, the Origin initiates a Search operation, searching DB2. Upon receipt of the Search request, the Target sends an Access-control request to the Origin, which in effect demands the Origin's credentials to search DB2, and the Origin responds with an Access-control response, which includes those credentials. If the supplied credentials are acceptable to the Target, it proceeds with the Search operation (eventually sending a Search response). If not, the Target send a Search response with a status of failure and an appropriate diagnostic.
Within the Resource-control request the Target indicates whether or not processing of the operation has been suspended pending the Resource-control response.
If the request occurs during a Search operation, the Target indicates the status of the result set. It may be that valid (partial) results are available (i.e. the partial result set is a proper subset of the theoretical final result set) and that if the Origin decides to terminate the operation, the partial result set will be made available for Present operations.
Thus the Target may ignore any Solicit-resource-control request, and in fact it must ignore a Solicit-resource-control request in two situations: (1) when there is no active operation (although the Origin sends the Solicit-resource-control request while an operation is active, the request might arrive at the Target after the operation is complete), and (2) after issuing a Resource-control request while awaiting a Resource-control response.
A request for a resource report during an operation presents a different problem than when no operation is pending. During an operation, the request must be non-confirmed, with no guarantee that the Target will take any action in response (see 4.2.1). Therefore the Solicit-resource-control service must be used. If the Origin sends a Solicit-resource-control request (during an operation) which arrives at the Target after the operation is complete the Target would not be able to recognize that the request pertained to the completed operation (and thus ignore it).
The Resource-report service, in contrast to Solicit-resource-control, must be confirmed. The Origin invokes the Resource-report service to initiate an operation and therefore a Resource-report request from the Origin requires a response from the Target; if the response were not determinable, then the Origin would not be certain when to initiate a subsequent operation.
This facility is accomplished in a manner that adds no new protocol mechanisms to the SR protocol. The Explain facility is implemented as a special database on any Target that supports the facility. Note, however that there is no requirement that the Target actually implement the facility as a database. That is an implementation detail for each Target. The model for the Explain facility is a database available like any other database through SR. Records from this database are available and may be retrieved using the standard SR search and present services. The Explain facility has provisions in it for an Origin to obtain details of the databases available for searching on a Target, of the attributes and diagnostic sets used by a Target, of the record syntaxes and element set names retrievable from a Target. It can also be used to determine information about the composition of records in databases on the Target. The Explain facility is also intended to be fully extensible in the sense that Targets can include implementation specific records for any purpose that can be retrieved and used by Origins that recognize such records. The records as defined contain both human readable information that can be displayed as is to the end-users, and structured information that is intended to be processed by automated retrieval programs. The Explain database makes use of a special attribute set exp-1 and returns records in a special record syntax IR-exp-syntax. This record syntax is defined using ASN.1. Targets that support the Explain facility agree to support this record syntax and attribute set. Origins and Targets are free, of course, to agree among themselves about additional attribute sets and record syntax's they wish to use with the Explain facility. The standard RPN Type 1 query as defined in the base SR standard is used to search the Explain database. All search terms are defined to be visible strings and capitalization of search terms is considered not significant. Many parameters of Explain records are defined to be human readable strings. This data type is intended to permit the transfer of data intended to be read by a human operator. This data may have a language associated with it and may be in one of several display formats such as plain text, Postscript, etc. It is not required that each parameter within a record have the same language and format. Each parameter that is a human visible string may contain multiple instances of that string, each with a different language and/or format. The Explain Use attributes contain fields for specifying both the format and language desired. Currently the following values are recognized as valid values for parameters in Explain records that are defined as human readable strings:
As an extensibility mechanism other formats may be accepted by agreement between the Origin and Target. In addition certain fields in Explain records are defined as structured fields. These fields are intended to be parsed and processed by automated search mechanisms. Some of the information that may be provided through using the Explain service are:
4.4 ScanThe ISO 10163 does not include any form of browse service. A type of browse, the scanning of ordered lists, has been added through an amendment undergoing final balloting. This Scan service will enable the end-users to browse, or scan, through ordered lists from the Target database(s), such as author indexes, alphabetic lists of subject heading, alphabetic lists of title words, etc.The ordering of scan lists is Target-defined and thus a request for an alphabetically sorted list of authors to one system may not return entries in the same order as the same request to another system.
The proposal includes the possibility to scan quickly through a list. This means that the user may want to see, e.g., every 30th entry in the list.
The Sort request specifies the name of the result set that is to be sorted and a sequence of sort elements. The request can also contain a new name for the sorted result set. If there is no new name, the existing name is used for the sorted result set. The Origin's specification of an element to be used for sorting is either an explicit field reference (for example a tag), an element set name, or an attribute list. The Origin can provide a constant value to be used in case the element is missing from the record. The Origin can specify for each sort element whether the sort on that element is to be ascending or descending, and whether the case of the element is significant in sorting. If more than one sort element is provided, the order of occurrence is from major to minor.
The Sort response contains status and diagnostic information about the sort. In the situation where the Origin has not given a name to be used for the sorted result set and the sort has failed, the Target indicates in its response whether the original result set is still available for retrieval.
4.6.2 Definition and CoverageFor implementing update services between applications a number of common arrangements as well as individual commitments are necessary. The following conventions have to be defined outside of an Update service:
It is presumed that exchange formats to be used must be agreed upon and in many cases will be specific national formats. Within these national formats it has to be settled which data have to be available for an Update service, for example:
4.6.3 Functions of the Update ServiceThe following requirements should be used for the Update service to assure basic functionality.4.6.3.1 Role AllocationThe application in which a new data record is created or in which a change is made takes the initiative in an Update service, i.e., the Origin system where the change took place is responsible for bringing new and updated records to the Target. It is not defined at which time the Update service is activated, for example real-time or within frequent intervals, etc. The databases within the Target system itself can of course only be changed by the application of the Target system.4.6.3.2 Update ConnectionsThe Update service should define the services between one Origin system and one Target system. Thus a one-to-one connection is created. In cases where an Origin system has to distribute changed records to several Target systems (1:n), this has to be settled within the individual application, for example by means of several connections.4.6.3.3 Update FunctionsDistinctions should be made among the following functions:
In the last two cases (modification and deletion), the service must describe some means by which the Origin may unambiguously identify the records to be modified or deleted.
4.7 Suspend/ResumeA Suspend/Resume service has been proposed as an amendment to the SR protocol. It is intended to be used when a Search request has been submitted and the end-user either cannot or will not, just wait for the response. Certain searches may take a long time. Both in order to release the network association and to be able to use the terminal for other tasks, one should be able to send a Suspend request. When the end-user is able to continue the session, or believes that the search has been carried out, a Resume request can be sent.4.8 SR-Operations and Concurrent Operations4.8.1 OperationsSR describes several operation types: Init, Search, Present, and Delete (as well as proposed Scan, Sort, Resource-report, and Extended-services). In general, an Origin request initiates an operation, of the same type as the request; for example a Search request initiates a Search operation. Note that only Origin requests initiate operations, and not every Origin request initiates an operation; the exceptions are the Solicit-resource-control and Close requests.An operation is terminated by the response, of the operation type, from the Target; for example, a Search response terminates a Search operation. A request that initiates an operation is called an initiating request and a response that terminates an operation is called a terminating response. From the Origin perspective, an operation begins when it issues the initiating request, and ends when it receives the terminating response. From the Target perspective, the operation begins when it receives the initiating request and ends when it sends the terminating response. An operation consists of the initiating request and the terminating response, along with any intervening Access-control and Resource-control requests (from the Target) and responses (from the Origin), Solicit-resource-control requests (from the Origin), and Segment requests (from the Target). An operation is assigned a Reference-id by the Origin, the Origin includes the Reference-id within the initiating request, and it must be included within each message of the operation. If concurrent operations has not been negotiated (in which case "serial operations" is said to be in effect), the Reference-id parameter may be omitted in the initiating request; in that case the reference-id is considered null for that operation, and all other messages of that operation must also omit the Reference-id parameter. Thus any message from Origin to Target, or vice versa (i.e., any SR APDU), is part of an operation, identified by its (possibly null) Reference-id, with the following exceptions:
There is no relationship assumed between a given operation and any subsequent operation even if the latter operation uses the same Reference-id.
Once an operation is initiated, until that operation is terminated, another operation may not be initiated with the same Reference-id. The protocol does not specify the order in which concurrent operations are processed at the Target; the Target may process concurrent operations in any manner it chooses. For example: the Origin may issue a Search request using Reference-id 100, and then issue a second Search request using Reference-id 101 before receiving the Search response from the first Search request. There would then be two concurrent operations. Receipt by the Origin of the response corresponding to the second Search request (identified by Reference-id 101) would terminate the second operation, and that might occur before termination of the first operation (identified by Reference-id 100). The Origin might then issue a Present request (against the result set created by the second operation), initiating another operation. In that case, the Origin must supply a Reference-id other than 100 (because there is an active operation with that Reference-id). The new Reference-id could (but need not) be 101; if it is, the Target may not assume that there is any implied relationship between this new operation and the previous operation which used Reference-id 101. All result sets are, in principle, available to any operation. It is possible that two or more concurrent operations will attempt to reference the same result set. The protocol does not specify what happens in that circumstance. (The Origin should not initiate concurrent Search operations with the same value of Result-set-id.) There are no restrictions on the re-use or management of Reference-ids by the Origin (other than the restriction cited above that when the Origin uses a Reference-id to initiate an operation, until that operation is terminated it may not use that Reference-id to initiate another operation).
The Origin might re-cycle Reference-ids randomly among users, or it may manage local threads by assigning different Reference-ids to end-users. The Target is not required to know how the Origin manages Reference-ids, or in particular, that the Origin is using Reference-ids to distinguish different users. There is no requirement for the Target to have any knowledge of multiple end-users at the Origin, the Target only interacts with the single Origin.
After sending an initiating request, the Origin must be prepared to receive an Access-control or Resource-control request (for that operation), respond with a respective response (although for Resource-control the response is conditional) then later receive another Access-control or Resource-control request, etc., before receiving a terminating response. For Access-control, the Target might suspend processing of the operation from the time that it sends the Access-control request until it receives the Access-control response. The challenge does not interrupt any other operation. If the Origin response is acceptable to the Target, the operation proceeds as if the challenge has never taken place. If the Origin fails to respond correctly to the challenge then the Target's terminating response to the interrupted operation may indicate that the operation was terminated due to an Access-control failure. For Resource-control (if the request indicates that a response is required) the Target might (but need not) suspend processing of the operation (however, other operations are not affected) from the time that it sends the request until it receives the response. If the response indicates "continue" the operation proceeds as if the challenge has never taken place. Otherwise, If the Target's terminating response to the interrupted operation may indicate that the operation was terminated by resource control at the Origin request. The following pertain to Access-control and Resource control as it applies to the SR-association, when concurrent operations is in effect. Following initialization, the Origin must be prepared at any time, whether or not there are active operations, to receive an Access-control or Resource-control request pertaining to the SR-association, respond, then later receive another Access-control or Resource control request, etc.
For access control, the Target might suspend some or all of the active operation from the time that it sends the Access-control request until it receives the response. If the Origin response is acceptable to the Target, the suspended operations proceed as if the challenge had never taken place. If the Origin fails to respond correctly to the challenge, the Target might decide to terminate one or more operations but leave open the SR-association. In that case, the Target's terminating response to any such operations may indicate that the operation was terminated due to an Access-control failure. Alternately the Target may close the SR-association.
4.9.1 Proximity OperatorThere is no proximity operator in the current SR search service. Few systems allow the use of proximity operators in searching bibliographic references. However, the SR protocol may be used when searching databases where the use of a proximity operator is relevant. The inclusion of such an operator has therefore been proposed. The use of a proximity operator within SR is the same as the use of a proximity operator in different search languages today.4.9.2 Resource-limits ParameterA new parameter, Resource-limits, is proposed for the Search request. It may include limits such as cost, result set size, and elapsed time, as well as one of the following prescribed action for the Target to take when one of the limits is approached, such as:
The Origin may also indicate (via a flag within the Resource-limits parameter) that it wishes the Target to pre-screen the operation. If pre-screening determines that the operation cannot be performed within limits (or if the request omits limits), then the Target sends a Resource-control request with a resource report which includes resource estimates for the operation; if the Origin response is to continue the operation, then those estimates override any corresponding limits that were originally specified in the request (if the request did not specify any limits the search simply proceeds without limits).
In general the Target makes no guarantee when it accepts a limit; the Origin assumes it will make a good faith effort to be as precise as it can. However, the Origin may further indicate (via a flag within the parameter) that the Target should not begin the operation unless it can guarantee that it will not exceed the limits. This does not mean that the Target must know, or guarantee, a priori, that it can complete the operation within the specified limit, but rather, the Target guarantees that in the event that it decides to abort a search that would have exceeded the limits, the operation will accrue charges similar to those if the search had not been processed.
During initialization, the Origin and Target negotiate one of the following:
When no segmentation is in effect, the Target response to a Present request consists of a Present response only containing an integral number of records. When level 1 segmentation is in effect the Target may respond to a Present request with multiple segments: a Present response, with possibly one or more intervening Segment requests where each must contain an integral number of records. When level 2 segmentation is in effect the Target may respond to a Present request with multiple segments, and individual records may span segments.
Thus the Present service is a confirmed service initiated by the origin to initiate a Present operation. The Segment service is a non-confirmed service initiated by the Target, during a Present operation. A Present operation thus consists of a Present request followed by zero or more Segment requests followed by a Present response.
An ES operation is initiated by the Origin, via an ES request; the ES response, which completes the ES operation, does not (necessarily) signal completion of the task (it may indicate for example whether the task has started or has been queued). An ES task may have a lifetime beyond the SR-association. Examples of extended services are:
For each extended service an abstract data structure is defined. Each ES task is represented by a database record, called a task package, maintained in a special database by the Target, whose abstract structure is that defined for that extended service. This extended services database may be searched, and records retrieved, by the SR Search and Present services. The Origin may search for packages of a particular type, or created by a particular user, or of a particular status (i.e. pending, active, or complete), or according to various other criteria. In particular, after submitting an ES request (during the same or a subsequent SR-association), the Origin may search the Target's database for a resulting task package in order to determine status information pertaining to the task, such as whether the task has started. The Origin, via an ES request, may create, delete, or modify a task package. When it creates a task package, it specifies a user-id, to be associated with the package, as well as permissions for other user-ids. Permissions include create, delete, and modify, as well as present, and invoke. For example, when a user creates a task package of type Save-Result-Set a (persistent) result set is created, represented by the created task package. When that package is presented (either in the same or a subsequent SR-association), a copy of that persistent result set is made available to that SR-association as an SR result set (a result set name, for use during the SR-association, is included within the task package). When a user deletes the task package, the persistent result set is deleted.
As another example: when a user creates a task package of type Save-Query, a (persistent) query is created, represented by the created task package. Another user may subsequently create a Periodic-Query-Schedule task package, which refers to the persistent query task package, only if that user has invoke privilege for that persistent query. The Periodic-Query-Schedule task package includes an active flag, indicating whether the periodic query is active. The user may subsequently modify the task package (if the user has modify privilege for the package) to turn the active flag on or off. Similarly, a user may create an Export-Specification (package) and another user (or the same user) may subsequently invoke that Export-Specification, by creating an Invoke-Export-Specification package.
For both SR and Z39.50 a search request must identify the database(s) to be searched as well as the set of attributes to be used in the search. In the ISO standard, currently there is only one such attribute set defined. It is called bib-1 and contains most of the attributes needed to search bibliographic data. Attributes in bib-1 are, for example, type of term (personal name, title, ISBN, subject, etc.), relational and positional operators, term structure (word, phrase, etc.), and type of truncation. Boolean operators may be used in the query, but masking characters and proximity operators are still under development. The Z39.50 uses bib-1 but the Z39.50 bib-1 is a superset of the SR bib-1. In both protocols the format in which records should be delivered and whether they should be brief or full records can be specified by the Origin. The Origin may also request the result set be delivered in various increments of one to n records at a time.
Closer alignment of the texts of SR and Z39.50 is currently under consideration, since the intent of ISO TC46 and NISO is to keep the two functionally the same in order to assure interoperability. Alignment has been achieved by introducing changes to one standard into the other through amendments, but considerable rewriting must be carried out in the process as the documents have very different structures. SR is split into two documents, Service Description and Protocol Specification, while Z39.50 is one document for service and protocol. ISO TC46 is investigating adoption of the Z39.50 text as the ISO standard, a move that would not change the SR protocol specification but would simplify protocol maintenance.
At present, the ILL service model assumes that requested documents are to be delivered by some document delivery mechanism separate from the communications channel used by the ILL protocol. This delivery mechanism most often involves physical delivery of the requested material, e.g., using the post office, courier services, etc. It is not unreasonable to expect, however, that there will be an increasing demand for electronic delivery of requested documents. Already there are experiments under way in the use of Group 3 and Group 4 fax to deliver documents in association with ILL requests. In addition, the Research Libraries Group, Inc., (RLG) has developed an electronic delivery workstation, Ariel, for use over the Internet, that is growing in popularity for the delivery of ILL documents. All these activities, however, continue the metaphor of a separate delivery channel for the requested material. In order to be able to build automated or even partially automated delivery systems, it will be necessary to support an explicit, machine-processable association between the ILL transaction and the document being delivered.
Sections 4.12.2 and 4.12.3 below describe respectively the electronic-delivery-related requirements and the rationale for the proposed changes in the ILL service and protocol.
There is no requirement to enclose a document as part of an ILL message.
The protocol must be able to support the transfer of any of these document types, and the transfer protocol must have sufficient extensibility to be able to accommodate any new document types which may require transfer in the future. One means of accomplishing this is to support the definition of document types outside the ILL standard, using, for instance, the object identifiers assigned to document types registered under the procedures of ISO 9834.
A similarly extensible mechanism to that used for document type will be required to allow extensible specification of the required delivery service. It is assumed that electronic document delivery necessarily corresponds to the ILL service type "copy/non-returnable", and that transactions involving electronic delivery enter the terminal state on Shipped or Received as appropriate. 4.12.2.4 Linking Shipped Document to Delivery ServiceThere are two approaches to electronic document delivery in conjunction with ILL: delivery synchronous with the Shipped service or delivery asynchronous to the Shipped service. Synchronous delivery may be either through association of the document with a Shipped message on the same communication service, or by the immediate use of a separate communications service. In an X.400 environment, for instance, a Shipped APDU could occupy one body part of an InterPersonal Message (IPM), with the document in the subsequent body part. In a connection-mode environment, a Shipped APDU could be immediately followed by the invocation of a bulk data transfer service such as FTAM.Asynchronous delivery requires that the document be explicitly related to the ILL transaction it fulfills through some form of delivery note; with synchronous delivery, the implicit relation established by the sequence should be sufficient to identify the transaction to which the document relates.
How the specifics of delivery via an external delivery service are implemented is a mapping issue, which is outside the ILL standard, and belongs in an application context. For instance, an application context for ILL+X.400 IPM could specify that a document for delivery follows in a body part immediately after the body part containing the Shipped APDU (and probably that that body part may contain ONLY the one APDU). Similarly, which (if any) delivery services and document types are to be supported is a profile question.
The delivery-service parameter as currently specified in ISO 10161 does not provide for a machine-processable specification of the desired delivery service. Without compromising backward compatibility, the current definition needs to be expanded to enable choice of either physical or electronic delivery in such a way that the Requester can specify a list of supported electronic delivery services (e.g. FTAM, X.400 MHS, FTP, SMTP mail, etc.) in order of preference. Therefore it is proposed that Delivery Service be a choice between the existing Transportation-Mode and a new parameter called "Electronic-Delivery-Service".
In order to be machine processable, the Electronic-Delivery-Service parameter must allow the user to specify the required delivery service (FTAM, MOTIS IPM, etc.), parameters specific to the delivery service (e.g. body-part type for IPM, file transfer parameters for FTAM), the document type to be transferred (e.g. IA5 text, group 3 fax, etc.), any parameters required for the document type, and an electronic delivery address specific to the delivery service. In addition, it should be possible to specify the required service and document type in a human-readable form for use in environments which are only partly automated or which do not use OSI object identification mechanisms. The Electronic-Delivery-Service parameter should also allow the user to specify a preferred time for delivery of the document, to enable, for instance, delivery to take place at off-peak times.
It may also be desirable to allow an ILL-Answer with "conditional-results", the condition being acceptance of a delivery service proposed by the Responder. This would require addition of a "proposed-supply-details" parameter to the APDU. This parameter would have the same definition as the supply-details parameter of Shipped.
| ||
 |
||
|
| ||
| Latest Revision: April 27, 1995 |
Copyright © 1995-2000
International Federation of Library Associations and Institutions www.ifla.org | |