ISO 10160:1997
(Main)Information and documentation - Open Systems Interconnection - Interlibrary Loan Application Service Definition
Information and documentation - Open Systems Interconnection - Interlibrary Loan Application Service Definition
Information et documentation — Interconnexion de systèmes ouverts (OSI) — Définition du service d'application pour les prêts entre bibliothèques
Informatika in dokumentacija – Skupina za povezovanje odprtih sistemov – Definicija aplikacijskih storitev medknjižnične izposoje
General Information
Relations
Frequently Asked Questions
ISO 10160:1997 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information and documentation - Open Systems Interconnection - Interlibrary Loan Application Service Definition". This standard covers: Information and documentation - Open Systems Interconnection - Interlibrary Loan Application Service Definition
Information and documentation - Open Systems Interconnection - Interlibrary Loan Application Service Definition
ISO 10160:1997 is classified under the following ICS (International Classification for Standards) categories: 35.240.30 - IT applications in information, documentation and publishing. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 10160:1997 has the following relationships with other standards: It is inter standard links to ISO 10160:1997/Amd 1:2002, ISO 10160:2015; is excused to ISO 10160:1997/Amd 1:2002. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 10160:1997 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL
Is0
STANDARD 10160
Second edition
1997-04-O 1
Information and documentation - Open
Systems Interconnection - Interlibrary
Loan Application Service Definition
lnforma tion et documentation - lnterconnexion de syst&mes ouverts
(OS/) - Dkfinition du setvice d’application pour /es pr6ts entre
biblioth&ques
Reference number
IS0 10160: 1997(E)
IS0 10160:1997(E)
Contents
Page
.....................................................
1 7.1.14 Overdue
. . . . . .*.
1 SCOPE
.....................................................
7.1.15 Renewal
. . . . . . . . . . . . . . . . . . . . . . . . . . .
2 NORMATIVE REFERENCES 16
.........................................
7.1.16 Renew Answer.
........................................
7.1.17 Lost Notification
....................................................
3 DEFINITIONS
................................
7.1.18 Damaged Notification
.....................
.2
3.1 REFERENCE MODEL DEFINITIONS
.....................................................
7.1.19 Message
3.2 APPLICATION LAYER STRUCTURE DEFINITIONS. 2
..............................................
7.1.20 Status Query
.2
3.3 SERVICE CONVENTIONS DEFINITIONS .
7.1.2 1 Status-or-Error Report .
...............................................
3.4 ILL DEFINITIONS
........................................................
7.1.22 Expiry
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 ABBREVIATIONS . 17
7.2 SPECIFICATION METHOD AND NOTATION
7.3 ILL SERVICES .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 CONVENTIONS
............................... 18
ILL-REQUEST Service
7.3.1
.............................................
6 SERVICE MODEL .
7.3.2 FORWARD Service
.4
.22
6.1 SERVICE-USER AND SERVICE-PROVIDER. .
7.3.3 FORWARD-NOTIFICATION Service. .
...............................
6.1.1 Roles of the Service-user . 22
7.3.4 SHIPPED Service
............................................
6.2 ILL-TRANSACTION 23
7.3.5 ILL-ANSWER Service .
.4
............... 25
6.3 ILL-TRANSACTION TYPES AND TOPOLOGIES .
7.3.6 CONDITIONAL-REPLY Service
.................................. 5
6.3.1 Simple ILL-transaction .
7.3.7 CANCEL Service
................................ 26
6.3.2 Chained ILL-transaction .
7.3.8 CANCEL-REPLY Service
............................
6.3.3 Partitioned ILL-transaction . 26
Service
7.3.9 RECEIVED
............................... 7
..................................... 27
6.3.4 Distinct ILL-transactions Service.
7.3.10 RECALL
..................................................... 27
6.3.5 Forwarding .
7.3.11 RETURNED Service
6.3.6 Referrals . .
7.3.12 CHECKED-IN Service
............................................................ 28
6.3.7 Retries .
7.3.13 OVERDUE Service
...............................
6.4 ILL-TRANSACTION STATE .
7.3.14 RENEW Service
............................................ ......................
6.4.1 Requester-State 29
7.3.15 RENEW-ANSWER Service
...........................................
6.4.2 Responder State 30
7.3.16 LOST Service .
............................................
6.4.3 Terminal States 30
Service. .
7.3.17 DAMAGED
......................................
6.4.4 Intermediary States .
7.3.18 MESSAGE Service
................................ 15
3 1
6.4.5 ILL-transaction Phases .
7.3.19 STATUS-QUERY Service
7.3.20 STATUS-OR-ERROR-REPORT Service .3 1
...........................
7 DEFINITION OF SERVICES
........................................
7.3.2 1 EXPIRY Service
......................................... 15
7.1 SERVICE FEATURES
........................................................ 33
7.1.1 General .
8 SEQUENCES OF PRIMITIVES.
.................................................
7.1.2 ILL Request
8.1 RESILIANCE TO LOST AND OUT-OF-SEQUENCE
.....................................
7.1.3 Request Forwarding MESSAGES .
..............................
7.1.4 Forwarding Notification .
8.1.1 Lost Messages
...................................................... 33
7.1.5 Shipment .
8.1.2 Out-of-Sequence Messages
..................................................
7.1.6 ILL Answer 34
8.2 STATE TRANSITIONS .
........................................ ................... 48
7.1.7 Conditional Reply
8.3 ADDITIONAL SEQUENCING RULES
.................................................
7.1.8 Cancellation
ANNEXES
.......................................
7.1.9 Cancellation Reply
................................. 50
A Time Sequence Diagrams
.......................................................
7.1.10 Receipt
................ 57
B ILL Service and Document Delivery
......................................................... 16
7.1.11 Recall
C Bibliography .
........................................................
7.1.12 Return
..................................................... 16
7.1.13 Check-in
0 IS0 1997
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or
including photocopying and micro-
utilized in any form or by any means, electronic or mechanical,
film, without permission in writing from the publisher.
International Organization for Standardization
Case postale 56 l CH-1211 Geneve 20 l Switzerland
central@iso.ch
Internet
c=ch; a=4OOnet; p=iso; o=isocs; s=central
x.400
Printed in Switzerland
ii
0 IS0 IS0 10160:1997(E)
FOREWORD
IS0 (the International Organization for Standardization) is a worldwide federation
of national standards bodies (IS0 member bodies). The work of preparing
International Standards is normally carried out through IS0 technical committees.
Each member body interested in a subject for which a technical committee has
been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take
part in the work. IS0 collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are circulated to
the member bodies for voting. Publication as an International Standard requires
approval by at least 75% of the member bodies casting a vote.
International Standard IS0 10 160 was prepared by Technical Committee
ISOITC 46, Information and documentation, Subcommittee SC 4, Computer
applications in information and documentation.
This second edition cancels and replaces the first edition (IS0 10160: 1993), which
has been technically revised.
Annexes A, B and C of this International Standard are for information only.
. . .
IS0 10160:1997(E) 0 IS0
implementation, and by minimizing the number of
INTRODUCTION
messages sent between the sites involved in an
The purpose of the Interlibrary Loan (ILL) standard
ILL-transaction.
is to provide a set of Application Layer services
which can be used by libraries to perform loan-related - Reflection of Current ILL Practices. The purpose
activities in an Open Systems Interconnection (OSI) in defining a protocol is not to introduce a new
environment, as defined by IS0 7498. method for performing an ILL-transaction, but
The goal of Opens Systems Interconnection is to
rather to formalize current practices in a way that
allow, with a minimum of technical agreement allows existing systems to communicate with each
outside the interconnection standards, the other in a standardized way, as well as to allow
interconnection of information processing systems:
newer automated systems to take full advantage of
the protocol’s potential. However, it is recognized
- from different manufacturers;
that this International Standard may not be
- under different managements;
universally applicable to all existing ILL systems
- of different levels of complexity; and
without some modification, due to the wide
variation in their capabilities.
- of different technologies.
There is an inherent trade off in any attempt to
The ILL service provides capabilities to request the
reconcile these divergent objectives. For example,
loan of returnable bibliographic items, such as books,
minimizing ILL-transaction costs may result in some
or to request non-returnable items, such as
loss of control over the ILL-transaction. Reducing the
photocopies of journal articles. Related procedures,
number of messages sent lowers the
such as loan renewal, item recall, overdue
telecommunications cost and also lowers the operator
notification, etc. are also supported by this service.
costs as there is less need for the operator to initiate
The purpose of the service definition is to defme the
and control the communications operations.
communications aspects of ILL processing in terms
However, by reducing the total number of messages,
of a set of services provided to a user by an
some level of information regarding the ILL-
application-service-element (ASE). Performing an
transaction is lost as is the coordination between the
ILL-transaction involves a user invoking the services
requesting and responding libraries. By reducing the
in the prescribed order.
total number of stages through which a ILL-
The focus of ILL activity is the bibliographic item,
transaction must go (i.e. states), the operator interface
which may be a book, periodical, journal article,
of an automated system can be made simpler, with an
microform, etc. The ILL application is concerned
associated reduction in requisite demands on the
with procedures relating to the loan of these items
operator.
between libraries or to the interchange of copies
The approach taken in this International Standard is
thereof.
to set the mandatory requirements that all open
This service definition strives to satisfy a number of
systems must support in order to achieve an
objectives, including:
acceptable degree of coordination between automated
- Control of ILL-transactions. The services must
parties to an ILL-transaction. Additional optional
provide a means of controlling the ILL-
features are defined which allow implementors to
transaction in terms of constraining allowable
achieve a greater degree of control if it is desired.
actions, exchanging information, tracking a
NOTE - The mandatory requirements of this
borrowed item, and synchronizing the activity of
International Standard may, however, exceed the
the two or more sites involved in the ILL-
capabilities and/or needs of some existing manual or
transaction.
semi-automated ILL systems.
- Interworking of Various Systems. The ILL
This International Standard is one of a number of
activity will continue to be performed using a
related standards supporting the interconnection of
combination of manual and automated systems.
library systems. These standards can be used by
The ILL service and protocol must recognize this
themselves or in a cooperative manner to support
fact and allow systems with varying degrees of
library applications requiring a mixture of
automation to be able to interwork, i.e.
communications services. For example, IS0 10 163,
communicate with each other in a meaningful
which supports remote access to bibliographic
way.
databases, could be used in conjunction with the ILL
- Minimizing the Costs of ILL-transactions. The
protocol to obtain item identification information.
costs associated with an ILL-transaction include
The control and management of interactions among
both operator costs and communications costs. An
such bibliographic applications are outside the scope
ILL protocol should attempt to minimize the costs
of this International Standard.
incurred by implementations conforming to the
Security and accounting issues as they relate to ILL
protocol. This can be done by minimizing the
operations are for further study.
operator intervention required by the protocol
1v
IS0 10160:1997(E)
INTERNATIONAL STANDARD 0 IS0
Information and documentation -
Open Systems Interconnection -
Interlibrary Loan Application Service Definition
Information processing systems
IS0 7498-2: 1989
1 Scope
- Open Systems Interconnection
This International Standard is an Application Layer
- Basic Reference Model -
standard within the Open Systems Interconnection
Part 2: Security Architecture.
framework defined by IS0 7498.
This standard defines the services for Interlibrary
IS0 7498-3: 1989
Information processing systems
Loan. These services are provided by the use of the
- Open Systems Interconnection
ILL protocol in conjunction with the supporting
- Basic Reference Model -
telecommunications service which may be a store-
Part 3: Naming and addressing.
and-forward messaging service, such as that
provided by the MOTIS Standards, IS0 1002 l-4
ISOIIEC 7498-4: Information processing systems
etc.; or a direct connection-mode service using
1989 - Open Systems Interconnection
IS0 8822 and IS0 8649.
- Basic Reference Model -
This standard does not specify individual
Part 4: Management framework.
implementations or products, nor does it constrain
NOTE - ISO/IEC 7498-l : 1994,
the implementation of entities and interfaces within
IS0 7498-2: 1989, IS0 7498-3:
a computer system. Computer systems may range
1989 and ISO/IEC 7498-4: 1989
from stand-alone workstations to mainframes.
supersede IS0 7498: 1984.
This standard is intended for use by libraries,
However, when this International
information utilities such as union catalogue centres,
Standard was under development,
and any other system which processes bibliographic
the previous edition was valid and
information. These systems may participate in an this International Standard is
therefore based on this edition,
interlibrary loan transaction in the role of requester
which is given below.
(i.e. an initiator of ILL requests), responder (i.e. a
provider of bibliographic material or information)
IS0 7498: 1984 Information Processing Systems
and/or intermediary (i.e. an agent that acts on behalf
- Open Systems Interconnection
of a requester to find suitable responders).
Various interworking topologies are supported, - Basic Reference Model.
ranging from simple two-party interactions to multi-
party interactions. ISO/IEC 1073 1: Information technology - Open
There is no requirement for conformance to this 1994 Systems Interconnection - Basic
standard. Conformance is required only for the ILL
Reference Model - Conventions
protocol specification. for the definition of OS1
services.
NOTE - ISO/IEC 1073 1: 1994
supersedes ISO/TR 8509: 1987.
2 Normative references
However, when this International
Standard was under development,
The following standards contain provisions which,
ISO/TR 8509 was valid and this
through reference in this text, constitute provisions
International Standard is therefore
of this International Standard. At the time of
based on ISO/TR 8509, which is
publication, the editions indicated were valid. All
given below.
standards are subject to revison, and parties to
agreements based on this International Standard are
ISOITR 8509: 1987
Information Processing Systems
encouraged to investigate the possibility of applying
- Open Systems Interconnection
the most recent editions of the standards indicated
- Service Conventions.
below. Members of IEC and IS0 maintain registers
of currently valid International Standards.
ISO/IEC 10026- 1:
Information Technology - Open
Systems Interconnection -
ISOIIEC 7498- 1: Information technology - Open
Distributed Transaction -
Systems Interconnection - Basic
Processing - Part 1: OS1 TP
Reference Model: The Basic
model.
Model.
0 IS0
IS0 10160:1997(E)
Information and Documentation application-protocol-control-information
IS0 10 16 1- 1: 1997
- Open Systems Interconnection using the Presentation Service.
- Interlibrary Loan Application
3.2.2 application-context: A set of rules shared
Protocol Specification - Part 1:
in common by two application-entity-
Protocol specification.
invocations governing their behavior in
order to enable their cooperative operation.
NOTE - An application-context is a shared
conceptual schema for the universe of
3 Definitions
discourse for communication.
For the purposes of this International Standard, the
following definitions apply.
3.2.3 application-context-definition: The
description of an application-context.
3.1 Reference Model Definitions
3.2.4 application-entity-invocation: A specific
This International Standard is based on the concepts
utilization of part or all of the capabilities
developed in IS0 7498: 1984 and makes use of the
of a given application-entity in support of
following terms found in it. These terms are
the communications requirements of an
replicated here as a convenience to the reader.
application-process-invocation.
3.1.1 application-entity: The aspects of an
application-process pertinent to OSI. 3.2.5 application-process-invocation: A
specific utilization of part or all of the
3.1.2 Application Layer: The seventh and
capabilities of a given application-process
highest layer in the Reference Model for
in support of a specific occasion of
Open Systems Interconnection (OSI); it
information processing.
serves as the window between
correspondent application-processes which
3.3 Service Conventions Definitions
are using the OS1 to exchange meaningful
This International Standard makes use of the
information.
following terms defined in ISO/TR 8509: 1987.
3.1.3 application-protocol-data-unit: A unit of
3.3.1 indication primitive: A representation of
data specified in an application-protocol
an interaction in which a service-provider
and consisting of application-protocol-
either:
information and possibly application-user-
a. indicates that it has, on its own
data.
initiative, invoked some procedure; or
3.1.4 application-service-element: That part of
b. indicates that a procedure has been
an application-entity which provides an
invoked by the service-user at the peer
OS1 environment capability, using
service-access-point.
underlying services when appropriate.
3.3.2 non-confirmed service: A distinct part of
(N)-service: A capability of the @I)-layer
3.1.5
the total @Q-service which does not result
and the layers beneath it, which is provided
in an explicit confirmation from the
to (N+l)-entities at the boundary between
service-provider to the initiating service-
the @I)-layer and the (N+l)-layer.
user.
-
NOTE - An application-service does not provide a
3.3.3 provider-initiated service: A distinct part
capability to higher layer entities, but
of the total @Q-service which is initiated
rather to application-processes.
by the service-provider rather than the
3.1.6 presentation-service: A capability of the
service-user.
Presentation Layer and the layers beneath
3.3.4
request primitive: A representation of an
it, which is provided to application-entities
interaction in which a service-user invokes
at the boundary betsween the Presentation
some procedure.
and the Application Layer.
3.3.5 service primitive: An abstract,
implementation-independent representation
3.2 Application Layer Structure Definitions
of an interaction between service-user and
This International Standard makes use of the
following terms defined in ISO/IEC 9545: 1989. the service-provider.
application-association: A cooperative
3.2.1
3.3.6 service-provider: An abstract of the
relationship between two application-
totality of those entities which provide a
entity-invocations’ for the purpose of
service to peer service-users. _
communication of information and co-
3.3.7 service-user: An entity in a single open
ordination of their joint operation. This
system that makes use of a service.
relationship is formed by the exchange of
Ifi0 10160:1997(E)
0 IS0
3.4.12 partitioned ILL-transaction: An ILL-
3.4 ILL Definitions
transaction involving three parties, i.e. a
3.4.1 bibliographic item: A monograph, serial,
requester, a responder and an intermediary,
microform, film, video recording, sound
where the intermediary acts as a relay of
recording or other item of information held
ILL messages during the processing phase,
by a library or some organization. A
and where the requester and responder
bibliographic item may assume different
interact directly during the tracking phase.
forms, e.g., a book may be printed on
paper or represented electronically.
3.4.13 processing phase: That phase of an ILL-
transaction up to and including shipment of
3.4.2 chained ILL-transaction: An ILL-
a requested item.
transaction involving three or more parties,
i.e. a requester, a responder and one or
3.4.14 requester: The party which has generated
more intermediaries, where each
an ILL-REQUEST.
intermediary acts as a relay for all ILL
3.4.15 responder: The party which has received
messages.
an ILL-REQUEST.
3.4.3 electronic delivery: Delivery of an
3.4.16 simple ILL-transaction: An ILL-trans-
electronic representation of a requested
action involving only two active parties, a
item via a telecommunication-based
requester and responder.
service.
3.4.17 sub-transaction: A part of an ILL-
3.4.4 final-responder: The institution which
transaction involving interactions between
supplies a requested item. This term is
an intermediary and a responder or another
used when it is necessary to distinguish
intermediary.
between the responder of an ILL-
3.4.18 supplier: The party that has supplied the
transaction and the responder of an ILL-
requested item. It need not be the same as
sub-transaction.
the final-responder.
3.4.5 ILL-transaction: A single, complete
3.4.19 terminal state: A state from which no
instance of the whole ILL cycle, including
transition to another state can be made,
all of the actions, service primitives, and
e.g.:
messages involved from the initial ILL-
REQUEST until the cycle is concluded, as When a photocopy is provided, SHIPPED
with the return of the requested material. is the terminal state for the responder,
RECEIVED is the terminal state for the
3.4.6 ILL-transaction group: A set of related
requester.
ILL-transactions initiated by the same
CANCELLED is a terminal state for both
requester.
the requester and responder.
ILL-transaction state: The information
3.4.7
3.4.20 tracking phase: That phase of an ILL-
which describes the current processing
transaction after shipment and receipt of a
status of an ILL-transaction; it is the
returnable item, including renewals,
combination of the requester state, the
overdues and item return.
responder state and the states of all
intermediaries involved in an ILL- 3.4.21 user: (see service-user, clause 3.3.7)
transaction.
initial-requester: Person or institution
3.4.8
4 Abbreviations
which initiates an ILL-transaction; this
ACID - Atomicity, consistency, isolation &
term is used when it is necessary to
durability
distinguish between the requester of an
ASE -
Application-service-element
ILL-transaction and the requester of an
ILL-sub-transaction.
AS0 - Application service object
intermediary: A responder which either
3.4.9 ILL -
Interlibrary loan
forwards a request to another library or
MOTIS - Message Oriented Text Interchange
institution for processing, or initiates
System
chained or partitioned sub-transactions
OS1 -
Open systems interconnection
with other responders.
3.4.10 item: (see bibliographic item, clause 3.41)
5 Conventions
3.4.11 parameter: A functionally related group
This International Standard uses the conventions
of one or more data elements.
defined in ISO/TR 8509.
0 IS0
IS0 10160:1997(E)
durability, as applied to transactions in the OS1
6 Service Model
transaction processing model (IS0 100260 1).
6.1 Service-user and Service-provider
ILL-transactions may overlap in time, i.e. multiple
The ILL application is modelled as a distributed
ILL-transactions may be processed concurrently by
collection of application-processes, each of which is
a given open system.
located in a separate real open system, e.g. a library
An ILL-transaction may be initiated only by a
system.
requester.
Within each application-process, there are two types
A sub-transaction refers to the set of
of functions: local processing functions; and
communications activity involving an intermediary
communications-related functions, i.e. OSI-related
and a responder or another intermediary, and is
functions. The local processing functions deal with
related to an ILL-transaction initiated by a
such activities as database manipulation, report
requester. A sub-transaction is not, in itself, an
generation, etc.; these are outside the scope of this
actual ILL-transaction.
International Standard. Within each system, those
A sub-transaction may be initiated only by an
aspects of the application-process which are
intermediary.
pertinent to OS1 are called the application-entity.
When an ILL-transaction involves three or more
Each application-entity in turn includes one or more
parties, the initial-requester is the party that
application-service-elements (ASEs), one of which
generated the initial ILL-REQUEST. The final-
is the ILL ASE. These ASEs provide
responder is the last recipient of an ILL-REQUEST
communications-related services to the service-user.
for that ILL-transaction.
To do this they engage in protocol exchanges with
Individual ILL-transactions may be related to each
peer application-entities in other systems and they
other, for example a succession of attempts by a
take advantage of supporting services within the
requester to contact different responders directly.
Application Layer and the layers below it.
Such ILL-transactions form an ILL-transaction
Relationships with other ASEs are defined as part of
group. It is at the discretion of the initiator to
an application-context-definition. This is outside the
determine whether such ILL-transactions are to be
scope of this International Standard.
related explicitly through the ILL-transaction
The set of all ILL ASEs, supporting ASEs and the
identifier; such grouping of ILL-transactions may be
lower layer services across all systems together
done, for example, to provide a historical record of
form the ILL service-provider.
the related steps associated with an interlibrary loan.
Each ILL-transaction has a unique ILL-transaction
6.1.1 Roles of the Service-user
identifier that is used to identify the state and other
A service-user involved in ILL activity takes on one
descriptive information maintained by ILL-
of three roles: requester, responder or intermediary.
application-entities for that ILL-transaction. The
The requester generates ILL requests.
ILL-transaction identifier has the following
The responder receives ILL requests and is the
components:
potential supplier of requested items.
initial-requester-id: identification of the requester
The intermediary is a responder which does not
who initiated the ILL-transaction;
itself satisfy an ILL request and which passes the
request to another responder on behalf of the ILL-transaction-group-qualifier: distinguishes a
requester.
group of ILL-transactions from all other active ILL-
The actual supplier of requested items is normally a
transaction groups associated with the initial-
responder; however, the service model allows for requester;
institutions that do not receive ILL requests, as
ILL-transaction-qualifier: distinguishes an ILL-
defined in this International Standard, to supply the
transaction from all other ILL-transactions within an
requested items. For example, an institution that
ILL-transaction group.
supports only postal and telephone ILL requests
The ILL-transaction identifier of each sub-
may have another institution that supports electronic
transaction has the following additional component,
ILL requests act as a responder on its behalf.
which is unique within, and only within, the scope
6.2 ILL-transaction
of a single intermediary:
An ILL-transaction is a single, complete instance of
sub-transaction-qualifier: distinguishes this sub-
the whole ILL cycle, including all of the actions,
transaction from all other sub-transactions within an
service primitives, and messages involved from the
ILL-transaction initiated by the intermediary.
initial ILL-REQUEST until the cycle is concluded,
as with the return of the requested material. The
6.3 ILL-transaction Types and Topoi’ogies
term “ILL-transaction” is used in this International
There are three types of ILL-transactions: simple,
Standard in its most general sense, and does not
chained and partitioned.
imply an atomic unit of work with the ACID
properties of atomicity, consistency, isolation and
0 IS0 IS0 10160:1997(E)
The interactions between the requester and the first
6.3.1 Simple ILL-transaction
intermediary define the main ILL-transaction. The
A simple ILL-transaction involves two active
parties, the requester and responder. In its most set of interactions between an intermediary and the
basic manifestation, the requester and responder responder constitute a sub-transaction, as do the
interactions between each pair of intervening
interact in a point-to-point manner, as illustrated in
intermediaries. Figure 2 (a) illustrates a chained
Figure 1.
ILL-transaction with two intermediaries (and hence
All ILL-transactions initiated by a requester begin
as simple ILL-transactions. A requester may, two sub-transactions).
If a sub-transaction results in non-fulfillment of the
however, indicate as part of the ILL-request that the
ILL request, the intermediary may initiate a new
responder has permission to change the ILL-
transaction-type to chained or partitioned. If the sub-transaction to another responder. The
responder does change the type, this responder then intermediary may try several potential responders in
turn. This leads to a star ILL-transaction topology
becomes an intermediary.
with the intermediary as the hub, as illustrated in
When a responder is unable to respond successfully
Figure 2 (b).
to a request, it may supply a list of potential
responders to assist the requester. The responder may supply a list of potential
responders to the intermediary to assist it in making
6.3.2 Chained ILL-transaction
a selection.
A chained ILL-transaction involves at least three
The requested item could be delivered directly to
parties: the requester, the responder and one or
the requester or client, or to one of the
more intermediaries. An ILL-request is passed from
intermediaries who would then be responsible for
one intermediary (to another intermediary) to the
delivering it to the requester or client.
responder in a chain, with each intermediary acting
as a relay for all ILL messages. There is no direct
interaction between the requester and responder.
Resp.
i
Req.
l = System
Req. = Requester
Resp. = Responder 1,2,3 . . . = order of interactions
LEGEND
Figure 1 - Simple Transaction
IS0 10160:1997(E) 0 IS0
Resp.
Resp.
Resp.
t
3 (Sub-Transaction)
/ Transaction)
Transaction) \
IlIt. Resp. Resp.
2 =tL 5
(unfilled) m (Sub- - (film
(Sub-
2 (sub-~aclioIl)
Transaction) Transaction)
Inti
1 (Thnsaction)
1 (Tkansaction)
i 1
Req. Req.
a
chained with
Star Topology
Two Intermediaries
Req. = Requester
l = System
Resp. = Responder
IIlL = I.nterme%liaIy 1,2,3 . . . = order of interactions
LEGEND
Figure 2 - Chained Transactions
Partitioned ILL-transactions are useful in situations
The requester can allow or prohibit chaining and
where the intermediary acts as an agent of the
can specify, if desired, a list of potential responders
to which a request might be chained. It can also requester to find a suitable responder but has no
interest in participating any further in an ILL-
supply a list of responders which have already been
transaction. This is typical of some union catalogue
tried, so that unnecessary duplication of ILL
facilities.
requests does not occur.
A partitioned ILL-transaction is divided into two
6.3.3 Partitioned ILL-transaction
phases. The first phase, the “processing phase”,
A partitioned ILL-transaction involves at least three
consists of interactions between the requester and
parties: the requester; the responder; and one or
the responder via the intermediary or intermediaries.
more intermediaries. An ILL-request is passed from
During this phase, the sets of interactions between
the intermediary to the responder who responds to
intermediaries and between the intermediary and a
the intermediary, who then responds to the
responder constitute sub-transactions. The second
requester. After the desired item has been shipped
phase of the main ILL-transaction, the “tracking
and the requester has received notification that it
phase”, consists of the direct interactions between
has been shipped, all further interactions take place
the requester and responder. It is used for
directly between the requester and responder; the
monitoring the progress of the loaned item,
intermediary no longer participates in the ILL-
including recalls, renewals, overdues, etc. ILL-
transaction. Figure 3 illustrates a partitioned ILL-
transaction phases are described more fully in
transaction.
clause 6.4.5.
IS0 10160:1997(E)
0 IS0
(Sub-Transaction-processing
p- OdY)
pransaction-tracking
(Transaction-processing
p- OdY)
Req. = Requester
= System
Resp. = Responder
1,2,3 . . . = order of interactions
lint. = Intermediary
LEGEND
Figure 3 - Partitioned Transaction
6.3.4 Distinct ILL-transactions
The requested item could be delivered directly to
The preceding descriptions of chained and
the requester or client, or to the intermediary who
partitioned ILL-transactions imply that the
would then be responsible for delivering it to the
intermediary plays only a relay role during the
requester or client.
tracking phase, i.e. it does not invoke any services
The requester can allow or prohibit partitioning and
such as OVERDUE on its own initiative.
can specify, if desired, a list of potential responders
The ILL service model also allows a potential
to which a request might be sent. It can also supply
intermediary to instead play an active role during
a list of responders which have already been tried,
so that unnecessary duplication of ILL requests does the processing phase of ILL-transactions, and exert
control over all phases of an ILL-transaction by
not occur.
establishing distinct ILL-transactions for its
When a responder is unable to respond successfully
to a request, it may supply a list of potential interactions with the requester and with the
responder. A system which receives an ILL-request
responders to assist the requester.
may act as a final responder (from the viewpoint of
Partitioning and chaining may be mixed within the
same ILL-transaction, as illustrated in Figure 4. the initial requester), and act as an initial requester
Note that when partitioning occurs after chaining, as in a second transaction which it initiates with the
fmal responder. These distinct transactions are not
shown in Figure 4 (a), it overrides chaining, the
required to share any common identification and
effect being the same as multiple instances of
partitioning. However, if chaining follows need not proceed in a synchronized fashion. All
linkage between events on one ILL-transaction and
partitioning, then the chaining effect is preserved.
events on the other is at the discretion and under the
control of the dual-role system. This permits the
0 IS0
IS0 10160:1997(E)
(PtitiOIlCd
Sub-Transaction)
Int
Resp. Resp*
(Wd
T
Subtransaction)
(PZUtitiOIld
ht. Suhansaction)
4 =tL
f
(Transaction)
4 (?kacking Phase
only)
///I
(a) Chained then b) Partitioned then
Partitioned
chained
Req. = Requester
= System
Resp. = Responder
1,2,3 . . .
= order of interactions
IIlL = htermediary
LEGEND
Figure 4 - Mix of Chaining and Partitioning
requester. The intermediary notifies the requester
dual-role system, for example, to initiate an
when forwarding occurs. Figure 5 (a) shows the
OVERDUE request without having received an
simplest case of forwarding involving only one
OVERDUE indication from the responder.
The one constraint on the use of distinct ILL- intermediary. Figure 5 (b) shows the case where
multiple instances of forwarding occur.
transactions is that all items supplied by a final-
The requester can allow or prohibit forwarding and
responder must be shipped and returned via the
dual-role system. This ensures that the dual-role can specify, if desired, a list of potential responders
system is able to track the progress of the two ILL- to which a request might be forwarded. It can also
transactions and can reach terminal states. supply a list of responders which have already been
This style of operation, since it involves two distinct tried, so that unnecessary duplication of ILL
simple ILL-transactions, has no protocol requests does not occur.
When a responder is unable to respond successfully
implications, and is not described further in this
International Standard. to a request, it may supply a list of potential
responders to assist the requester.
6.3.5 Forwarding
A variation of the simple ILL-transaction involves
an intermediary who forwards an ILL request to a
responder and then ceases to participate actively in
the ILL-transaction. The responder receiving the
forwarded request responds directly to the
IS0 10160:1997(E)
0 IS0
a
0 09
Multiple Instances of
One Instance of Forwarding
Forwarding
Req. = Requester
l =System
Resp. = Responder
Int. = Intermediary 1,2,3 . . . = order of interactions
LEGEND
Figure 5 - Simple Transaction with Forwarding
choose to retry the original request at an appropriate
Chaining and forwarding may be mixed within the
time or to look elsewhere. If the original request is
same ILL-transaction, as illustrated in Figure 6 (a)
and (b). repeated, it carries an indication that this is a retry.
The retry is a new transaction or sub-transaction
Partitioning and forwarding also may be mixed
which should form part of the same ILL-transaction
within the same ILL-transaction, as illustrated in
Figure 7 (a) and (b). group as the original request.
For the initial requester, a retry is a new ILL-
6.3.6 Referrals
transaction and so the ILL-transaction-qualifier
When an ILL request is unfilled, the requester may
must be different from that used in the original
choose to refer the request to another responder, as
request but the ILL-transaction-group-qualifier must
illustrated in Figure 8. Each request referral is
be the same (to enable the responder or
considered to be a separate ILL-transaction which is
intermediary to relate the retry to the previous ILL-
part of the same ILL-transaction group.
transaction).
As an implementation consideration, this request
For an intermediary a retry is a new sub-transaction
referral could be performed manually or
and so the sub-transaction-qualifier must be
automatically.
different from that used in the previous request, but
both the ILL-transaction-group-qualifier and the
6.3.7 Retries
ILL-transaction-qualifier must be the same (to
When an ILL request is unfilled with a reason such
enable the responder or next intermediary to relate
as RETRY, ESTIMATE or LOCATIONS-
the retry to the previous sub-transaction).
PROVIDED, the ILL-transaction or sub-transaction
terminates. The requester or intermediary may
0 IS0
IS0 10160:1997(E)
Int.
F-ard)
2 (Sub-
Rev* 4
Transaction)
Ll
Int.
Y
1 (-==tid
i
Req.
a
chain&then Forwarded then
Forwarded chained
Req. = Requester
= System
l
Req. = Responder
1,2,3 . . . = order of interaclions
Int = In-ary
LEGEND
Figure 6 - Chained Transaction with Forwarding
IS0 10160:1997(E)
0 IS0
tTkm=tioll- \;
-gphasc)
a
PartitioIledthcn
Forwarded
(sub-on-
=w@=)
Fonuardcdthen
PartitioIled
Req.=-
@ =systcm
Req. = Responder
13 . . . = order of ixl~ons
IIlt=IU~
LEGEND
c
Figure 7 - Partitioned Transaction with Forwarding
IS0 10160:1997(E) 0 IS0
l = System
Req. = Requester
Resp. = Responder
1,2,3 . . .
= orda of interactions
LEGEND
Figure 8 - Transaction Referrals
0 IS0 IS0 10160:1997(E)
NOT-SUPPLIED
The ILL-transaction has
6.4 ILL-transaction State
reached a stage where the
At any given time, the possible interactions that can
request cannot be filled by
occur between an ILL service-user and service-
the responder.
provider are governed by the state of the ILL-
CONDITIONAL The ILL-transaction has
transaction.
reached a stage where the
The ILL-transaction state, i.e. the information which
request can only be filled if
describes the status of processing of an ILL-
the requester agrees to meet
transaction, is the combination of the requester state,
specified conditions.
the responder state and the states of all intermediaries
CANCEL-PENDING The requester has initiated
involved in the ILL-transaction, where the requester,
responder and intermediary states correspond to the cancellation of the ILL-
transaction but no response
ILL-transaction representation held by the
has been received from the
application-entities within these end-systems.
responder.
Due to a requirement to support systems with
CANCELLED
reduced functionality or where telecommunications The ILL-transaction has
been cancelled by the
costs must be minimized, the ILL protocol supports
responder.
optional messages. This means that for certain
SHIPPED The item has been shipped
interactions, i.e. SHIPPED request, RECEIVED
to the requester.
request, RETURNED request and CHECKED-IN
RECEIVED
request, the sending of a message is optional and The item has been received
from the responder.
therefore a service event in one system may not
RENEW/PENDING A request has been made for
result in a corresponding event in the peer system.
The state of one application-entity in an ILL- the renewal of the item.
RENEW/OVERDUE
transaction cannot necessarily be inferred fkom the A request has been made for
the renewal of an item
state of the other application-entity. However,
which is overdue.
services are available (i.e. the STATUS-QUERY
OVERDUE
and STATUS-OR-ERROR-REPORT services) for The requester has been
obtaining the current state of the other application- notified that the item is
overdue.
entity. It is never necessary for one application-
NOT RECEIVED/
entity to know the state of the other application- The responder has se
...
INTERNATIONAL
Is0
STANDARD 10160
Second edition
1997-04-O 1
Information and documentation - Open
Systems Interconnection - Interlibrary
Loan Application Service Definition
lnforma tion et documentation - lnterconnexion de syst&mes ouverts
(OS/) - Dkfinition du setvice d’application pour /es pr6ts entre
biblioth&ques
Reference number
IS0 10160: 1997(E)
IS0 10160:1997(E)
Contents
Page
.....................................................
1 7.1.14 Overdue
. . . . . .*.
1 SCOPE
.....................................................
7.1.15 Renewal
. . . . . . . . . . . . . . . . . . . . . . . . . . .
2 NORMATIVE REFERENCES 16
.........................................
7.1.16 Renew Answer.
........................................
7.1.17 Lost Notification
....................................................
3 DEFINITIONS
................................
7.1.18 Damaged Notification
.....................
.2
3.1 REFERENCE MODEL DEFINITIONS
.....................................................
7.1.19 Message
3.2 APPLICATION LAYER STRUCTURE DEFINITIONS. 2
..............................................
7.1.20 Status Query
.2
3.3 SERVICE CONVENTIONS DEFINITIONS .
7.1.2 1 Status-or-Error Report .
...............................................
3.4 ILL DEFINITIONS
........................................................
7.1.22 Expiry
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 ABBREVIATIONS . 17
7.2 SPECIFICATION METHOD AND NOTATION
7.3 ILL SERVICES .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 CONVENTIONS
............................... 18
ILL-REQUEST Service
7.3.1
.............................................
6 SERVICE MODEL .
7.3.2 FORWARD Service
.4
.22
6.1 SERVICE-USER AND SERVICE-PROVIDER. .
7.3.3 FORWARD-NOTIFICATION Service. .
...............................
6.1.1 Roles of the Service-user . 22
7.3.4 SHIPPED Service
............................................
6.2 ILL-TRANSACTION 23
7.3.5 ILL-ANSWER Service .
.4
............... 25
6.3 ILL-TRANSACTION TYPES AND TOPOLOGIES .
7.3.6 CONDITIONAL-REPLY Service
.................................. 5
6.3.1 Simple ILL-transaction .
7.3.7 CANCEL Service
................................ 26
6.3.2 Chained ILL-transaction .
7.3.8 CANCEL-REPLY Service
............................
6.3.3 Partitioned ILL-transaction . 26
Service
7.3.9 RECEIVED
............................... 7
..................................... 27
6.3.4 Distinct ILL-transactions Service.
7.3.10 RECALL
..................................................... 27
6.3.5 Forwarding .
7.3.11 RETURNED Service
6.3.6 Referrals . .
7.3.12 CHECKED-IN Service
............................................................ 28
6.3.7 Retries .
7.3.13 OVERDUE Service
...............................
6.4 ILL-TRANSACTION STATE .
7.3.14 RENEW Service
............................................ ......................
6.4.1 Requester-State 29
7.3.15 RENEW-ANSWER Service
...........................................
6.4.2 Responder State 30
7.3.16 LOST Service .
............................................
6.4.3 Terminal States 30
Service. .
7.3.17 DAMAGED
......................................
6.4.4 Intermediary States .
7.3.18 MESSAGE Service
................................ 15
3 1
6.4.5 ILL-transaction Phases .
7.3.19 STATUS-QUERY Service
7.3.20 STATUS-OR-ERROR-REPORT Service .3 1
...........................
7 DEFINITION OF SERVICES
........................................
7.3.2 1 EXPIRY Service
......................................... 15
7.1 SERVICE FEATURES
........................................................ 33
7.1.1 General .
8 SEQUENCES OF PRIMITIVES.
.................................................
7.1.2 ILL Request
8.1 RESILIANCE TO LOST AND OUT-OF-SEQUENCE
.....................................
7.1.3 Request Forwarding MESSAGES .
..............................
7.1.4 Forwarding Notification .
8.1.1 Lost Messages
...................................................... 33
7.1.5 Shipment .
8.1.2 Out-of-Sequence Messages
..................................................
7.1.6 ILL Answer 34
8.2 STATE TRANSITIONS .
........................................ ................... 48
7.1.7 Conditional Reply
8.3 ADDITIONAL SEQUENCING RULES
.................................................
7.1.8 Cancellation
ANNEXES
.......................................
7.1.9 Cancellation Reply
................................. 50
A Time Sequence Diagrams
.......................................................
7.1.10 Receipt
................ 57
B ILL Service and Document Delivery
......................................................... 16
7.1.11 Recall
C Bibliography .
........................................................
7.1.12 Return
..................................................... 16
7.1.13 Check-in
0 IS0 1997
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or
including photocopying and micro-
utilized in any form or by any means, electronic or mechanical,
film, without permission in writing from the publisher.
International Organization for Standardization
Case postale 56 l CH-1211 Geneve 20 l Switzerland
central@iso.ch
Internet
c=ch; a=4OOnet; p=iso; o=isocs; s=central
x.400
Printed in Switzerland
ii
0 IS0 IS0 10160:1997(E)
FOREWORD
IS0 (the International Organization for Standardization) is a worldwide federation
of national standards bodies (IS0 member bodies). The work of preparing
International Standards is normally carried out through IS0 technical committees.
Each member body interested in a subject for which a technical committee has
been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take
part in the work. IS0 collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are circulated to
the member bodies for voting. Publication as an International Standard requires
approval by at least 75% of the member bodies casting a vote.
International Standard IS0 10 160 was prepared by Technical Committee
ISOITC 46, Information and documentation, Subcommittee SC 4, Computer
applications in information and documentation.
This second edition cancels and replaces the first edition (IS0 10160: 1993), which
has been technically revised.
Annexes A, B and C of this International Standard are for information only.
. . .
IS0 10160:1997(E) 0 IS0
implementation, and by minimizing the number of
INTRODUCTION
messages sent between the sites involved in an
The purpose of the Interlibrary Loan (ILL) standard
ILL-transaction.
is to provide a set of Application Layer services
which can be used by libraries to perform loan-related - Reflection of Current ILL Practices. The purpose
activities in an Open Systems Interconnection (OSI) in defining a protocol is not to introduce a new
environment, as defined by IS0 7498. method for performing an ILL-transaction, but
The goal of Opens Systems Interconnection is to
rather to formalize current practices in a way that
allow, with a minimum of technical agreement allows existing systems to communicate with each
outside the interconnection standards, the other in a standardized way, as well as to allow
interconnection of information processing systems:
newer automated systems to take full advantage of
the protocol’s potential. However, it is recognized
- from different manufacturers;
that this International Standard may not be
- under different managements;
universally applicable to all existing ILL systems
- of different levels of complexity; and
without some modification, due to the wide
variation in their capabilities.
- of different technologies.
There is an inherent trade off in any attempt to
The ILL service provides capabilities to request the
reconcile these divergent objectives. For example,
loan of returnable bibliographic items, such as books,
minimizing ILL-transaction costs may result in some
or to request non-returnable items, such as
loss of control over the ILL-transaction. Reducing the
photocopies of journal articles. Related procedures,
number of messages sent lowers the
such as loan renewal, item recall, overdue
telecommunications cost and also lowers the operator
notification, etc. are also supported by this service.
costs as there is less need for the operator to initiate
The purpose of the service definition is to defme the
and control the communications operations.
communications aspects of ILL processing in terms
However, by reducing the total number of messages,
of a set of services provided to a user by an
some level of information regarding the ILL-
application-service-element (ASE). Performing an
transaction is lost as is the coordination between the
ILL-transaction involves a user invoking the services
requesting and responding libraries. By reducing the
in the prescribed order.
total number of stages through which a ILL-
The focus of ILL activity is the bibliographic item,
transaction must go (i.e. states), the operator interface
which may be a book, periodical, journal article,
of an automated system can be made simpler, with an
microform, etc. The ILL application is concerned
associated reduction in requisite demands on the
with procedures relating to the loan of these items
operator.
between libraries or to the interchange of copies
The approach taken in this International Standard is
thereof.
to set the mandatory requirements that all open
This service definition strives to satisfy a number of
systems must support in order to achieve an
objectives, including:
acceptable degree of coordination between automated
- Control of ILL-transactions. The services must
parties to an ILL-transaction. Additional optional
provide a means of controlling the ILL-
features are defined which allow implementors to
transaction in terms of constraining allowable
achieve a greater degree of control if it is desired.
actions, exchanging information, tracking a
NOTE - The mandatory requirements of this
borrowed item, and synchronizing the activity of
International Standard may, however, exceed the
the two or more sites involved in the ILL-
capabilities and/or needs of some existing manual or
transaction.
semi-automated ILL systems.
- Interworking of Various Systems. The ILL
This International Standard is one of a number of
activity will continue to be performed using a
related standards supporting the interconnection of
combination of manual and automated systems.
library systems. These standards can be used by
The ILL service and protocol must recognize this
themselves or in a cooperative manner to support
fact and allow systems with varying degrees of
library applications requiring a mixture of
automation to be able to interwork, i.e.
communications services. For example, IS0 10 163,
communicate with each other in a meaningful
which supports remote access to bibliographic
way.
databases, could be used in conjunction with the ILL
- Minimizing the Costs of ILL-transactions. The
protocol to obtain item identification information.
costs associated with an ILL-transaction include
The control and management of interactions among
both operator costs and communications costs. An
such bibliographic applications are outside the scope
ILL protocol should attempt to minimize the costs
of this International Standard.
incurred by implementations conforming to the
Security and accounting issues as they relate to ILL
protocol. This can be done by minimizing the
operations are for further study.
operator intervention required by the protocol
1v
IS0 10160:1997(E)
INTERNATIONAL STANDARD 0 IS0
Information and documentation -
Open Systems Interconnection -
Interlibrary Loan Application Service Definition
Information processing systems
IS0 7498-2: 1989
1 Scope
- Open Systems Interconnection
This International Standard is an Application Layer
- Basic Reference Model -
standard within the Open Systems Interconnection
Part 2: Security Architecture.
framework defined by IS0 7498.
This standard defines the services for Interlibrary
IS0 7498-3: 1989
Information processing systems
Loan. These services are provided by the use of the
- Open Systems Interconnection
ILL protocol in conjunction with the supporting
- Basic Reference Model -
telecommunications service which may be a store-
Part 3: Naming and addressing.
and-forward messaging service, such as that
provided by the MOTIS Standards, IS0 1002 l-4
ISOIIEC 7498-4: Information processing systems
etc.; or a direct connection-mode service using
1989 - Open Systems Interconnection
IS0 8822 and IS0 8649.
- Basic Reference Model -
This standard does not specify individual
Part 4: Management framework.
implementations or products, nor does it constrain
NOTE - ISO/IEC 7498-l : 1994,
the implementation of entities and interfaces within
IS0 7498-2: 1989, IS0 7498-3:
a computer system. Computer systems may range
1989 and ISO/IEC 7498-4: 1989
from stand-alone workstations to mainframes.
supersede IS0 7498: 1984.
This standard is intended for use by libraries,
However, when this International
information utilities such as union catalogue centres,
Standard was under development,
and any other system which processes bibliographic
the previous edition was valid and
information. These systems may participate in an this International Standard is
therefore based on this edition,
interlibrary loan transaction in the role of requester
which is given below.
(i.e. an initiator of ILL requests), responder (i.e. a
provider of bibliographic material or information)
IS0 7498: 1984 Information Processing Systems
and/or intermediary (i.e. an agent that acts on behalf
- Open Systems Interconnection
of a requester to find suitable responders).
Various interworking topologies are supported, - Basic Reference Model.
ranging from simple two-party interactions to multi-
party interactions. ISO/IEC 1073 1: Information technology - Open
There is no requirement for conformance to this 1994 Systems Interconnection - Basic
standard. Conformance is required only for the ILL
Reference Model - Conventions
protocol specification. for the definition of OS1
services.
NOTE - ISO/IEC 1073 1: 1994
supersedes ISO/TR 8509: 1987.
2 Normative references
However, when this International
Standard was under development,
The following standards contain provisions which,
ISO/TR 8509 was valid and this
through reference in this text, constitute provisions
International Standard is therefore
of this International Standard. At the time of
based on ISO/TR 8509, which is
publication, the editions indicated were valid. All
given below.
standards are subject to revison, and parties to
agreements based on this International Standard are
ISOITR 8509: 1987
Information Processing Systems
encouraged to investigate the possibility of applying
- Open Systems Interconnection
the most recent editions of the standards indicated
- Service Conventions.
below. Members of IEC and IS0 maintain registers
of currently valid International Standards.
ISO/IEC 10026- 1:
Information Technology - Open
Systems Interconnection -
ISOIIEC 7498- 1: Information technology - Open
Distributed Transaction -
Systems Interconnection - Basic
Processing - Part 1: OS1 TP
Reference Model: The Basic
model.
Model.
0 IS0
IS0 10160:1997(E)
Information and Documentation application-protocol-control-information
IS0 10 16 1- 1: 1997
- Open Systems Interconnection using the Presentation Service.
- Interlibrary Loan Application
3.2.2 application-context: A set of rules shared
Protocol Specification - Part 1:
in common by two application-entity-
Protocol specification.
invocations governing their behavior in
order to enable their cooperative operation.
NOTE - An application-context is a shared
conceptual schema for the universe of
3 Definitions
discourse for communication.
For the purposes of this International Standard, the
following definitions apply.
3.2.3 application-context-definition: The
description of an application-context.
3.1 Reference Model Definitions
3.2.4 application-entity-invocation: A specific
This International Standard is based on the concepts
utilization of part or all of the capabilities
developed in IS0 7498: 1984 and makes use of the
of a given application-entity in support of
following terms found in it. These terms are
the communications requirements of an
replicated here as a convenience to the reader.
application-process-invocation.
3.1.1 application-entity: The aspects of an
application-process pertinent to OSI. 3.2.5 application-process-invocation: A
specific utilization of part or all of the
3.1.2 Application Layer: The seventh and
capabilities of a given application-process
highest layer in the Reference Model for
in support of a specific occasion of
Open Systems Interconnection (OSI); it
information processing.
serves as the window between
correspondent application-processes which
3.3 Service Conventions Definitions
are using the OS1 to exchange meaningful
This International Standard makes use of the
information.
following terms defined in ISO/TR 8509: 1987.
3.1.3 application-protocol-data-unit: A unit of
3.3.1 indication primitive: A representation of
data specified in an application-protocol
an interaction in which a service-provider
and consisting of application-protocol-
either:
information and possibly application-user-
a. indicates that it has, on its own
data.
initiative, invoked some procedure; or
3.1.4 application-service-element: That part of
b. indicates that a procedure has been
an application-entity which provides an
invoked by the service-user at the peer
OS1 environment capability, using
service-access-point.
underlying services when appropriate.
3.3.2 non-confirmed service: A distinct part of
(N)-service: A capability of the @I)-layer
3.1.5
the total @Q-service which does not result
and the layers beneath it, which is provided
in an explicit confirmation from the
to (N+l)-entities at the boundary between
service-provider to the initiating service-
the @I)-layer and the (N+l)-layer.
user.
-
NOTE - An application-service does not provide a
3.3.3 provider-initiated service: A distinct part
capability to higher layer entities, but
of the total @Q-service which is initiated
rather to application-processes.
by the service-provider rather than the
3.1.6 presentation-service: A capability of the
service-user.
Presentation Layer and the layers beneath
3.3.4
request primitive: A representation of an
it, which is provided to application-entities
interaction in which a service-user invokes
at the boundary betsween the Presentation
some procedure.
and the Application Layer.
3.3.5 service primitive: An abstract,
implementation-independent representation
3.2 Application Layer Structure Definitions
of an interaction between service-user and
This International Standard makes use of the
following terms defined in ISO/IEC 9545: 1989. the service-provider.
application-association: A cooperative
3.2.1
3.3.6 service-provider: An abstract of the
relationship between two application-
totality of those entities which provide a
entity-invocations’ for the purpose of
service to peer service-users. _
communication of information and co-
3.3.7 service-user: An entity in a single open
ordination of their joint operation. This
system that makes use of a service.
relationship is formed by the exchange of
Ifi0 10160:1997(E)
0 IS0
3.4.12 partitioned ILL-transaction: An ILL-
3.4 ILL Definitions
transaction involving three parties, i.e. a
3.4.1 bibliographic item: A monograph, serial,
requester, a responder and an intermediary,
microform, film, video recording, sound
where the intermediary acts as a relay of
recording or other item of information held
ILL messages during the processing phase,
by a library or some organization. A
and where the requester and responder
bibliographic item may assume different
interact directly during the tracking phase.
forms, e.g., a book may be printed on
paper or represented electronically.
3.4.13 processing phase: That phase of an ILL-
transaction up to and including shipment of
3.4.2 chained ILL-transaction: An ILL-
a requested item.
transaction involving three or more parties,
i.e. a requester, a responder and one or
3.4.14 requester: The party which has generated
more intermediaries, where each
an ILL-REQUEST.
intermediary acts as a relay for all ILL
3.4.15 responder: The party which has received
messages.
an ILL-REQUEST.
3.4.3 electronic delivery: Delivery of an
3.4.16 simple ILL-transaction: An ILL-trans-
electronic representation of a requested
action involving only two active parties, a
item via a telecommunication-based
requester and responder.
service.
3.4.17 sub-transaction: A part of an ILL-
3.4.4 final-responder: The institution which
transaction involving interactions between
supplies a requested item. This term is
an intermediary and a responder or another
used when it is necessary to distinguish
intermediary.
between the responder of an ILL-
3.4.18 supplier: The party that has supplied the
transaction and the responder of an ILL-
requested item. It need not be the same as
sub-transaction.
the final-responder.
3.4.5 ILL-transaction: A single, complete
3.4.19 terminal state: A state from which no
instance of the whole ILL cycle, including
transition to another state can be made,
all of the actions, service primitives, and
e.g.:
messages involved from the initial ILL-
REQUEST until the cycle is concluded, as When a photocopy is provided, SHIPPED
with the return of the requested material. is the terminal state for the responder,
RECEIVED is the terminal state for the
3.4.6 ILL-transaction group: A set of related
requester.
ILL-transactions initiated by the same
CANCELLED is a terminal state for both
requester.
the requester and responder.
ILL-transaction state: The information
3.4.7
3.4.20 tracking phase: That phase of an ILL-
which describes the current processing
transaction after shipment and receipt of a
status of an ILL-transaction; it is the
returnable item, including renewals,
combination of the requester state, the
overdues and item return.
responder state and the states of all
intermediaries involved in an ILL- 3.4.21 user: (see service-user, clause 3.3.7)
transaction.
initial-requester: Person or institution
3.4.8
4 Abbreviations
which initiates an ILL-transaction; this
ACID - Atomicity, consistency, isolation &
term is used when it is necessary to
durability
distinguish between the requester of an
ASE -
Application-service-element
ILL-transaction and the requester of an
ILL-sub-transaction.
AS0 - Application service object
intermediary: A responder which either
3.4.9 ILL -
Interlibrary loan
forwards a request to another library or
MOTIS - Message Oriented Text Interchange
institution for processing, or initiates
System
chained or partitioned sub-transactions
OS1 -
Open systems interconnection
with other responders.
3.4.10 item: (see bibliographic item, clause 3.41)
5 Conventions
3.4.11 parameter: A functionally related group
This International Standard uses the conventions
of one or more data elements.
defined in ISO/TR 8509.
0 IS0
IS0 10160:1997(E)
durability, as applied to transactions in the OS1
6 Service Model
transaction processing model (IS0 100260 1).
6.1 Service-user and Service-provider
ILL-transactions may overlap in time, i.e. multiple
The ILL application is modelled as a distributed
ILL-transactions may be processed concurrently by
collection of application-processes, each of which is
a given open system.
located in a separate real open system, e.g. a library
An ILL-transaction may be initiated only by a
system.
requester.
Within each application-process, there are two types
A sub-transaction refers to the set of
of functions: local processing functions; and
communications activity involving an intermediary
communications-related functions, i.e. OSI-related
and a responder or another intermediary, and is
functions. The local processing functions deal with
related to an ILL-transaction initiated by a
such activities as database manipulation, report
requester. A sub-transaction is not, in itself, an
generation, etc.; these are outside the scope of this
actual ILL-transaction.
International Standard. Within each system, those
A sub-transaction may be initiated only by an
aspects of the application-process which are
intermediary.
pertinent to OS1 are called the application-entity.
When an ILL-transaction involves three or more
Each application-entity in turn includes one or more
parties, the initial-requester is the party that
application-service-elements (ASEs), one of which
generated the initial ILL-REQUEST. The final-
is the ILL ASE. These ASEs provide
responder is the last recipient of an ILL-REQUEST
communications-related services to the service-user.
for that ILL-transaction.
To do this they engage in protocol exchanges with
Individual ILL-transactions may be related to each
peer application-entities in other systems and they
other, for example a succession of attempts by a
take advantage of supporting services within the
requester to contact different responders directly.
Application Layer and the layers below it.
Such ILL-transactions form an ILL-transaction
Relationships with other ASEs are defined as part of
group. It is at the discretion of the initiator to
an application-context-definition. This is outside the
determine whether such ILL-transactions are to be
scope of this International Standard.
related explicitly through the ILL-transaction
The set of all ILL ASEs, supporting ASEs and the
identifier; such grouping of ILL-transactions may be
lower layer services across all systems together
done, for example, to provide a historical record of
form the ILL service-provider.
the related steps associated with an interlibrary loan.
Each ILL-transaction has a unique ILL-transaction
6.1.1 Roles of the Service-user
identifier that is used to identify the state and other
A service-user involved in ILL activity takes on one
descriptive information maintained by ILL-
of three roles: requester, responder or intermediary.
application-entities for that ILL-transaction. The
The requester generates ILL requests.
ILL-transaction identifier has the following
The responder receives ILL requests and is the
components:
potential supplier of requested items.
initial-requester-id: identification of the requester
The intermediary is a responder which does not
who initiated the ILL-transaction;
itself satisfy an ILL request and which passes the
request to another responder on behalf of the ILL-transaction-group-qualifier: distinguishes a
requester.
group of ILL-transactions from all other active ILL-
The actual supplier of requested items is normally a
transaction groups associated with the initial-
responder; however, the service model allows for requester;
institutions that do not receive ILL requests, as
ILL-transaction-qualifier: distinguishes an ILL-
defined in this International Standard, to supply the
transaction from all other ILL-transactions within an
requested items. For example, an institution that
ILL-transaction group.
supports only postal and telephone ILL requests
The ILL-transaction identifier of each sub-
may have another institution that supports electronic
transaction has the following additional component,
ILL requests act as a responder on its behalf.
which is unique within, and only within, the scope
6.2 ILL-transaction
of a single intermediary:
An ILL-transaction is a single, complete instance of
sub-transaction-qualifier: distinguishes this sub-
the whole ILL cycle, including all of the actions,
transaction from all other sub-transactions within an
service primitives, and messages involved from the
ILL-transaction initiated by the intermediary.
initial ILL-REQUEST until the cycle is concluded,
as with the return of the requested material. The
6.3 ILL-transaction Types and Topoi’ogies
term “ILL-transaction” is used in this International
There are three types of ILL-transactions: simple,
Standard in its most general sense, and does not
chained and partitioned.
imply an atomic unit of work with the ACID
properties of atomicity, consistency, isolation and
0 IS0 IS0 10160:1997(E)
The interactions between the requester and the first
6.3.1 Simple ILL-transaction
intermediary define the main ILL-transaction. The
A simple ILL-transaction involves two active
parties, the requester and responder. In its most set of interactions between an intermediary and the
basic manifestation, the requester and responder responder constitute a sub-transaction, as do the
interactions between each pair of intervening
interact in a point-to-point manner, as illustrated in
intermediaries. Figure 2 (a) illustrates a chained
Figure 1.
ILL-transaction with two intermediaries (and hence
All ILL-transactions initiated by a requester begin
as simple ILL-transactions. A requester may, two sub-transactions).
If a sub-transaction results in non-fulfillment of the
however, indicate as part of the ILL-request that the
ILL request, the intermediary may initiate a new
responder has permission to change the ILL-
transaction-type to chained or partitioned. If the sub-transaction to another responder. The
responder does change the type, this responder then intermediary may try several potential responders in
turn. This leads to a star ILL-transaction topology
becomes an intermediary.
with the intermediary as the hub, as illustrated in
When a responder is unable to respond successfully
Figure 2 (b).
to a request, it may supply a list of potential
responders to assist the requester. The responder may supply a list of potential
responders to the intermediary to assist it in making
6.3.2 Chained ILL-transaction
a selection.
A chained ILL-transaction involves at least three
The requested item could be delivered directly to
parties: the requester, the responder and one or
the requester or client, or to one of the
more intermediaries. An ILL-request is passed from
intermediaries who would then be responsible for
one intermediary (to another intermediary) to the
delivering it to the requester or client.
responder in a chain, with each intermediary acting
as a relay for all ILL messages. There is no direct
interaction between the requester and responder.
Resp.
i
Req.
l = System
Req. = Requester
Resp. = Responder 1,2,3 . . . = order of interactions
LEGEND
Figure 1 - Simple Transaction
IS0 10160:1997(E) 0 IS0
Resp.
Resp.
Resp.
t
3 (Sub-Transaction)
/ Transaction)
Transaction) \
IlIt. Resp. Resp.
2 =tL 5
(unfilled) m (Sub- - (film
(Sub-
2 (sub-~aclioIl)
Transaction) Transaction)
Inti
1 (Thnsaction)
1 (Tkansaction)
i 1
Req. Req.
a
chained with
Star Topology
Two Intermediaries
Req. = Requester
l = System
Resp. = Responder
IIlL = I.nterme%liaIy 1,2,3 . . . = order of interactions
LEGEND
Figure 2 - Chained Transactions
Partitioned ILL-transactions are useful in situations
The requester can allow or prohibit chaining and
where the intermediary acts as an agent of the
can specify, if desired, a list of potential responders
to which a request might be chained. It can also requester to find a suitable responder but has no
interest in participating any further in an ILL-
supply a list of responders which have already been
transaction. This is typical of some union catalogue
tried, so that unnecessary duplication of ILL
facilities.
requests does not occur.
A partitioned ILL-transaction is divided into two
6.3.3 Partitioned ILL-transaction
phases. The first phase, the “processing phase”,
A partitioned ILL-transaction involves at least three
consists of interactions between the requester and
parties: the requester; the responder; and one or
the responder via the intermediary or intermediaries.
more intermediaries. An ILL-request is passed from
During this phase, the sets of interactions between
the intermediary to the responder who responds to
intermediaries and between the intermediary and a
the intermediary, who then responds to the
responder constitute sub-transactions. The second
requester. After the desired item has been shipped
phase of the main ILL-transaction, the “tracking
and the requester has received notification that it
phase”, consists of the direct interactions between
has been shipped, all further interactions take place
the requester and responder. It is used for
directly between the requester and responder; the
monitoring the progress of the loaned item,
intermediary no longer participates in the ILL-
including recalls, renewals, overdues, etc. ILL-
transaction. Figure 3 illustrates a partitioned ILL-
transaction phases are described more fully in
transaction.
clause 6.4.5.
IS0 10160:1997(E)
0 IS0
(Sub-Transaction-processing
p- OdY)
pransaction-tracking
(Transaction-processing
p- OdY)
Req. = Requester
= System
Resp. = Responder
1,2,3 . . . = order of interactions
lint. = Intermediary
LEGEND
Figure 3 - Partitioned Transaction
6.3.4 Distinct ILL-transactions
The requested item could be delivered directly to
The preceding descriptions of chained and
the requester or client, or to the intermediary who
partitioned ILL-transactions imply that the
would then be responsible for delivering it to the
intermediary plays only a relay role during the
requester or client.
tracking phase, i.e. it does not invoke any services
The requester can allow or prohibit partitioning and
such as OVERDUE on its own initiative.
can specify, if desired, a list of potential responders
The ILL service model also allows a potential
to which a request might be sent. It can also supply
intermediary to instead play an active role during
a list of responders which have already been tried,
so that unnecessary duplication of ILL requests does the processing phase of ILL-transactions, and exert
control over all phases of an ILL-transaction by
not occur.
establishing distinct ILL-transactions for its
When a responder is unable to respond successfully
to a request, it may supply a list of potential interactions with the requester and with the
responder. A system which receives an ILL-request
responders to assist the requester.
may act as a final responder (from the viewpoint of
Partitioning and chaining may be mixed within the
same ILL-transaction, as illustrated in Figure 4. the initial requester), and act as an initial requester
Note that when partitioning occurs after chaining, as in a second transaction which it initiates with the
fmal responder. These distinct transactions are not
shown in Figure 4 (a), it overrides chaining, the
required to share any common identification and
effect being the same as multiple instances of
partitioning. However, if chaining follows need not proceed in a synchronized fashion. All
linkage between events on one ILL-transaction and
partitioning, then the chaining effect is preserved.
events on the other is at the discretion and under the
control of the dual-role system. This permits the
0 IS0
IS0 10160:1997(E)
(PtitiOIlCd
Sub-Transaction)
Int
Resp. Resp*
(Wd
T
Subtransaction)
(PZUtitiOIld
ht. Suhansaction)
4 =tL
f
(Transaction)
4 (?kacking Phase
only)
///I
(a) Chained then b) Partitioned then
Partitioned
chained
Req. = Requester
= System
Resp. = Responder
1,2,3 . . .
= order of interactions
IIlL = htermediary
LEGEND
Figure 4 - Mix of Chaining and Partitioning
requester. The intermediary notifies the requester
dual-role system, for example, to initiate an
when forwarding occurs. Figure 5 (a) shows the
OVERDUE request without having received an
simplest case of forwarding involving only one
OVERDUE indication from the responder.
The one constraint on the use of distinct ILL- intermediary. Figure 5 (b) shows the case where
multiple instances of forwarding occur.
transactions is that all items supplied by a final-
The requester can allow or prohibit forwarding and
responder must be shipped and returned via the
dual-role system. This ensures that the dual-role can specify, if desired, a list of potential responders
system is able to track the progress of the two ILL- to which a request might be forwarded. It can also
transactions and can reach terminal states. supply a list of responders which have already been
This style of operation, since it involves two distinct tried, so that unnecessary duplication of ILL
simple ILL-transactions, has no protocol requests does not occur.
When a responder is unable to respond successfully
implications, and is not described further in this
International Standard. to a request, it may supply a list of potential
responders to assist the requester.
6.3.5 Forwarding
A variation of the simple ILL-transaction involves
an intermediary who forwards an ILL request to a
responder and then ceases to participate actively in
the ILL-transaction. The responder receiving the
forwarded request responds directly to the
IS0 10160:1997(E)
0 IS0
a
0 09
Multiple Instances of
One Instance of Forwarding
Forwarding
Req. = Requester
l =System
Resp. = Responder
Int. = Intermediary 1,2,3 . . . = order of interactions
LEGEND
Figure 5 - Simple Transaction with Forwarding
choose to retry the original request at an appropriate
Chaining and forwarding may be mixed within the
time or to look elsewhere. If the original request is
same ILL-transaction, as illustrated in Figure 6 (a)
and (b). repeated, it carries an indication that this is a retry.
The retry is a new transaction or sub-transaction
Partitioning and forwarding also may be mixed
which should form part of the same ILL-transaction
within the same ILL-transaction, as illustrated in
Figure 7 (a) and (b). group as the original request.
For the initial requester, a retry is a new ILL-
6.3.6 Referrals
transaction and so the ILL-transaction-qualifier
When an ILL request is unfilled, the requester may
must be different from that used in the original
choose to refer the request to another responder, as
request but the ILL-transaction-group-qualifier must
illustrated in Figure 8. Each request referral is
be the same (to enable the responder or
considered to be a separate ILL-transaction which is
intermediary to relate the retry to the previous ILL-
part of the same ILL-transaction group.
transaction).
As an implementation consideration, this request
For an intermediary a retry is a new sub-transaction
referral could be performed manually or
and so the sub-transaction-qualifier must be
automatically.
different from that used in the previous request, but
both the ILL-transaction-group-qualifier and the
6.3.7 Retries
ILL-transaction-qualifier must be the same (to
When an ILL request is unfilled with a reason such
enable the responder or next intermediary to relate
as RETRY, ESTIMATE or LOCATIONS-
the retry to the previous sub-transaction).
PROVIDED, the ILL-transaction or sub-transaction
terminates. The requester or intermediary may
0 IS0
IS0 10160:1997(E)
Int.
F-ard)
2 (Sub-
Rev* 4
Transaction)
Ll
Int.
Y
1 (-==tid
i
Req.
a
chain&then Forwarded then
Forwarded chained
Req. = Requester
= System
l
Req. = Responder
1,2,3 . . . = order of interaclions
Int = In-ary
LEGEND
Figure 6 - Chained Transaction with Forwarding
IS0 10160:1997(E)
0 IS0
tTkm=tioll- \;
-gphasc)
a
PartitioIledthcn
Forwarded
(sub-on-
=w@=)
Fonuardcdthen
PartitioIled
Req.=-
@ =systcm
Req. = Responder
13 . . . = order of ixl~ons
IIlt=IU~
LEGEND
c
Figure 7 - Partitioned Transaction with Forwarding
IS0 10160:1997(E) 0 IS0
l = System
Req. = Requester
Resp. = Responder
1,2,3 . . .
= orda of interactions
LEGEND
Figure 8 - Transaction Referrals
0 IS0 IS0 10160:1997(E)
NOT-SUPPLIED
The ILL-transaction has
6.4 ILL-transaction State
reached a stage where the
At any given time, the possible interactions that can
request cannot be filled by
occur between an ILL service-user and service-
the responder.
provider are governed by the state of the ILL-
CONDITIONAL The ILL-transaction has
transaction.
reached a stage where the
The ILL-transaction state, i.e. the information which
request can only be filled if
describes the status of processing of an ILL-
the requester agrees to meet
transaction, is the combination of the requester state,
specified conditions.
the responder state and the states of all intermediaries
CANCEL-PENDING The requester has initiated
involved in the ILL-transaction, where the requester,
responder and intermediary states correspond to the cancellation of the ILL-
transaction but no response
ILL-transaction representation held by the
has been received from the
application-entities within these end-systems.
responder.
Due to a requirement to support systems with
CANCELLED
reduced functionality or where telecommunications The ILL-transaction has
been cancelled by the
costs must be minimized, the ILL protocol supports
responder.
optional messages. This means that for certain
SHIPPED The item has been shipped
interactions, i.e. SHIPPED request, RECEIVED
to the requester.
request, RETURNED request and CHECKED-IN
RECEIVED
request, the sending of a message is optional and The item has been received
from the responder.
therefore a service event in one system may not
RENEW/PENDING A request has been made for
result in a corresponding event in the peer system.
The state of one application-entity in an ILL- the renewal of the item.
RENEW/OVERDUE
transaction cannot necessarily be inferred fkom the A request has been made for
the renewal of an item
state of the other application-entity. However,
which is overdue.
services are available (i.e. the STATUS-QUERY
OVERDUE
and STATUS-OR-ERROR-REPORT services) for The requester has been
obtaining the current state of the other application- notified that the item is
overdue.
entity. It is never necessary for one application-
NOT RECEIVED/
entity to know the state of the other a
...
SLOVENSKI STANDARD
01-november-2005
,QIRUPDWLNDLQGRNXPHQWDFLMD±6NXSLQD]DSRYH]RYDQMHRGSUWLKVLVWHPRY±
'HILQLFLMDDSOLNDFLMVNLKVWRULWHYPHGNQMLåQLþQHL]SRVRMH
Information and documentation -- Open Systems Interconnection -- Interlibrary Loan
Application Service Definition
Information et documentation -- Interconnexion de systèmes ouverts (OSI) -- Définition
du service d'application pour les prêts entre bibliothèques
Ta slovenski standard je istoveten z: ISO 10160:1997
ICS:
01.140.20 Informacijske vede Information sciences
35.240.30 Uporabniške rešitve IT v IT applications in information,
informatiki, dokumentiranju in documentation and
založništvu publishing
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
INTERNATIONAL
Is0
STANDARD 10160
Second edition
1997-04-O 1
Information and documentation - Open
Systems Interconnection - Interlibrary
Loan Application Service Definition
lnforma tion et documentation - lnterconnexion de syst&mes ouverts
(OS/) - Dkfinition du setvice d’application pour /es pr6ts entre
biblioth&ques
Reference number
IS0 10160: 1997(E)
IS0 10160:1997(E)
Contents
Page
.....................................................
1 7.1.14 Overdue
. . . . . .*.
1 SCOPE
.....................................................
7.1.15 Renewal
. . . . . . . . . . . . . . . . . . . . . . . . . . .
2 NORMATIVE REFERENCES 16
.........................................
7.1.16 Renew Answer.
........................................
7.1.17 Lost Notification
....................................................
3 DEFINITIONS
................................
7.1.18 Damaged Notification
.....................
.2
3.1 REFERENCE MODEL DEFINITIONS
.....................................................
7.1.19 Message
3.2 APPLICATION LAYER STRUCTURE DEFINITIONS. 2
..............................................
7.1.20 Status Query
.2
3.3 SERVICE CONVENTIONS DEFINITIONS .
7.1.2 1 Status-or-Error Report .
...............................................
3.4 ILL DEFINITIONS
........................................................
7.1.22 Expiry
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 ABBREVIATIONS . 17
7.2 SPECIFICATION METHOD AND NOTATION
7.3 ILL SERVICES .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 CONVENTIONS
............................... 18
ILL-REQUEST Service
7.3.1
.............................................
6 SERVICE MODEL .
7.3.2 FORWARD Service
.4
.22
6.1 SERVICE-USER AND SERVICE-PROVIDER. .
7.3.3 FORWARD-NOTIFICATION Service. .
...............................
6.1.1 Roles of the Service-user . 22
7.3.4 SHIPPED Service
............................................
6.2 ILL-TRANSACTION 23
7.3.5 ILL-ANSWER Service .
.4
............... 25
6.3 ILL-TRANSACTION TYPES AND TOPOLOGIES .
7.3.6 CONDITIONAL-REPLY Service
.................................. 5
6.3.1 Simple ILL-transaction .
7.3.7 CANCEL Service
................................ 26
6.3.2 Chained ILL-transaction .
7.3.8 CANCEL-REPLY Service
............................
6.3.3 Partitioned ILL-transaction . 26
Service
7.3.9 RECEIVED
............................... 7
..................................... 27
6.3.4 Distinct ILL-transactions Service.
7.3.10 RECALL
..................................................... 27
6.3.5 Forwarding .
7.3.11 RETURNED Service
6.3.6 Referrals . .
7.3.12 CHECKED-IN Service
............................................................ 28
6.3.7 Retries .
7.3.13 OVERDUE Service
...............................
6.4 ILL-TRANSACTION STATE .
7.3.14 RENEW Service
............................................ ......................
6.4.1 Requester-State 29
7.3.15 RENEW-ANSWER Service
...........................................
6.4.2 Responder State 30
7.3.16 LOST Service .
............................................
6.4.3 Terminal States 30
Service. .
7.3.17 DAMAGED
......................................
6.4.4 Intermediary States .
7.3.18 MESSAGE Service
................................ 15
3 1
6.4.5 ILL-transaction Phases .
7.3.19 STATUS-QUERY Service
7.3.20 STATUS-OR-ERROR-REPORT Service .3 1
...........................
7 DEFINITION OF SERVICES
........................................
7.3.2 1 EXPIRY Service
......................................... 15
7.1 SERVICE FEATURES
........................................................ 33
7.1.1 General .
8 SEQUENCES OF PRIMITIVES.
.................................................
7.1.2 ILL Request
8.1 RESILIANCE TO LOST AND OUT-OF-SEQUENCE
.....................................
7.1.3 Request Forwarding MESSAGES .
..............................
7.1.4 Forwarding Notification .
8.1.1 Lost Messages
...................................................... 33
7.1.5 Shipment .
8.1.2 Out-of-Sequence Messages
..................................................
7.1.6 ILL Answer 34
8.2 STATE TRANSITIONS .
........................................ ................... 48
7.1.7 Conditional Reply
8.3 ADDITIONAL SEQUENCING RULES
.................................................
7.1.8 Cancellation
ANNEXES
.......................................
7.1.9 Cancellation Reply
................................. 50
A Time Sequence Diagrams
.......................................................
7.1.10 Receipt
................ 57
B ILL Service and Document Delivery
......................................................... 16
7.1.11 Recall
C Bibliography .
........................................................
7.1.12 Return
..................................................... 16
7.1.13 Check-in
0 IS0 1997
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or
including photocopying and micro-
utilized in any form or by any means, electronic or mechanical,
film, without permission in writing from the publisher.
International Organization for Standardization
Case postale 56 l CH-1211 Geneve 20 l Switzerland
central@iso.ch
Internet
c=ch; a=4OOnet; p=iso; o=isocs; s=central
x.400
Printed in Switzerland
ii
0 IS0 IS0 10160:1997(E)
FOREWORD
IS0 (the International Organization for Standardization) is a worldwide federation
of national standards bodies (IS0 member bodies). The work of preparing
International Standards is normally carried out through IS0 technical committees.
Each member body interested in a subject for which a technical committee has
been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take
part in the work. IS0 collaborates closely with the International Electrotechnical
Commission (IEC) on all matters of electrotechnical standardization.
Draft International Standards adopted by the technical committees are circulated to
the member bodies for voting. Publication as an International Standard requires
approval by at least 75% of the member bodies casting a vote.
International Standard IS0 10 160 was prepared by Technical Committee
ISOITC 46, Information and documentation, Subcommittee SC 4, Computer
applications in information and documentation.
This second edition cancels and replaces the first edition (IS0 10160: 1993), which
has been technically revised.
Annexes A, B and C of this International Standard are for information only.
. . .
IS0 10160:1997(E) 0 IS0
implementation, and by minimizing the number of
INTRODUCTION
messages sent between the sites involved in an
The purpose of the Interlibrary Loan (ILL) standard
ILL-transaction.
is to provide a set of Application Layer services
which can be used by libraries to perform loan-related - Reflection of Current ILL Practices. The purpose
activities in an Open Systems Interconnection (OSI) in defining a protocol is not to introduce a new
environment, as defined by IS0 7498. method for performing an ILL-transaction, but
The goal of Opens Systems Interconnection is to
rather to formalize current practices in a way that
allow, with a minimum of technical agreement allows existing systems to communicate with each
outside the interconnection standards, the other in a standardized way, as well as to allow
interconnection of information processing systems:
newer automated systems to take full advantage of
the protocol’s potential. However, it is recognized
- from different manufacturers;
that this International Standard may not be
- under different managements;
universally applicable to all existing ILL systems
- of different levels of complexity; and
without some modification, due to the wide
variation in their capabilities.
- of different technologies.
There is an inherent trade off in any attempt to
The ILL service provides capabilities to request the
reconcile these divergent objectives. For example,
loan of returnable bibliographic items, such as books,
minimizing ILL-transaction costs may result in some
or to request non-returnable items, such as
loss of control over the ILL-transaction. Reducing the
photocopies of journal articles. Related procedures,
number of messages sent lowers the
such as loan renewal, item recall, overdue
telecommunications cost and also lowers the operator
notification, etc. are also supported by this service.
costs as there is less need for the operator to initiate
The purpose of the service definition is to defme the
and control the communications operations.
communications aspects of ILL processing in terms
However, by reducing the total number of messages,
of a set of services provided to a user by an
some level of information regarding the ILL-
application-service-element (ASE). Performing an
transaction is lost as is the coordination between the
ILL-transaction involves a user invoking the services
requesting and responding libraries. By reducing the
in the prescribed order.
total number of stages through which a ILL-
The focus of ILL activity is the bibliographic item,
transaction must go (i.e. states), the operator interface
which may be a book, periodical, journal article,
of an automated system can be made simpler, with an
microform, etc. The ILL application is concerned
associated reduction in requisite demands on the
with procedures relating to the loan of these items
operator.
between libraries or to the interchange of copies
The approach taken in this International Standard is
thereof.
to set the mandatory requirements that all open
This service definition strives to satisfy a number of
systems must support in order to achieve an
objectives, including:
acceptable degree of coordination between automated
- Control of ILL-transactions. The services must
parties to an ILL-transaction. Additional optional
provide a means of controlling the ILL-
features are defined which allow implementors to
transaction in terms of constraining allowable
achieve a greater degree of control if it is desired.
actions, exchanging information, tracking a
NOTE - The mandatory requirements of this
borrowed item, and synchronizing the activity of
International Standard may, however, exceed the
the two or more sites involved in the ILL-
capabilities and/or needs of some existing manual or
transaction.
semi-automated ILL systems.
- Interworking of Various Systems. The ILL
This International Standard is one of a number of
activity will continue to be performed using a
related standards supporting the interconnection of
combination of manual and automated systems.
library systems. These standards can be used by
The ILL service and protocol must recognize this
themselves or in a cooperative manner to support
fact and allow systems with varying degrees of
library applications requiring a mixture of
automation to be able to interwork, i.e.
communications services. For example, IS0 10 163,
communicate with each other in a meaningful
which supports remote access to bibliographic
way.
databases, could be used in conjunction with the ILL
- Minimizing the Costs of ILL-transactions. The
protocol to obtain item identification information.
costs associated with an ILL-transaction include
The control and management of interactions among
both operator costs and communications costs. An
such bibliographic applications are outside the scope
ILL protocol should attempt to minimize the costs
of this International Standard.
incurred by implementations conforming to the
Security and accounting issues as they relate to ILL
protocol. This can be done by minimizing the
operations are for further study.
operator intervention required by the protocol
1v
IS0 10160:1997(E)
INTERNATIONAL STANDARD 0 IS0
Information and documentation -
Open Systems Interconnection -
Interlibrary Loan Application Service Definition
Information processing systems
IS0 7498-2: 1989
1 Scope
- Open Systems Interconnection
This International Standard is an Application Layer
- Basic Reference Model -
standard within the Open Systems Interconnection
Part 2: Security Architecture.
framework defined by IS0 7498.
This standard defines the services for Interlibrary
IS0 7498-3: 1989
Information processing systems
Loan. These services are provided by the use of the
- Open Systems Interconnection
ILL protocol in conjunction with the supporting
- Basic Reference Model -
telecommunications service which may be a store-
Part 3: Naming and addressing.
and-forward messaging service, such as that
provided by the MOTIS Standards, IS0 1002 l-4
ISOIIEC 7498-4: Information processing systems
etc.; or a direct connection-mode service using
1989 - Open Systems Interconnection
IS0 8822 and IS0 8649.
- Basic Reference Model -
This standard does not specify individual
Part 4: Management framework.
implementations or products, nor does it constrain
NOTE - ISO/IEC 7498-l : 1994,
the implementation of entities and interfaces within
IS0 7498-2: 1989, IS0 7498-3:
a computer system. Computer systems may range
1989 and ISO/IEC 7498-4: 1989
from stand-alone workstations to mainframes.
supersede IS0 7498: 1984.
This standard is intended for use by libraries,
However, when this International
information utilities such as union catalogue centres,
Standard was under development,
and any other system which processes bibliographic
the previous edition was valid and
information. These systems may participate in an this International Standard is
therefore based on this edition,
interlibrary loan transaction in the role of requester
which is given below.
(i.e. an initiator of ILL requests), responder (i.e. a
provider of bibliographic material or information)
IS0 7498: 1984 Information Processing Systems
and/or intermediary (i.e. an agent that acts on behalf
- Open Systems Interconnection
of a requester to find suitable responders).
Various interworking topologies are supported, - Basic Reference Model.
ranging from simple two-party interactions to multi-
party interactions. ISO/IEC 1073 1: Information technology - Open
There is no requirement for conformance to this 1994 Systems Interconnection - Basic
standard. Conformance is required only for the ILL
Reference Model - Conventions
protocol specification. for the definition of OS1
services.
NOTE - ISO/IEC 1073 1: 1994
supersedes ISO/TR 8509: 1987.
2 Normative references
However, when this International
Standard was under development,
The following standards contain provisions which,
ISO/TR 8509 was valid and this
through reference in this text, constitute provisions
International Standard is therefore
of this International Standard. At the time of
based on ISO/TR 8509, which is
publication, the editions indicated were valid. All
given below.
standards are subject to revison, and parties to
agreements based on this International Standard are
ISOITR 8509: 1987
Information Processing Systems
encouraged to investigate the possibility of applying
- Open Systems Interconnection
the most recent editions of the standards indicated
- Service Conventions.
below. Members of IEC and IS0 maintain registers
of currently valid International Standards.
ISO/IEC 10026- 1:
Information Technology - Open
Systems Interconnection -
ISOIIEC 7498- 1: Information technology - Open
Distributed Transaction -
Systems Interconnection - Basic
Processing - Part 1: OS1 TP
Reference Model: The Basic
model.
Model.
0 IS0
IS0 10160:1997(E)
Information and Documentation application-protocol-control-information
IS0 10 16 1- 1: 1997
- Open Systems Interconnection using the Presentation Service.
- Interlibrary Loan Application
3.2.2 application-context: A set of rules shared
Protocol Specification - Part 1:
in common by two application-entity-
Protocol specification.
invocations governing their behavior in
order to enable their cooperative operation.
NOTE - An application-context is a shared
conceptual schema for the universe of
3 Definitions
discourse for communication.
For the purposes of this International Standard, the
following definitions apply.
3.2.3 application-context-definition: The
description of an application-context.
3.1 Reference Model Definitions
3.2.4 application-entity-invocation: A specific
This International Standard is based on the concepts
utilization of part or all of the capabilities
developed in IS0 7498: 1984 and makes use of the
of a given application-entity in support of
following terms found in it. These terms are
the communications requirements of an
replicated here as a convenience to the reader.
application-process-invocation.
3.1.1 application-entity: The aspects of an
application-process pertinent to OSI. 3.2.5 application-process-invocation: A
specific utilization of part or all of the
3.1.2 Application Layer: The seventh and
capabilities of a given application-process
highest layer in the Reference Model for
in support of a specific occasion of
Open Systems Interconnection (OSI); it
information processing.
serves as the window between
correspondent application-processes which
3.3 Service Conventions Definitions
are using the OS1 to exchange meaningful
This International Standard makes use of the
information.
following terms defined in ISO/TR 8509: 1987.
3.1.3 application-protocol-data-unit: A unit of
3.3.1 indication primitive: A representation of
data specified in an application-protocol
an interaction in which a service-provider
and consisting of application-protocol-
either:
information and possibly application-user-
a. indicates that it has, on its own
data.
initiative, invoked some procedure; or
3.1.4 application-service-element: That part of
b. indicates that a procedure has been
an application-entity which provides an
invoked by the service-user at the peer
OS1 environment capability, using
service-access-point.
underlying services when appropriate.
3.3.2 non-confirmed service: A distinct part of
(N)-service: A capability of the @I)-layer
3.1.5
the total @Q-service which does not result
and the layers beneath it, which is provided
in an explicit confirmation from the
to (N+l)-entities at the boundary between
service-provider to the initiating service-
the @I)-layer and the (N+l)-layer.
user.
-
NOTE - An application-service does not provide a
3.3.3 provider-initiated service: A distinct part
capability to higher layer entities, but
of the total @Q-service which is initiated
rather to application-processes.
by the service-provider rather than the
3.1.6 presentation-service: A capability of the
service-user.
Presentation Layer and the layers beneath
3.3.4
request primitive: A representation of an
it, which is provided to application-entities
interaction in which a service-user invokes
at the boundary betsween the Presentation
some procedure.
and the Application Layer.
3.3.5 service primitive: An abstract,
implementation-independent representation
3.2 Application Layer Structure Definitions
of an interaction between service-user and
This International Standard makes use of the
following terms defined in ISO/IEC 9545: 1989. the service-provider.
application-association: A cooperative
3.2.1
3.3.6 service-provider: An abstract of the
relationship between two application-
totality of those entities which provide a
entity-invocations’ for the purpose of
service to peer service-users. _
communication of information and co-
3.3.7 service-user: An entity in a single open
ordination of their joint operation. This
system that makes use of a service.
relationship is formed by the exchange of
Ifi0 10160:1997(E)
0 IS0
3.4.12 partitioned ILL-transaction: An ILL-
3.4 ILL Definitions
transaction involving three parties, i.e. a
3.4.1 bibliographic item: A monograph, serial,
requester, a responder and an intermediary,
microform, film, video recording, sound
where the intermediary acts as a relay of
recording or other item of information held
ILL messages during the processing phase,
by a library or some organization. A
and where the requester and responder
bibliographic item may assume different
interact directly during the tracking phase.
forms, e.g., a book may be printed on
paper or represented electronically.
3.4.13 processing phase: That phase of an ILL-
transaction up to and including shipment of
3.4.2 chained ILL-transaction: An ILL-
a requested item.
transaction involving three or more parties,
i.e. a requester, a responder and one or
3.4.14 requester: The party which has generated
more intermediaries, where each
an ILL-REQUEST.
intermediary acts as a relay for all ILL
3.4.15 responder: The party which has received
messages.
an ILL-REQUEST.
3.4.3 electronic delivery: Delivery of an
3.4.16 simple ILL-transaction: An ILL-trans-
electronic representation of a requested
action involving only two active parties, a
item via a telecommunication-based
requester and responder.
service.
3.4.17 sub-transaction: A part of an ILL-
3.4.4 final-responder: The institution which
transaction involving interactions between
supplies a requested item. This term is
an intermediary and a responder or another
used when it is necessary to distinguish
intermediary.
between the responder of an ILL-
3.4.18 supplier: The party that has supplied the
transaction and the responder of an ILL-
requested item. It need not be the same as
sub-transaction.
the final-responder.
3.4.5 ILL-transaction: A single, complete
3.4.19 terminal state: A state from which no
instance of the whole ILL cycle, including
transition to another state can be made,
all of the actions, service primitives, and
e.g.:
messages involved from the initial ILL-
REQUEST until the cycle is concluded, as When a photocopy is provided, SHIPPED
with the return of the requested material. is the terminal state for the responder,
RECEIVED is the terminal state for the
3.4.6 ILL-transaction group: A set of related
requester.
ILL-transactions initiated by the same
CANCELLED is a terminal state for both
requester.
the requester and responder.
ILL-transaction state: The information
3.4.7
3.4.20 tracking phase: That phase of an ILL-
which describes the current processing
transaction after shipment and receipt of a
status of an ILL-transaction; it is the
returnable item, including renewals,
combination of the requester state, the
overdues and item return.
responder state and the states of all
intermediaries involved in an ILL- 3.4.21 user: (see service-user, clause 3.3.7)
transaction.
initial-requester: Person or institution
3.4.8
4 Abbreviations
which initiates an ILL-transaction; this
ACID - Atomicity, consistency, isolation &
term is used when it is necessary to
durability
distinguish between the requester of an
ASE -
Application-service-element
ILL-transaction and the requester of an
ILL-sub-transaction.
AS0 - Application service object
intermediary: A responder which either
3.4.9 ILL -
Interlibrary loan
forwards a request to another library or
MOTIS - Message Oriented Text Interchange
institution for processing, or initiates
System
chained or partitioned sub-transactions
OS1 -
Open systems interconnection
with other responders.
3.4.10 item: (see bibliographic item, clause 3.41)
5 Conventions
3.4.11 parameter: A functionally related group
This International Standard uses the conventions
of one or more data elements.
defined in ISO/TR 8509.
0 IS0
IS0 10160:1997(E)
durability, as applied to transactions in the OS1
6 Service Model
transaction processing model (IS0 100260 1).
6.1 Service-user and Service-provider
ILL-transactions may overlap in time, i.e. multiple
The ILL application is modelled as a distributed
ILL-transactions may be processed concurrently by
collection of application-processes, each of which is
a given open system.
located in a separate real open system, e.g. a library
An ILL-transaction may be initiated only by a
system.
requester.
Within each application-process, there are two types
A sub-transaction refers to the set of
of functions: local processing functions; and
communications activity involving an intermediary
communications-related functions, i.e. OSI-related
and a responder or another intermediary, and is
functions. The local processing functions deal with
related to an ILL-transaction initiated by a
such activities as database manipulation, report
requester. A sub-transaction is not, in itself, an
generation, etc.; these are outside the scope of this
actual ILL-transaction.
International Standard. Within each system, those
A sub-transaction may be initiated only by an
aspects of the application-process which are
intermediary.
pertinent to OS1 are called the application-entity.
When an ILL-transaction involves three or more
Each application-entity in turn includes one or more
parties, the initial-requester is the party that
application-service-elements (ASEs), one of which
generated the initial ILL-REQUEST. The final-
is the ILL ASE. These ASEs provide
responder is the last recipient of an ILL-REQUEST
communications-related services to the service-user.
for that ILL-transaction.
To do this they engage in protocol exchanges with
Individual ILL-transactions may be related to each
peer application-entities in other systems and they
other, for example a succession of attempts by a
take advantage of supporting services within the
requester to contact different responders directly.
Application Layer and the layers below it.
Such ILL-transactions form an ILL-transaction
Relationships with other ASEs are defined as part of
group. It is at the discretion of the initiator to
an application-context-definition. This is outside the
determine whether such ILL-transactions are to be
scope of this International Standard.
related explicitly through the ILL-transaction
The set of all ILL ASEs, supporting ASEs and the
identifier; such grouping of ILL-transactions may be
lower layer services across all systems together
done, for example, to provide a historical record of
form the ILL service-provider.
the related steps associated with an interlibrary loan.
Each ILL-transaction has a unique ILL-transaction
6.1.1 Roles of the Service-user
identifier that is used to identify the state and other
A service-user involved in ILL activity takes on one
descriptive information maintained by ILL-
of three roles: requester, responder or intermediary.
application-entities for that ILL-transaction. The
The requester generates ILL requests.
ILL-transaction identifier has the following
The responder receives ILL requests and is the
components:
potential supplier of requested items.
initial-requester-id: identification of the requester
The intermediary is a responder which does not
who initiated the ILL-transaction;
itself satisfy an ILL request and which passes the
request to another responder on behalf of the ILL-transaction-group-qualifier: distinguishes a
requester.
group of ILL-transactions from all other active ILL-
The actual supplier of requested items is normally a
transaction groups associated with the initial-
responder; however, the service model allows for requester;
institutions that do not receive ILL requests, as
ILL-transaction-qualifier: distinguishes an ILL-
defined in this International Standard, to supply the
transaction from all other ILL-transactions within an
requested items. For example, an institution that
ILL-transaction group.
supports only postal and telephone ILL requests
The ILL-transaction identifier of each sub-
may have another institution that supports electronic
transaction has the following additional component,
ILL requests act as a responder on its behalf.
which is unique within, and only within, the scope
6.2 ILL-transaction
of a single intermediary:
An ILL-transaction is a single, complete instance of
sub-transaction-qualifier: distinguishes this sub-
the whole ILL cycle, including all of the actions,
transaction from all other sub-transactions within an
service primitives, and messages involved from the
ILL-transaction initiated by the intermediary.
initial ILL-REQUEST until the cycle is concluded,
as with the return of the requested material. The
6.3 ILL-transaction Types and Topoi’ogies
term “ILL-transaction” is used in this International
There are three types of ILL-transactions: simple,
Standard in its most general sense, and does not
chained and partitioned.
imply an atomic unit of work with the ACID
properties of atomicity, consistency, isolation and
0 IS0 IS0 10160:1997(E)
The interactions between the requester and the first
6.3.1 Simple ILL-transaction
intermediary define the main ILL-transaction. The
A simple ILL-transaction involves two active
parties, the requester and responder. In its most set of interactions between an intermediary and the
basic manifestation, the requester and responder responder constitute a sub-transaction, as do the
interactions between each pair of intervening
interact in a point-to-point manner, as illustrated in
intermediaries. Figure 2 (a) illustrates a chained
Figure 1.
ILL-transaction with two intermediaries (and hence
All ILL-transactions initiated by a requester begin
as simple ILL-transactions. A requester may, two sub-transactions).
If a sub-transaction results in non-fulfillment of the
however, indicate as part of the ILL-request that the
ILL request, the intermediary may initiate a new
responder has permission to change the ILL-
transaction-type to chained or partitioned. If the sub-transaction to another responder. The
responder does change the type, this responder then intermediary may try several potential responders in
turn. This leads to a star ILL-transaction topology
becomes an intermediary.
with the intermediary as the hub, as illustrated in
When a responder is unable to respond successfully
Figure 2 (b).
to a request, it may supply a list of potential
responders to assist the requester. The responder may supply a list of potential
responders to the intermediary to assist it in making
6.3.2 Chained ILL-transaction
a selection.
A chained ILL-transaction involves at least three
The requested item could be delivered directly to
parties: the requester, the responder and one or
the requester or client, or to one of the
more intermediaries. An ILL-request is passed from
intermediaries who would then be responsible for
one intermediary (to another intermediary) to the
delivering it to the requester or client.
responder in a chain, with each intermediary acting
as a relay for all ILL messages. There is no direct
interaction between the requester and responder.
Resp.
i
Req.
l = System
Req. = Requester
Resp. = Responder 1,2,3 . . . = order of interactions
LEGEND
Figure 1 - Simple Transaction
IS0 10160:1997(E) 0 IS0
Resp.
Resp.
Resp.
t
3 (Sub-Transaction)
/ Transaction)
Transaction) \
IlIt. Resp. Resp.
2 =tL 5
(unfilled) m (Sub- - (film
(Sub-
2 (sub-~aclioIl)
Transaction) Transaction)
Inti
1 (Thnsaction)
1 (Tkansaction)
i 1
Req. Req.
a
chained with
Star Topology
Two Intermediaries
Req. = Requester
l = System
Resp. = Responder
IIlL = I.nterme%liaIy 1,2,3 . . . = order of interactions
LEGEND
Figure 2 - Chained Transactions
Partitioned ILL-transactions are useful in situations
The requester can allow or prohibit chaining and
where the intermediary acts as an agent of the
can specify, if desired, a list of potential responders
to which a request might be chained. It can also requester to find a suitable responder but has no
interest in participating any further in an ILL-
supply a list of responders which have already been
transaction. This is typical of some union catalogue
tried, so that unnecessary duplication of ILL
facilities.
requests does not occur.
A partitioned ILL-transaction is divided into two
6.3.3 Partitioned ILL-transaction
phases. The first phase, the “processing phase”,
A partitioned ILL-transaction involves at least three
consists of interactions between the requester and
parties: the requester; the responder; and one or
the responder via the intermediary or intermediaries.
more intermediaries. An ILL-request is passed from
During this phase, the sets of interactions between
the intermediary to the responder who responds to
intermediaries and between the intermediary and a
the intermediary, who then responds to the
responder constitute sub-transactions. The second
requester. After the desired item has been shipped
phase of the main ILL-transaction, the “tracking
and the requester has received notification that it
phase”, consists of the direct interactions between
has been shipped, all further interactions take place
the requester and responder. It is used for
directly between the requester and responder; the
monitoring the progress of the loaned item,
intermediary no longer participates in the ILL-
including recalls, renewals, overdues, etc. ILL-
transaction. Figure 3 illustrates a partitioned ILL-
transaction phases are described more fully in
transaction.
clause 6.4.5.
IS0 10160:1997(E)
0 IS0
(Sub-Transaction-processing
p- OdY)
pransaction-tracking
(Transaction-processing
p- OdY)
Req. = Requester
= System
Resp. = Responder
1,2,3 . . . = order of interactions
lint. = Intermediary
LEGEND
Figure 3 - Partitioned Transaction
6.3.4 Distinct ILL-transactions
The requested item could be delivered directly to
The preceding descriptions of chained and
the requester or client, or to the intermediary who
partitioned ILL-transactions imply that the
would then be responsible for delivering it to the
intermediary plays only a relay role during the
requester or client.
tracking phase, i.e. it does not invoke any services
The requester can allow or prohibit partitioning and
such as OVERDUE on its own initiative.
can specify, if desired, a list of potential responders
The ILL service model also allows a potential
to which a request might be sent. It can also supply
intermediary to instead play an active role during
a list of responders which have already been tried,
so that unnecessary duplication of ILL requests does the processing phase of ILL-transactions, and exert
control over all phases of an ILL-transaction by
not occur.
establishing distinct ILL-transactions for its
When a responder is unable to respond successfully
to a request, it may supply a list of potential interactions with the requester and with the
responder. A system which receives an ILL-request
responders to assist the requester.
may act as a final responder (from the viewpoint of
Partitioning and chaining may be mixed within the
same ILL-transaction, as illustrated in Figure 4. the initial requester), and act as an initial requester
Note that when partitioning occurs after chaining, as in a second transaction which it initiates with the
fmal responder. These distinct transactions are not
shown in Figure 4 (a), it overrides chaining, the
required to share any common identification and
effect being the same as multiple instances of
partitioning. However, if chaining follows need not proceed in a synchronized fashion. All
linkage between events on one ILL-transaction and
partitioning, then the chaining effect is preserved.
events on the other is at the discretion and under the
control of the dual-role system. This permits the
0 IS0
IS0 10160:1997(E)
(PtitiOIlCd
Sub-Transaction)
Int
Resp. Resp*
(Wd
T
Subtransaction)
(PZUtitiOIld
ht. Suhansaction)
4 =tL
f
(Transaction)
4 (?kacking Phase
only)
///I
(a) Chained then b) Partitioned then
Partitioned
chained
Req. = Requester
= System
Resp. = Responder
1,2,3 . . .
= order of interactions
IIlL = htermediary
LEGEND
Figure 4 - Mix of Chaining and Partitioning
requester. The intermediary notifies the requester
dual-role system, for example, to initiate an
when forwarding occurs. Figure 5 (a) shows the
OVERDUE request without having received an
simplest case of forwarding involving only one
OVERDUE indication from the responder.
The one constraint on the use of distinct ILL- intermediary. Figure 5 (b) shows the case where
multiple instances of forwarding occur.
transactions is that all items supplied by a final-
The requester can allow or prohibit forwarding and
responder must be shipped and returned via the
dual-role system. This ensures that the dual-role can specify, if desired, a list of potential responders
system is able to track the progress of the two ILL- to which a request might be forwarded. It can also
transactions and can reach terminal states. supply a list of responders which have already been
This style of operation, since it involves two distinct tried, so that unnecessary duplication of ILL
simple ILL-transactions, has no protocol requests does not occur.
When a responder is unable to respond successfully
implications, and is not described further in this
International Standard. to a request, it may supply a list of potential
responders to assist the requester.
6.3.5 Forwarding
A variation of the simple ILL-transaction involves
an intermediary who forwards an ILL request to a
responder and then ceases to participate actively in
the ILL-transaction. The responder receiving the
forwarded request responds directly to the
IS0 10160:1997(E)
0 IS0
a
0 09
Multiple Instances of
One Instance of Forwarding
Forwarding
Req. = Requester
l =System
Resp. = Responder
Int. = Intermediary 1,2,3 . . . = order of interactions
LEGEND
Figure 5 - Simple Transaction with Forwarding
choose to retry the original request at an appropriate
Chaining and forwarding may be mixed within the
time or to look elsewhere. If the original request is
same ILL-transaction, as illustrated in Figure 6 (a)
and (b). repeated, it carries an indication that this is a retry.
The retry is a new transaction or sub-transaction
Partitioning and forwarding also may be mixed
which should form part of the same ILL-transaction
within the same ILL-transaction, as illustrated in
Figure 7 (a) and (b). group as the original request.
For the initial requester, a retry is a new ILL-
6.3.6 Referrals
transaction and so the ILL-transaction-qualifier
When an ILL request is unfilled, the requester may
must be different from that used in the original
choose to refer the request to another responder, as
request but the ILL-transaction-group-qualifier must
illustrated in Figure 8. Each request referral is
be the same (to enable the responder or
considered to be a separate ILL-transaction which is
intermediary to relate the retry to the previous ILL-
part of the same ILL-transaction group.
transaction).
As an implementation consideration, this request
For an intermediary a retry is a new sub-transaction
referral could be performed manually or
and so the sub-transaction-qualifier must be
automatically.
different from that used in the previous request, but
both the ILL-transaction-group-qualifier and the
6.3.7 Retries
ILL-transaction-qualifier must be the same (to
When an ILL request is unfilled with a reason such
enable the responder or next intermediary to relate
as RETRY, ESTIMATE or LOCATIONS-
the retry to the previous sub-transaction).
PROVIDED, the ILL-transaction or sub-transaction
terminates. The requester or intermediary may
0 IS0
IS0 10160:1997(E)
Int.
F-ard)
2 (Sub-
Rev* 4
Transaction)
Ll
Int.
Y
1 (-==tid
i
Req.
a
chain&then Forwarded then
Forwarded chained
Req. = Requester
= System
l
Req. = Responder
1,2,3 . . . = order of interaclions
Int = In-ary
LEGEND
Figure 6 - Chained Transaction with Forwarding
IS0 10160:1997(E)
0 IS0
tTkm=tioll- \;
-gphasc)
a
PartitioIledthcn
Forwarded
(sub-on-
=w@=)
Fonuardcdthen
PartitioIled
Req.=-
@ =systcm
Req. = Responder
13 . . . = order of ixl~ons
IIlt=IU~
LEGEND
c
Figure 7 - Partitioned Transaction with Forwarding
IS0 10160:1997(E) 0 IS0
l = System
Req. = Requester
Resp. = Responder
1,2,3 . . .
= orda of interactions
LEGEND
Figure 8 - Transaction Referrals
0 IS0 IS0 10160:1997(E)
NOT-SUPPLIED
The ILL-transaction has
6.4 ILL-transaction State
reached a stage where the
At any given time, the possible interactions that can
request cannot be filled by
occur between an ILL service-user and service-
the responder.
provider are governed by the state of the ILL-
CONDITIONAL The ILL-transaction has
transaction.
reached a stage where the
The ILL-transaction state, i.e. the information which
request can only be filled if
describes the status of processing of an ILL-
the requester agrees to meet
transaction, is the combination of the requester state,
specified conditions.
the responder state and the states of all intermediaries
CANCEL-PENDING The requester has initiated
involved in the ILL-transaction, where the requester,
responder and intermediary states correspond to the cancellation of the ILL-
transaction but no response
ILL-transaction representation held by the
has been received f
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...