This is z3950-spec.txt in view mode; [Download] [Up]
ANSI Z39.50 Version 2
THIRD DRAFT
(Z39.50/V2D3)
May 1991
This is an interim draft, for internal NISO use, subject to review and
revision.
STATUS: This is the third draft of version 2 of ANSI Z39.50-1988
(Z39.50/V2D3).
1. INTRODUCTION
This is one of a set of standards produced to facilitate the
inter-connection of computer systems. It is positioned with respect to
other related standards by the Open Systems Interconnection (OSI) basic
reference model (ISO 7498). The aim of Open Systems Interconnection is to
allow the interconnection of computer systems, with a minimum of technical
agreement outside the interconnection standards.
This standard defines a protocol within the application layer of the
reference model, and is concerned in particular with the retrieval of
information stored in machine readable databases.
1.1 SCOPE AND FIELD OF APPLICATION
This standard describes the Information Retrieval application service
(section 3) and specifies the Information Retrieval application protocol
(section 4), for Open Systems Interconnection.
The Information Retrieval application service is described in terms of
services which provide capabilities within an application. The description
neither specifies nor constrains the implementation within a computer
system. The purpose of the service description is to define the functions
that the protocol must support.
The protocol specification includes the definition of the protocol
control information, the rules for exchanging this information, and the
conformance requirements to be met by implementation of this protocol.
This standard is intended particularly for use in the area of library
and information sciences. It addresses connection-oriented,
program-to-program communication utilizing telecommunications. It does not
address the interchange of information with terminals or via other physical
media.
1.2 MODEL
The objective of this standard is to facilitate the open
interconnection of database users with database providers. It is necessary
to distinguish between the set of OSI standards and the hardware and
software implementation of a system using the protocols specified in these
standards. The ways in which databases are implemented differ
considerably; different systems have different styles for describing the
storage of data and the means by which it can be accessed. A common,
abstract model is therefore used in describing databases, to which an
individual system can map its implementation. This enables different
systems to communicate in standard, mutually understandable terms.
The term "database" as used in this standard refers to a collection of
one or more files, each with a unique name. A group of files within a
database may also have a name and be accessed as a single database. The
unit of information for retrieval from a database is a record. All of the
records within a given file have a common structure, contain a common set
of data elements and a common set of access points. An access point is a
unique or non-unique key which can be specified either singly or in
combination with other access points in a search for records. An access
point may be equivalent to a data element, be derived from a data element,
or the combination of all or part of two or more data elements.
A search query may be applied to a database, specifying values to be
matched against the access points of the database. The subset of records
formed by applying the search query is termed the result set. A result set
may itself be referenced in a subsequent search query statement and
manipulated to form a new result set.
For generality, it is assumed that query processing does not
necessarily require physical access to records; a result set is thus
assumed to be the identification of (e.g. pointers to) records, as opposed
to the actual set of records, selected by a query. (It is not assumed that
the database records are locked. Methods of concurrency control, which
would prevent modification or deletion of result set records, are not
addressed by this standard.) A result set may be used as a selection
mechanism for the transfer of records between systems; the result set
itself is considered to be a purely local data structure and is not
transfered (that is, records are transferred, but not the local pointers to
the records).
A generic search query statement is composed of a database name
followed by a query statement. The Type-1 query statement defined in this
standard consists of either a single access point clause, or several access
point clauses linked by logical operators. For example:
"In the database which is named 'Books' find all of the records for
which the access point 'title word' contains the value 'evangeline'
AND the access point 'author' contains the value 'longfellow'".
Following the processing of a search, the set of items with the specified
properties (the result set) is made available by the target system, to the
origin system, for subsequent retrieval requests. The logical structure of
a result set is that of a named, ordered list of triples consisting of (a)
an ordinal number corresponding to the position of the triple in the list,
(b) a database name, and (c) a unique record identifier (of local
significance only) within the database named in (b). A result set item is
referenced by its position within the result set, that is, by (a).
1.3 REFERENCES
ISO 7498 -- Information Processing Systems - Open Systems Interconnection -
Basic Reference Model
ISO 8649 -- Information Processing Systems - Open Systems Interconnection -
Service Definition for Association Control Service Element
ISO 8650 -- Information processing systems - Open Systems Interconnection -
Service Definition for Association Control Protocol Specification
ISO 8822 -- Information Processing Systems - Open Systems Interconnection -
Connection Oriented Presentation Service Definition
ISO 8824 -- Information Processing Systems - Open Systems Interconnection -
Abstract Syntax Notation One (ASN.1)
ANSI X3.4 -- Information Processing - Coded Character Sets - 7-bit American
National Standard Code for Information Interchange (7-bit ASCII)
ISO 2709 -- Documentation - Format for Bibliographic Information
Interchange on Magnetic Tape
2. DEFINITIONS
In cases below where formal definitions appear in other standards,
references to those standards are given, in those cases descriptions and/or
alternate definitions (indented) are sometimes provided. Alternate
definitions apply only to the Information Retrieval application service and
protocol, and only within the context of this document.
APDU - See Application Protocol Data Unit
Application Association -- See ISO xxxx
For the Information Retrieval service and protocol, an application
association is analogous to an individual communication session between a
database user and a database provider. Each association consists of an
origin application and a target application, and these roles may not be
reversed within an association.
Application Entity -- See ISO xxxx.
Application Protocol --
See ISO xxxx.
The rules governing the format and exchange of information
between an origin and target application.
Application Protocol Control Information -- See ISO xxxx.
The information conveyed by application protocol data units.
Application Protocol Data Unit -- See ISO xxxx.
A unit of data passed between an origin and a target.
Application Service User -- See ISO xxxx.
(The concept of service-user is employed to facilitate the specification
of protocol procedures and is not analogous to the database user.)
Connection Oriented Communication -- See ISO xxxx.
Database Provider -- The application which provides access to a database
local to that application.
Database User -- The application which accesses a remote database.
Origin Application -- The application that initiates an association and is
the source of requests during the association.
The database user.
Name -- See ISO xxxx.
OSI -- Open Systems Interconnection.
Primitive -- See ISO xxxx.
Result set -- An ordered list of triples consisting of (a) an ordinal
number corresponding to the position of the triple in the list, (b) a
database name, and (c) a unique record identifier (of local significance
only) within the database named in (b). A result set is formed by applying
a search query.
Service provider -- See ISO xxxx.
(The concept of service-provider is employed to facilitate the
specification of protocol procedures. It is not analogous to the database
provider, and it does not refer to providers of telecommunication
services.)
Target Application -- The application that accepts an association and is
the sink for requests during the association.
The database provider.
Primitive Name -- See ISO xxxx.
3. INFORMATION RETRIEVAL SERVICE
This section defines the Information Retrieval service, which is
supported by the Information Retrieval protocol.
3.1 GENERAL CHARACTERISTICS OF THE INFORMATION RETRIEVAL SERVICE
The service definition describes an activity between two applications
on different computers: an initiating application, the origin, and a
responding application, the target. The target is associated with one or
more databases. Communication between origin and target is via an
application association. An association is explicitly established by the
origin and may be explicitly terminated by either origin or target, or
implicitly terminated by a communication failure or other external event.
The roles of origin and target may not be reversed within an
association. An association cannot be restarted, thus no status information
is retained once an association is released.
The complete application service is composed of the association control
service element, which provides association management, and one or more
specific application services, such as the Information Retrieval
application service. There are three distinct phases during the life of an
application association: establishment, information transfer, and
termination. The association control service element provides all of the
services required during the establishment and termination phases,
including the selection of an application context specifying, among other
things, the set of service elements which are valid during the information
transfer phase. Section 4.2.1.2 specifies those services for association
control which are assumed by the Information Retrieval service.
3.2 FACILITIES OF THE INFORMATION RETRIEVAL SERVICE
There are seven facilities defined by this standard. All consist of a
single service except the Termination facility, which consists of two
services.
(1) Initialization Facility Init Service: Init request from the origin
followed (possibly after one or more intervening Access-control and/or
Resource-control request/response sequences) by an Init response from the
target
(2) Search Facility Search Service: Search request from the origin
followed (possibly after one or more intervening Access-control and/or
Resource-control request/response sequences) by a Search response from the
target
(3) Retrieval Facility Present Service: Present request from origin
followed (possibly after one or more intervening Access-control and/or
Resource-control request/response sequences) by a Present response from the
target
(4) Result-set-delete Facility Delete Service: Delete request from the
origin followed (possibly after one or more intervening Access-control
and/or Resource-control request/response sequences) by a Delete response
from the target
(5) Access Control Facility Access-control service: Access-control
request by the target, following an Init, Search, Present, or Delete
request by the origin, or following a Resource-control or Access-control
request/response sequence, and followed by an Access-control response from
the origin
(6) Accounting/Resource Control Facility Resource-control Service:
Resource-control request by the target, following an Init, Search, Present,
or Delete request by the origin, or following a Resource-control or
Access-control request/ response sequence, and followed by a
Resource-control response from the origin.
(7) Termination Facility The Termination Facility allows an origin
or target system to initiate abrupt termination of the association, or an
origin system to initiate graceful termination.
IR-abort Service: IR-abort request by either the origin or the target.
IR-Release Service: IR-release request by the origin followed by an
IR-release response by the target.
The IR-abort and IR-release services map directly onto the A-ABORT and
A-RELEASE services (respectively) of the association control service
element.
3.2.1 Initialization Facility
3.2.1.1 Init Service
The Init service allows an origin to propose values for initialization
parameters. The target system may propose alternative values for some of
the parameters. If so, the origin must either accept the alternative
values proposed by the target or else terminate communication.
3.2.1.1.1 Id/authentication The origin and target agree, outside the scope
of the standard, whether or not this parameter is to be supplied by the
origin, and if so, what the value is. This value is used by the target to
determine if the origin is authorized to enter into communication with the
target.
3.2.1.1.2 Options The Init request specifies either "will use" or "will not
use", and the Init response specifies "will support" or "will not support"
for the following capabilities:
1. search
2. present
3. delete
If the target specified "will support" for a particular capability, then
the origin may assume that the service will be available and may use the
service during the association, even if the origin had specified "will not
use" for that service.
ORIGIN TARGET
PARAMETER REQUEST RESPONSE
Id/authentication x (optional)
Options x x
Preferred-message-size x x
Maximum-record-size x x
Result x
User-information-field x (optional) x (optional)
Reference-id x (optional) x (if applicable)
In addition, the Init request specifies either "will support" or "will
not support", and the Init response specifies "will use" or "will not use"
for each of the following capabilities,
1. resource-control
2. access-control
If the request specifies "will not support" for a given capability, and
the response specifies "will use" for that capability, then the value of
Result must be "reject".
Note: the above two lists of capabilities are subject to expansion in
future versions of this protocol.
search - The origin specifies "will use" for "search" if it intends to
submit Search requests. If so, the target indicates that it is willing (or
unwilling) to accept Search requests by specifying "will support" (or "will
not support") for "search".
present - The origin specifies "will use" for "present" if it intends
to submit Present requests. If so, the target indicates that it is willing
(or unwilling) to accept Present requests by specifying "will support" (or
"will not support") for "present".
delete - The origin specifies "will use" for "delete" if it intends to
submit Delete requests. If so, the target indicates that it is willing (or
unwilling) to accept Delete requests by specifying "will support" (or "will
not support") for "delete".
resource-control - The origin indicates that it is prepared to receive
and respond to a Resource-control request from the target, by specifying
"will support" for "resource-control". Conversely, the origin indicates
that it is not prepared to receive a Resource-control request by specifying
"will not support". In the latter case, if the target cannot suppress
sending a Resource-control request, it should reject the connection by
setting Result to "reject", specifying "will use" for "resource-control",
and (optionally) supplying a text message in the User-information-field.
access-control - Likewise, the origin indicates whether or not it is
prepared to receive and respond to an Access-control request from the
target, by specifying "will support" or "will not support" for
"access-control".
Security is invoked at different levels. In addition to user
authentication at the outset of an association, security might be invoked
to control access to a particular database, record, result-set, or use of a
command.
If the origin is not capable of receiving an Access-control request,
and if security requirements on the target system mandate that security
(other than that which might be provided by the parameter
ID/authentication) be invoked at the outset of an association, then the
target should reject the association by setting the parameter Result to
"reject", and specifying "will use" for "access-control". However, if the
target invokes security, but not at the association level, then the target
may choose to accept the connection. In that case, if the target
subsequently receives a command that would trigger an Access-control
request, the target agrees to suppress the request and respond to the
command with an error status indicating that a security challenge was
required but could not be issued.
3.2.1.1.3 Preferred-message-size and Maximum-record-size The Init
request contains Preferred- message-size and Maximum-record-size, specified
in bytes. Maximum-record-size must be greater than or equal to
preferred-message-size. The Init response contains both the
Preferred-message-size and Maximum-Record-size that the target is going to
use.
The target has the option of responding with values different from
those requested by the origin (however, Preferred-message-size must be less
than or equal to Maximum-record-size), in which case, the origin may abort
the connection if those values are not acceptable. The usage of these
parameters is specified in section 3.3
3.2.1.1.4 Result The target indicates whether or not it accepts the
association by specifying a value of "accept" or "reject" respectively in
the parameter Result. If "reject" is indicated, the origin is expected to
terminate communication.
3.2.1.1.5 User-information-field This field may be used by either the
origin or target for additional information, not specified by this
standard.
3.2.1.1.6 Reference-id See section 3.4
3.2.2 Search Facility
The Search facility enables an origin system to query databases at a
target system, and to receive information about the results of the query.
3.2.2.1 Search Service The Search service allows an origin to send a
query to a target. The basic query concept is: "from the specified set of
items, identify those with the properties indicated." The set of items
identified is called the "result set", and is maintained by the target for
subsequent retrieval requests. However, depending on the parameters of the
search, one or more items identified by the result set may be immediately
returned as part of the search response. The result set is an ordered set;
items identified by entries in the result set are referenced by the
position of the entry within the result set, beginning with one (1).
________________________________________________________________________
ORIGIN TARGET
PARAMETER REQUEST RESPONSE
Query-type x
Query x
Database-names x
Result-set-name x
Replace-indicator x
Small-set-element-set-names x (optional)
medium-set-element-set-names x (optional)
preferred-record-syntax x (optional)
Small-set-upper-bound x
Large-set-lower-bound x
Medium-set-present-number x
Database/diagnostic-records x (if applicable)
Result-count x
Number-of-records-returned x
Next-result-set-position x
Search-status x
Result-set-status x (if applicable)
Present-status x (if applicable)
Reference-id x (optional) x (if applicable)
________________________________________________________________________
3.2.2.1.1 Query-type and Query The parameter Query-type identifies the
syntax of the query. As noted above, the basic query concept is "from the
specified set of items, identify those with the properties indicated." The
"specified set of items" is a collection of one or more databases,
specified by the parameter database-names. The "properties indicated" are
specified by the parameter Query.
The remainder of this clause specifies procedures when Query-type is 1,
'RPN-query'.
The RPN query has the following structure:
RPN-query ::= argument | argument + argument + operator
argument ::= operand | RPN-query
operand ::= attribute-set + term | Result-set-id
operator ::= AND | OR | AND-NOT
Where ::= means "is defined as",
| means "or",
+ means "followed by", and + has precedence over |
(i.e., + is evaluated before |).
NOTES
1. "RPN-query" is recursively defined; it is either
a) "operand" , or
b) "argument + argument + operator".
In case (b), each occurrence of "argument" can be replaced by
either (a) or (b) and so on.
A structure composed of operators and operands conforms to the
Type-1 query syntax if and only if it is possible, by repeatedly replacing
occurrences of (b) with (a), to reduce the structure to (a).
2. "operand" is either (a) attributes-set + term, or (b)
Result-set-id. In either case it
represents a set of database records. For (a) it is the set of
database records obtained by evaluating the specified attribute-set and
term against the collection of databases specified in the Search request
(see NOTE 3). For (b) it is the set of database records represented by the
result set for which Result-set-id was specified as the value of the
parameter Result-set-name in a previous Search request.
3. Different attribute sets will be defined and registered (Appendix
C defines and registers attribute-set bib-1). An example of an
attribute-set/term combination is 'title word'/ 'evangeline'; in this case,
evaluation of attribute-set/term against a database would result in the
identification of all of the records in the database for which the access
point 'title word' contains the value 'evangeline'.
Representation and Evaluation of the Type-1 Query
At the origin system, the Type-1 query is represented by a tree.
Each leaf node contains a simple operand and each non-leaf node contains a
complex operand. A simple operand is either a Result-set- id or an
Attribute-set+Term. A complex operand is a subtree whose root is an
operator and which contains two subtrees: a left-hand operand and a
right-hand operand, LO and RO. A complex operand is thus one of the
following:
- LO AND RO, represnting the intersection of LO and RO;
- LO OR RO, rperesenting the union of LO and RO; or
- LO AND-NOT RO, representing the set of elements in LO that are not
in RO.
At the target, evaluation of the tree is illustrated by the use of a
stack. The tree is processed according to a left post-order
traversal. Each leaf-node is one of the following:
a) Attribute-set + Term
b) Result-set-id
c) Operator
Whenever (a) is encountered, it is evaluated against the collection of
databases specified in the Search request, and the result is put on the
stack. Whenever (b) is encountered, it is put on the stack.
Whenever (c) is encountered, the last two items (i.e. sets, see NOTE 2
above) that have been put on the stack are pulled off and the operator is
applied as follows:
- if operator is AND, the result is the intersection of the two sets,
- if operator is OR, the result is the union of the two sets,
- if operator is AND-NOT, the result is the set of elements in the
first set (i.e., the first of the two sets to have been placed on the
stack) which are not in the second set.
The resulting set is then put on the stack.
When evaluation of the query is complete (i.e. all query-terms have been
processed) there will be one item remaining on the stack (otherwise the
query is in error) which is the result of the query.
The following examples illustrate query evaluation. In these
examples, D represents the collection of databases specified in the Search
request, R represents a Result-set-id, and A, B, and C represent
attribute-list/term combinations such as "subject = dogs".
1. Query = A
Result: the records in D for which A is true
2. Query = A B C AND OR
Result: the records in D for which both B and C are true,
or A is true
3. Query = A B AND C OR
Result: the records in D for which both A and B are true, or C
is true
4. Query = R A AND
Result: the records in D for which both (1) A is true, and
(2) which are also in result set
R
5. Query = R A OR
Result: the records in D for which A is true, together
with records in R
3.2.2.1.1.a Database-name The target designates, by agreement outside the
scope of the standard, what databases may be specified on a Search request,
and also in what combinations they may be specified. For example, a target
might specify that databases A, B, and C, may be searched individually, and
that A and B may be searched in combination (but not A and C, nor B and C).
If an origin requests a combination of databases which is not supported,
the search will result in a diagnostic such as "combination of specified
databases not supported" (see appendix D).
3.2.2.1.2 Result-set-name and Replace-indicator The parameter
Result-set-name specifies a name to be given to the result set which will
be created by the query so that it may be subsequently referenced within
the same association. If a result set with the same name already exists at
the target, then the action taken depends on the value of the parameter
Replace-indicator, as follows:
- If the value of Replace-indicator is "on", then prior to processing
the query, the existing result set whose name is specified by the parameter
Result-set-name will be deleted, and a new result set by that name created.
The initial content of the result set is null.
- If the value of Replace-indicator is "off", the search is not
processed, an error diagnostic is returned by the target, and the existing
result set whose name is specified by the parameter Result-set-name is left
unchanged.
If a result set does not exist with the name specified by the parameter
Result-set-name, then a result set by that name is created by the target,
and the parameter Replace-indicator is ignored. The initial content of the
result set is null. If no records are found by the query, the result set
remains null.
A target system need not support, in general, the naming of result sets
by the origin (see however section 4.4.3, "Statement Requirements" for
Conformance). However, a target system must support at least the result
set whose name is "default". If the origin specifies "default" as
Result-set-name, then Replace-indicator must be "on".
A result set which is created by a Search request (that is, specified
by the parameter Result-set-name) may be referenced in a subsequent Present
request or as an operand in a subsequent Search request (for example, in a
Type-1 query). If a result set named "default" is created, it remains
available for reference from the time it is created until the end of the
association during which it is created, or until either:
- another "default" result set is created, because the name "default"
is specified as Result-set-name in a subsequent Search request, or
- it is unilaterally erased or deleted by the target.
Any result set other than the result set named "default" remains
available for reference from the time it is created until it is deleted in
one of the following ways:
- by a Delete request
- implicitly, because a result set was specified by the same name
in a Search request, and the
value of the parameter Replace-indicator was "on"
- unilaterally by the target (at any time)
- by termination of the association.
3.2.2.1.3 Small-set-element-set-names and Medium-set-element-set-names An
element set name is a primitive name which specifies a particular subset of
the elements in a database record which are to compose the response
records. The specified subset is made up of components of the
abstract-syntax description of the database records and is, therefore, a
formal subset of that abstract-syntax-definition. Element set names are
specified, along with their definitions, for a given database, by the
target, outside of this standard. The target specifies a default element
set for each database.
The parameters Small-set-element-set-names and
Medium-set-element-set-names describe the preferred record composition of
the records expected in the search response. If the query results in a
small-set (see 3.2.2.1.4), then Small-set-record-element-set-names
pertains. If the query results in a medium-set, then
Medium-set-record-element-set-names pertains.
Each of the two parameters is a set of one or more pairs of a database
name and associated element set name. For each database record returned in
a Search (or Present) response, if the given database is specified (as a
component of one of the pairs comprising the pertaining element set name)
then the response record should be composed according to the corresponding
element set name. If not, the response record should be composed according
to the default element set name for that database. If a record composition
name is specified which is not valid for the corresponding database, then
the Search Response APDU will include a diagnostic, such as "record
composition name not valid for database", and the value of the parameter
Search-Status will be "failure".
Each of the two parameters may alternatively consist of a single
element set name (from those defined by the target system), with no
database specified. In that case, for each database record returned in a
Search (or Present) response:
- if the specified element set name is valid for the given
database, the response-record should be composed according to
that element set name;
- if the specified element set name is not valid for the given
database, the response-record should be composed according to
the default element set name for that database.
A target system must always recognize the character string "F" as an
element set name to mean "full record". When a "full record" is requested,
the target returns all of the elements stored in its database for the
requested record. For a given record, the set of elements included in a
"full record" in one database might not be the same set of elements
included in a "full record" in another database. (The target may use "F"
as the default element set name.)
3.2.2.1.3a Preferred-record-syntax The parameter Preferred-record-syntax
identifies the preferred abstract syntax for the records to be returned,
from among the set of abstract syntaxes for records for which presentation
contexts are currently established for this application association. If
the target cannot supply the information in the requested abstract syntax,
it will supply it in one of the other abstract syntaxes from the
established set.
3.2.2.1.4 Small-set-upper-bound, Large-set-lower-bound, and
Medium-set-present-number The number of database records identified by the
result set is referred to as the result-count. The result set is
considered either a "small-set", a "medium-set", or a "large-set",
depending on the result-count and the parameters of the search. The result
set is a small-set if Result-count is not greater than
small-set-upper-bound. The result set is a large-set if Result-count is
larger than or equal to Large-set-lower-bound. Otherwise, the result set is
a medium-set.
If the query results in a small-set, all database records identified by
the result set are to be returned to the origin (subject to possible
message size constraints). If the query results in a large-set, no database
records are to be returned. If the query results in a medium-set, the
maximum number of database records to be returned is specified by
Medium-set-present-number.
Notes: (1) The result set may be a medium-set only when
Result-count is greater than small-set-upper-bound and less than
Large-set-lower-bound, and this can only occur if Large- set-lower-bound is
at least 2 greater than Small-set-lower-bound; i.e., the result set cannot
be a medium-set if Large-set-lower-bound exceeds Small-set-upper bound by
one. For example, if Large-set-lower-bound is 11 and Small-set-upper-bound
is 10, the intent is "if 10 or less records are found return them all,
otherwise do not return any"; and medium-set-present-number would not apply.
(2) Small-set-upper-bound may be zero.
Large-set-upper-bound must be greater than Small-set-upper-bound.
(3) If the origin does not want any records returned in the
response regardless of the value of Result-cound, Larger-set-lower-bound
should be set to 1 and Small-set-upper-bound to zero.
3.2.2.1.5 Database/diagnostic-records The target processes the search,
creating a result set which identifies a set of database records. It
cannot be assumed however that search processing requires physical access
to the database records; thus one or more records might not be returnable,
but this circumstance might not be recognized until an attempt is made to
transfer such a record.
After processing the search, the target attempts to retrieve the first
N records identified by the result set, to be included in the Search
response (N depends on the search parameters and result-count, as described
in 3.2.2.1.4). For each record which cannot be returned, a surrogate
diagnostic record is substituted. Thus the parameter
Database/diagnostic-records is one of the following:
- N database and/or diagnostic records,
- a number of database and/or diagnostic records, which is less than
N because of message size constraints (see 3.3),
- a single non-surrogate diagnostic record indicating that the search
cannot be processed, and why it cannot be processed, or
- a single non-surrogate diagnostic record indicating that records
cannot be presented, and why not ", e.g. record composition name
not valid for database".
The order of occurrence of records (database and/or surrogate
diagnostic) within the parameter Database/diagnostic-records is according
to the order in which they are identified by the result set. Each database
or surrogate diagnostic record may optionally be accompanied by the name of
the database in which the record resides. However, the database name must
accompany the first database or surrogate diagnostic record being returned,
and must accompany any record coming from a database different than its
immediate predecessor.
3.2.2.1.6 Result-count and Number-of-records-returned The parameter
Result-count is the number of records identified by the result set. If the
result set is empty, result-count is zero. The parameter
Number-of-records-returned is the total number of records (database and
diagnostic) returned in the Search response.
3.2.2.1.7 Next-result-set-position The parameter Next-result-set-position
specifies the position within the result set of the next record following
those returned (or zero if the last record in the result set is being
returned).
3.2.2.1.8 Search-status The parameter Search-status is returned in the
response and assumes one of the following two values:
success - the search completed successfully
failure - the search did not complete successfully
A value of "success" does not imply that the expected database and/or
surrogate diagnostic records are being returned as part of the response
(see Present-status, 3.2.2.1.9). Note also, a value of "success" does not
imply that any records were located by the search. A value of "failure"
does imply that none of the expected database and/or surrogate diagnostic
records is being returned. In the latter case, the target returns a single
diagnostic record indicating that the search cannot be processed.
3.2.2.1.9 Result-set-status and Present-status These are status
descriptors necessary to dissambiguate certain situations that can occur
during search and present operations.
Result-set-status occurs if and only if the value of Search-status is
"failure", and its value is one of the following:
subset - Partial, valid results available.
interim - Partial results available, not necessary valid.
none - No results available (result set is null).
Present-status occurs if and only if the value of Search-status is
"success", and its value is one of the following:
success - All of the expected database (or surrogate diagnostic)
records are available.
partial-1 - Not all of the expected records can be returned because
the request was terminated by access-control.
partial-2 - Not all of the expected records can be returned because
the request was terminated by maximum message size.
partial-3 - Not all of the expected records can be returned because
the request was terminated by resource-control at origin.
partial-4 - Not all of the expected records can be returned because
the request was terminated by resource-control at target.
failure - None of the expected database (or surrogate diagnostic)
records can be returned. A single diagnostic is
returned, which is not a surrogate for a database record.
3.2.2.1.10 Reference-id See section 3.4
3.2.3 Retrieval Facility
The Retrieval facility enables the origin to retrieve a copy of records
according to position within a result set maintained by the target.
3.2.3.1 Present Service The Present service allows the origin system to
retrieve records from a specified result set. Records are referenced by
relative position within the result set. The origin specifies a range of
records to be retrieved and may follow with subsequent requests specifying
different ranges. For example, the origin may retrieve records one through
five and follow with a request for records four through six.
________________________________________________________________________
ORIGIN TARGET
PARAMETER REQUEST RESPONSE
Number-of-records-requested x
Result-set-start-position x
Result-set-id x
Element-set-names x (optional)
Preferred-record-syntax x (optional)
Database/diagnostic-records x (if applicable)
Number-of-records-returned x
Next-result-set-position x
Present-status x
Reference-id x (optional) x (if applicable)
________________________________________________________________________
3.2.3.1.1 Number-of-records-requested and Result-set-start-position The
origin requests the return of N records beginning at record M, from the
result set, where N = Number-of-records-requested and M = Result-set-start-
position (and N is not greater than Result-count - M + 1).
3.2.3.1.2 Result-set-id Result-set-id specifies the result set from which
records are to be retrieved. It is the result set created by a previous
Search request for which the value of the parameter Result- set-name
matches the value of Result-set-id.
3.2.3.1.3 Element-set-names The parameter Element-set-names describes the
preferred record composition of the records expected in the Present
response. See section 3.2.2.1.3.
3.2.3.1.4 Preferred-record-syntax See section 3.2.2.1.3.
3.2.3.1.5 Database/diagnostic-records The parameter
Database/diagnostic-records returned by the target consists of one of the
following:
- N database and/or diagnostic records, where N = Number-of-records-requested,
- a number of database and/or diagnostic records, which is less than N
(reason specified by Present-status), or
- a single diagnostic record indicating that the request cannot be
processed, and why it cannot be processed.
The order of occurrence of records (database and/or surrogate
diagnostic) within the parameter Database/diagnostic-records is according
to the order in which they are identified by the result set. Each database
and/or surrogate diagnostic record may optionally be accompanied by the
name of the database in which the record resides. However, the database
name must accompany the first record being returned, and must accompany any
record coming from a database different than its immediate predecessor.
3.2.3.1.6 Number-of-records-returned and Next-result-set-position The
parameter Number-of-records-returned is the total number of database and
diagnostic records returned. Next-result-set-position is the position
within the result set of the next record following the last database or
surrogate diagnostic record being returned (or zero, if the last database
or surrogate diagnostic record in the result set is being returned).
3.2.3.1.7 Present-status Present-status is mandatory in a Present response
and its values are the same as those listed for Present-status in
3.2.2.1.9.
3.2.3.1.8 Reference-id See section 3.4
3.2.4 Result-set-delete Facility
The Result-set-delete facility enables an origin system to instruct a
target system to delete one or more result sets known to the target system.
The target system responds with information pertaining to the result of the
operation.
3.2.4.1 Delete Service Element
The Delete service element enables an origin system to send a Delete
request to the target. The origin system may request deletion of specified
result sets held by the target system, or all result sets currently on the
target system created during this association. The target responds by
reporting the status of the requested delete operation.
________________________________________________________________________
ORIGIN TARGET
PARAMETER REQUEST RESPONSE
Delete-operation x
Result-set-list x (if applicable)
Delete-status x
List-statuses x (if applicable)
Number-not-deleted x (if applicable)
Bulk-statuses x (if applicable)
Delete-msg x (optional)
Reference-id x (optional) x (if applicable)
________________________________________________________________________
3.2.4.1.1 Delete-operation The origin specifies one of the following:
list - delete one or more specified result sets (see 3.2.4.1.2), or
Bulk-delete - delete all result sets currently on the target system
created during this association.
3.2.4.1.2 Result-set-list If Delete-operation is "list", then the parameter
Result-set-list must be present, and specifies a list of result sets to be
deleted, each of which was created by a previous Search request for which
the value of the parameter Result-set-name matches the value of one of the
members of the list. If Delete-operation is "Bulk-delete", then the
parameter Result-set-list must not be present.
3.2.4.1.3 Delete-status Delete-status is used by the target to report the
status of the delete request. It assumes one of the values "success" or
"failure-3" through "failure-9" in table 3.2.4-1.
3.2.4.1.4 List-statuses
List-statuses is present in a Delete response for a list operation. It
contains the same Result-set-id(s) contained in the Result-set-list
parameter of the corresponding Delete request. Each result-set-id in the
List-statuses parameter is paired with a status. Possible status values
are "success" and "failure-1" through "failure-6" in table 3.2.4-1.
_______________Table 3.2.4-1___________________________________
success - Result set(s) deleted.
failure-1 - Result set did not exist.
failure-2 - Result set previously unilaterally deleted by target.
failure-3 - System problem at target (optional text message may be
included in the Delete-msg parameter).
failure-4 - Access-control failure: the delete request caused the
target system to issue an Access-control request which the
origin system failed to satisfy, or the origin could not
accept an Access-control request.
failure-5 - Request terminated by origin system through resource control.
failure-6 - Access terminated by target system due to resource constraints.
failure-7 - Bulk delete of result sets not supported by target.
failure-8 - Not all result sets deleted (on a bulk delete request)
(see 3.2.4.1.4).
failure-9 - Not all requested result sets deleted.
Note: failure-7 and failure-8 can occur only if Delete-operation
is Bulk-delete.
________________________________________________________________
3.2.4.1.4 Number-not-deleted and Bulk-statuses These two parameters occur
only if Delete-operation is Bulk-delete and if Delete-status = "failure-8".
The parameter Number-not-deleted indicates how many result sets were not
deleted, and the parameter Bulk-statuses gives individual statuses for
those not deleted.
Note, however, that a target system is not obligated to provide
statuses for each result set not deleted on a bulk delete. For example, a
target system may abort a bulk delete when the first failure to delete a
result set that is part of the bulk delete fails; in this case only a
single status might be included in the parameter Bulk-statuses.
If a bulk delete results in more statuses than can fit into a single
Delete-response message, the target system may discard those which do not
fit.
3.2.4.1.5 Delete-msg Delete-msg, if present, contains an optional text message.
3.2.4.1.6 Reference-id See section 3.4
3.2.5 Access Control Facility
The Access-control facility allows a target system to challenge an
origin system during execution of an Init, Search, Present, or Delete
operation.
An origin system must be prepared to accept and respond to one or more
Access-control requests while an Init, Search, Present, or Delete request
is being executed by the target system (unless the parameter Options of the
Init request which initiated the connection did not include Access-control;
see 3.2.1.1.2). For example, after sending a Search request, the origin
must be prepared to receive an Access-control request, respond with an
Access-control response, then later receive another Access- control
request, etc., before receiving a Search response.
Once the origin has responded, the operation proceeds as if the
challenge has never taken place. If the origin system fails to respond
correctly to the challenge during a Search, Present, or Delete request,
then the Search, Present, or Delete response may indicate that the
operation was terminated due to an Access-control failure. (Note: During a
Search or Present operation, while the target is preparing records for
presentation, it might send an Access Control request pertaining to a
particular record. If the origin fails to respond correctly to the
challenge, the target may simply substitute a surrogate diagnostic:
"security challenge failed; record not included".) If the origin system
fails to respond correctly to the challenge during an Init request, the
target may set the Result parameter to "reject" and may (optionally) supply
such an indication in the User-information-field of the Init response.
The Access-control request/response mechanism can be used to support
password challenges, public key cryptosystems, or algorithmic
authentication, etc. The specific content of the Access-control request
and response parameters are outside the scope of this standard.
3.2.5.1 Access-control Service
________________________________________________________________________
TARGET ORIGIN
PARAMETER REQUEST RESPONSE
Security-challenge x
Security-challenge-response x
Reference-id x (if applicable) x (if applicable)
________________________________________________________________________
3.2.5.1.1 Security-challenge and Security-challenge-response The contents
of these two parameters are outside the scope of this standard and must be
established by prior agreement between a given target/origin system pair.
3.2.5.1.2 Reference-id See section 3.4.
3.2.6 Accounting/Resource Control Facility
The Accounting/resource Control facility permits the target system to
notify the origin system when either actual or predicted resource
consumption will exceed agreed upon limits (or limits built into the target
system), and to obtain the origin system's consent to continue. In
addition, the target system can inform the origin system about the current
status of a result set being generated on the target in response to a
Search request, and indicate information about the status of the current
request to the origin.
3.2.6.1 Resource-control Service
A target system may issue a Resource-control request in response to an
Init, Search, Delete, or Present request. The origin system must respond
to the Resource-control request, after which processing continues (from the
point of view of message sequencing) as if the request/response sequence
never occured. An origin should be prepared to respond to multiple
Resource-control requests during the execution of an Init, Search, Delete
or Present request.
If the origin responds to a Resource-control request with a
Resource-control response saying to terminate the command, it can expect to
receive an Init, Search, Present or Delete response. This response might
indicate that the request was terminated at origin request. However, the
response might alternately indicate that the request completed, since the
operation at the target system may continue to execute and subsequently
complete before the Resource-control response reaches the target system.
________________________________________________________________________
TARGET ORIGIN
PARAMETER REQUEST RESPONSE
Resource-report x (optional)
Suspended-flag x
Partial-results-available x (if applicable)
Continue-flag x
Result-set-wanted x (if applicable)
reference-id x (if applicable) x (if applicable)
________________________________________________________________________
3.2.6.1.1 Resource-report Resource-report may be used to convey information
about the current and estimated resource consumption at the target system.
The format of Resource-report bib-1 is defined in Appendix F.
3.2.6.1.2 Partial-results-available The target indicates the status of the
result set via the flag Partial- results-available, whose value is one of
the following:
subset - Partial, valid results available.
interim - Partial results available, not necessary valid.
none - No results available.
This parameter is meaningful only during a search operation. If its
value is "subset" or "interim", then the target will accept subsequent
Present requests if the current request is terminated by the
Resource-control response, and if the value of the parameter
Result-set-wanted is "on".
If the value of Partial-results-available is "none" then the target
need not accept subsequent Present requests in the event that the request
is terminated by the Resource-control response.
Note that if Suspended-flag is off, the partial results available
situation may change since processing continues on the search. In all
cases, the values of Search-status and Result-set-status in the Search
response should be treated as the authoritative information.
3.2.6.1.3 Suspended-flag The target system indicates whether or not
processing of the command has been suspended pending the Resource-control
response.
3.2.6.1.4 Continue-flag The origin indicates to the target whether or not
to continue processing.
3.2.6.1.5 Result-set-wanted This flag is meaningful only:
- during a Search request,
- when the value of Partial-results-available is "subset" or
"interim", and
- when the value of the parameter Continue-flag is "do not
continue".
If the value of the flag is "on", the target will maintain the
(possibly partial) result set for subsequent Present requests. If the
value of the flag is "off", the target may delete the result set. A result
set status of "none" on the subsequent Search response indicates that the
target has discarded the result set. In all cases, the values of
Search-status and Result-set-status in the Search response describe the
actual decisions made by the target system and the way in which the search
terminated.
3.2.6.1.6 Reference-id See section 3.4.
3.2.7 Termination Facility
The Termination Facility allows either:
(1) an origin or target to initiate abrupt termination of the
association via the IR-abort service element, or
(2) an origin system to initiate graceful termination via the
IR-release service.
Both the IR-abort and IR-release services map directly onto the A-ABORT
and A-RELEASE services of the association control service element.
3.2.7.1 IR-abort Service
Either the origin or target may at any time either send or receive an
IR-abort request, and consider the application association terminated.
3.2.7.2 IR-Release Service
The origin may invoke an IR-release request following receipt of an
Init, Search, Present, or Delete response. It should then await receipt of
an IR-Release response, and then consider the association terminated.
Alternately, it might receive an IR-abort request from the target, in which
case it should consider the application association terminated.
The target may receive an IR-release request after sending an Init,
Search, Present, or Delete response, or a Resource-control or
Access-control request. It should then send an IR-release response, and
consider the association terminated.
3.3 MESSAGE SIZE LIMITATIONS
For both the Search and Present services, it is possible that the
target will not be able to return the number of database records requested
because of message size limitations. In that case, the target is
responsible for packing as many records as possible into the response
message. (Note: A response message always contains an integral number of
records; a record never spans response messages.)
Illustration
Assume that the target is attempting to transmit records in result set
positions 1 through 10 (in this section, the term "record" means "database
or surrogate diagnostic record", unless "diagnostic record" or "database
record" is specified). Assume further that:
o records in position 1 through 6 fit in the response message, such
that the sum of the sizes of the records (not including any protocol
control information) does not exceed Preferred-message-size; but,
o the database record in position 7 will not fit in the message along
with records in position 1 through 6 without the resulting sum of the
message sizes exceeding Preferred-message-size.
The size of the database record in position 7:
(a) does not exceed Preferred-message-size, or
(b) exceeds Preferred-message-size, but does not exceed
Maximum-record-size, or
(c) exceeds Maximum-record-size.
In case (a), the target returns records in position 1 through 6.
In case (b), except as noted below (see "Exception"), the target
substitutes a diagnostic record for the database record in position 7,
indicating that the record exceeds Preferred-message-size. In case (c) the
target substitutes a diagnostic record for the database record in position
7, indicating that the record exceeds Maximum-record-size. (If
Maximum-record-size equals Preferred-message-size then there is no
distinction between the meaning of the two diagnostics.)
In case (b) or (c) if the diagnostic record will not fit along with the
records in position 1 through 6, the target returns the records in position
1 through 6. (Preferred-message-size must always be large enough to
contain any diagnostic record; thus a subsequent present request beginning
with the record in position 7 will retrieve the diagnostic.) Otherwise,
the target inserts the diagnostic record and proceeds to attempt to fit
records in positions 8 through 10 into the response message.
Exception
If a Present request specifies a single record (i.e.
Number-of-records-requested equals 1) then if the size of that record
exceeds Preferred-message-size, but does not exceed Maximum-record-size,
the target will return that single database record in the Present response.
Note that this exception applies only to a Present request and not to a
Search request.
Thus in case (b), the origin may subsequently request the database
record in position 7, by issuing a Present request in which that record is
the only record requested.
Note that the purpose of this distinction between
Preferred-message-size and Maximum-record-size is to allow the transfer of
normal length records to proceed in a routine fashion, with convenient
buffer sizes, but to also provide for the transfer of an occasional
exceptionally large database record without requiring the origin to
continually allocate and hold local buffer space for worst-case records.
Note also that this intended purpose is defeated if the origin routinely
requests a single record.
3.4 RERERENCE-ID
The parameter Reference-id, is optional in an Init, Search, Present, and
Delete request. If supplied,
- it must be echoed by the target in the respective response,
- it must be echoed in both the request and response of any
intermediate Access-control or Resource-control request/response
sequences.
If Reference-id is not supplied in an Init, Search, Present, or Delete
request, then it is not to appear in the respective response, nor in either
the request or response of any intermediate Access-control or
Resource-control request/response sequence.
The service does not assume any relationship between the Reference-id
used in an Init, Search, Present, or Delete request and the Reference-id
used in any other Init, Search, Present, or Delete request.
The purpose of this parameter is to facilitate the grouping of events
by the origin system. This standard does not specify its contents.
Reference-ids are always assigned by the origin and have meaning only
within the origin system. Since there are no semantics attributed to this
parameter, it has no implied datatype and can only be described as
transparent binary data. It is therefore described as ASN.1 type
OCTETSTRING).
4. PROTOCOL SPECIFICATION
This version of the ANSI Z39.50-1991 Information Retrieval protocol is
version 2. (Note: Version 2 is identical to version 1, and implementations
which support version 2 automatically support version 1. Version 1 of ANSI
Z39.50-1991 should not be confused with ANSI Z39.50-1988).
The Information Retrieval application protocol specifies the formats
and procedures governing the transfer of information between peer
information retrieval applications. A unit of information, passed between
two peer applications is called an "application protocol data unit" or
APDU.
4.1 ABSTRACT SYNTAX OF THE INFORMATION RETRIEVAL PROTOCOL
The Information Retrieval protocol data units are complex data types.
The transfer syntax of these data types is negotiated by the presentation
service provider. The definitions in this section specify the component
data elements of the protocol data units and the Type-0 , Type-1 Type-2,
and Type-100 queries.
4.1.1 ASN.1 Specification of the APDUs
This section describes the abstract syntax of the Z39.50 APDUs,
using the ASN.1 notation defined in ISO 8824 and in its addendum 1. The
comments included within the ASN.1 specification constitute part of the
standard.
BEGIN -- ANSI Z39.50 version 2 - May 16, 1991
ANSIZ39-50-2 DEFINITIONS ::=
BEGIN
PDU ::= CHOICE{
initRequest [20] IMPLICIT InitializeRequest,
initResponse [21] IMPLICIT InitializeResponse,
searchRequest [22] IMPLICIT SearchRequest,
searchResponse [23] IMPLICIT SearchResponse,
presentRequest [24] IMPLICIT PresentRequest,
presentResponse [25] IMPLICIT PresentResponse,
deleteResultSetRequest [26] IMPLICIT DeleteResultSetRequest,
deleteResultSetResponse [27] IMPLICIT DeleteResultSetResponse,
accessControlRequest [28] IMPLICIT AccessControlRequest,
accessControlResponse [29] IMPLICIT AccessControlResponse,
resourceControlRequest [30] IMPLICIT ResourceControlRequest,
resourceControlResponse [31] IMPLICIT ResourceControlResponse}
-- new APDUs can be added in the future at the end of this list.
-- Initialization APDUs
InitializeRequest ::=SEQUENCE{
referenceId ReferenceId OPTIONAL,
protocolVersion ProtocolVersion,
-- proposed version of the protocol to be used (see below).
options Options,
-- proposed set of services to be used
preferredMessageSize PreferredMessageSize,
-- origin proposal for the size of large messages
(where message size
is the sum of sizes, in bytes, of the records in an APDU)
the target should normally use when presenting groups of records;
however, the first record in a response is permitted to cause the
message to exceed this size (see also maximumRecordSize below).
maximumRecordSize MaximumRecordSize,
origin proposal for maximum record size (number of bytes).
Value must be greater than or equal to preferredMessageSize.
idAuthentication [7] ANY OPTIONAL,
information as required by the target to access the responding
IRPM; syntax of this parameter to be defined by the target prior
to communication.
implementationId ImplementationId OPTIONAL,
implementationName ImplementationName OPTIONAL,
implementationVersion ImplementationVersion OPTIONAL,
userInformationField UserInformationField OPTIONAL}
InitializeResponse ::= SEQUENCE
{referenceId ReferenceId OPTIONAL,
protocolVersion ProtocolVersion,
options Options,
preferredMessageSize PreferredMessageSize,
target decision on maximum APDU size (see description under
InitializationRequest definition). Value is allowed to be different
from what origin proposed in the InitializationRequest; if origin
does not agree on target values, it may abort the connection.
maximumRecordSize MaximumRecordSize,
target decision on the maximum record size
result [12] IMPLICIT BOOLEAN,
result of the processing of the request at the target.
reject = FALSE. Accept = TRUE;
implementationId ImplementationId OPTIONAL,
implementationName ImplementationName OPTIONAL,
implementationVersion ImplementationVersion OPTIONAL,
userInformationField UserInformationField OPTIONAL}
-- Auxiliary definitions for Initialization APDUs
ProtocolVersion ::= [3] IMPLICIT BIT STRING
represents a string of Boolean values, each value representing a
version. The first value set to 1 indicates version 1 is available,
the second value set to 1 indicates version 2 is available,
and so on. Values higher than the highest known version should
be ignored. Both the Initialize and Initialize Response APDUs
include a value string corresponding to the supported versions.
The highest common version is selected for use. If there are no
versions in common, the Initialize Response APDU should
indicate a value of "reject" for the parameter Result.
2 should indicate support for version 1 as well, for interoperability
with systems that indicate support for version 1 only.
Options ::= [4] IMPLICIT BIT STRING {search (0), present (1),
delSet (2), resourceCtrl (3), accessCtrl (4)}
In InitializeRequest, for search, present and delete, bit ON
indicates initiator does request use of service; for resource
contrl and access control, bit ON indicated indicates initiator
will support service. For InitializeResponse, for search, present
and delete, bit ON indicates target will support service; for
resource control and access control, bit ON indicated target
requests service. For extensibility of the protocol, additional
bits set should not be considered to be an error on received
InitializeRequest.
PreferredMessageSize ::= [5] IMPLICIT INTEGER
MaximumRecordSize ::= [6] IMPLICIT INTEGER
ImplementationId ::= [110] IMPLICIT VisibleString
ImplementationName ::= [111] IMPLICIT VisibleString
ImplementationVersion ::= [112] IMPLICIT VisibleString
these three implementation parameters are provided solely for the
convenience of implementors needing to distinguish implemen-
tations. They shall not be the subject of conformance tests.
UserInformationField ::= [11] EXTERNAL
additional information, not defined in this standard.
-- end auxiliary definitions for initialization APDUs
-- Search APDUs
SearchRequest ::= SEQUENCE{
referenceId ReferenceId OPTIONAL,
smallSetUpperBound [13] IMPLICIT INTEGER,
if the number of hits is less than or equal to this number, all
records are to be returned in the SearchResponse (within the
limits given by the negotiated preferredMessage- and
maximumRecordSize), composed in the way specified by the
smallSetElementSetNames parameter below. May be zero.
largeSetLowerBound [14] IMPLICIT INTEGER,
if the number of hits is equal to or greater than this number, no
records are to be returned. LargeSetLowerBound must be greater
than smallSetUpperBound.
mediumSetPresentNumber [15] IMPLICIT INTEGER,
maximum no. of records to be returned in the SearchResponse
if the number of hits is between largeSetLowerBound and
smallSetUpperBound (again within the limits given
by the message and record size parameters), composed as
specified by mediumSetRecordElementSetNames
replaceIndicator [16] IMPLICIT BOOLEAN,
origin indicates whether or not to replace a previously created
result set with the same name by the one that is constructed in
this search.
resultSetName [17] IMPLICIT VisibleString,
origin proposal for naming of the result set that is constructed
if hits are found. If target allows the origin to assign names to
result sets, it uses this proposed name. If the target does
not support named result sets it returns an error diagnostic.
databaseNames [18] IMPLICIT SEQUENCE OF DatabaseName,
database(s) in which the search will be performed.
smallSetElementSetNames [100] IMPLICIT ElementSetNames OPTIONAL,
origin proposal for composition of the records in the small set
(see above under smallSetUpperBound).
mediumSetElementSetNames [101] IMPLICIT ElementSetNames OPTIONAL,
origin proposal for the composition of the records in the medium
set (see above under mediumSetPresentNumber).
preferredRecordSyntax PreferredRecordSyntax OPTIONAL,
origin proposal for abstract syntax of the database records to
be returned in the SearchResponse. Values subject to registration.
query [21] Query}
the search argument (see description below).
-- query definition
Query ::= CHOICE
{type-0 [0] ANY,
type-1 [1] IMPLICIT RPNQuery,
type-2 [2] OCTET STRING,
type-100 [100] OCTET STRING}
the search argument contained in the SearchRequest. Four types
are defined:
-- a) A type-0 query may be used only when the origin and target
-- have an a priori agreement outside of this standard as to
-- form of quert acceptable to the target.
-- b) type-1 is the Reverse Polish Notation (RPN) query (see below).
-- c) type-2 is the ISO8777 type query, specified in ISO 8777.
-- d) type-100 is the Z39.58 type query.
RPNQuery ::= SEQUENCE{
attributeSetId OBJECT IDENTIFIER, -- identifies attribute set
RPNStructure}
RPNStructure ::= CHOICE {
[0] Operand,
[1] IMPLICIT SEQUENCE {
RPNStructure,
RPNStructure,
Operator } }
Operand ::= CHOICE{
AttributesPlusTerm,
ResultSetId}
AttributesPlusTerm ::= [102] IMPLICIT SEQUENCE{
AttributeList,
Term}
AttributeList ::= [44] IMPLICIT SEQUENCE OF
AttributeElement
Term ::= [45] IMPLICIT OCTET STRING
-- the type OCTET STRING is used to enable the inclusion of
-- multibyte character representations which the types CharacterString
-- and VisibleString might impose on graphic character repertoire.
Operator ::= [46] CHOICE{
and [0] IMPLICIT NULL,
or [1] IMPLICIT NULL,
and-not [2] IMPLICIT NULL}
AttributeElement ::= SEQUENCE{
AttributeType,
AttributeValue}
AttributeType ::= [120] IMPLICIT INTEGER
AttributeValue ::= [121] IMPLICIT INTEGER
-- AttributeType and AttributeValue interpretation is governed by the
-- values contained in the definition identified by AttributeSetId
SearchResponse ::= SEQUENCE{
referenceId ReferenceId OPTIONAL,
resultCount [23] IMPLICIT INTEGER,
-- number of hits resulting from the search.
numberOfRecordsReturned NumberOfRecordsReturned,
-- number of records in the searchResults below.
nextResultSetPosition NextResultSetPosition,
-- the ordinal number in the result set of the record appearing
-- directly after the last record in the searchResults below.
searchStatus [22] IMPLICIT BOOLEAN,
-- result of the processing of the request at the target IRPM.
-- success = TRUE; failure = FALSE.
resultSetStatus [26] IMPLICIT INTEGER
{subset(1), interim(2), none(3)} OPTIONAL,
-- occurs if and only if search-status is FALSE indicates the presence
-- and validity of the result set produced.
presentStatus PresentStatus OPTIONAL,
-- occurs if and only if search-status is TRUE. Indicates presence and
-- validity of records appearing in searchResults (see below).
databaseOrDiagnosticRecords Records OPTIONAL}
-- the records (diagnostic and/or bibliographic) resulting from the
-- search (see description below).
-- Present APDUs
PresentRequest ::= SEQUENCE{
referenceId ReferenceId OPTIONAL,
resultSetId ResultSetId,
-- identification of the result set from which to retrieve records
resultSetStartPoint [30] IMPLICIT INTEGER,
-- ordinal number in the result set of the first record to appear in
-- the presentResults in the PresentResponse.
numberOfRecordsRequested [29] IMPLICIT INTEGER,
-- specifies the maximum number of records to be returned in the
-- presentResults in the PresentResponse (within the limits given by
-- the negotiated message and record size parameters), composed as
-- specified by the element set names parameter below.
ElementSetNames OPTIONAL,
-- origin proposal for the composition of the records to be returned
-- in the presentResults parameter in the PresentResponse
preferredRecordSyntax PreferredRecordSyntax OPTIONAL}
-- origin proposal for abstract syntax of the database records to
-- be returned in the presentResults in the PresentResponse. Values
-- subject to registration, at present by specification in Appendix E.
PresentResponse ::= SEQUENCE{
referenceId ReferenceId OPTIONAL,
numberOfRecordsReturned NumberOfRecordsReturned,
-- number of records returned in the presentResults below.
nextResultSetPosition NextResultSetPosition,
-- the ordinal number in the result set of the record appearing
-- directly after the last record in the presentResults below.
presentStatus PresentStatus,
-- indicates the presence and validity of the records
databaseOrDiagnosticRecords Records OPTIONAL} -- the presented records
-- begin auxiliary definitions for search and present APDUs
-- begin definition of record structure
Records ::= CHOICE{
dataBaseOrSurDiagnostics [28] IMPLICIT SEQUENCE OF
NamePlusRecord,
nonSurrogateDiagnostic [130] IMPLICIT DiagRec}
NamePlusRecord ::= SEQUENCE{
[0] IMPLICIT DatabaseName OPTIONAL,
presence of DatabaseName is conditional. See
3.2.2.1.5 and 3.2.3.1.5.
[1] CHOICE{
databaseRecord [1] DatabaseRecord,
surrogateDiagnostic [2] DiagRec}}
DatabaseRecord ::= EXTERNAL
-- the database record syntax is defined outside of this standard.
-- For bibliographic data, USMARC is a prime example.
DiagRec ::= SEQUENCE{
diagnosticSetId OBJECT IDENTIFIER,
condition INTEGER,
-- interpretation of condition is governed by values contained in
-- definition identified by DiagnosticSetId.
addinfo VisibleString} -- add'l info.
-- end definition of record structure
-- begin definition of element set names
ElementSetNames ::= [19] CHOICE{
generic [0] IMPLICIT ElementSetName,
databaseSpecific [1] IMPLICIT SEQUENCE OF SEQUENCE{
DatabaseName,
ElementSetName}}
ElementSetName ::= [103] IMPLICIT VisibleString
-- A target must always recognize the value "F" to mean "full record".
-- end definition of element set name.
-- begin miscellaneous definitions for search and present APDUs
NumberOfRecordsReturned ::= [24] IMPLICIT INTEGER
NextResultSetPosition ::= [25] IMPLICIT INTEGER
PresentStatus ::= [27] IMPLICIT INTEGER{
success (0),
partial-1 (1),
partial-2 (2),
partial-3 (3),
partial-4 (4),
failure (5)}
PreferredRecordSyntax ::= [104] IMPLICIT OBJECT IDENTIFIER
-- end miscellaneous definitions for search and present APDUs
-- end auxiliary definitions for search and present APDUs
-- Delete Result Set APDUs
DeleteResultSetRequest ::=SEQUENCE{
referenceId ReferenceId OPTIONAL,
deleteOperation [32] IMPLICIT INTEGER{
list (0),
all (1)},
resultSetList SEQUENCE OF ResultSetId OPTIONAL }
-- identification of result sets to be deleted if operation is "list"
DeleteResultSetResponse ::= SEQUENCE{
referenceId ReferenceId OPTIONAL,
deleteOperationStatus [0] IMPLICIT DeleteSetStatus,
-- Reports status for entire delete operation. Values limited to
-- "success" or "failure-3" through "failure-9". Values of "failure-7"
-- and "failure-8" may be used only if operation is "all".
listStatuses [1] IMPLICIT ListStatuses OPTIONAL,
-- Must occur if operation is "list". Individual status values
-- limited to "success" through "failure-6".
numberNotDeleted [34] IMPLICIT INTEGER OPTIONAL,
-- number of result sets the target failed to delete. Occurs only
-- if operation is "all".
bulkStatuses [35] IMPLICIT ListStatuses OPTIONAL,
-- occurs if and only if DeleteSetStatus equals 8. Individual
-- statuses limited to "success" through "failure-6"
deleteMessage [36] IMPLICIT VisibleString OPTIONAL}
-- textual message concerning the delete operation.
-- begin auxiliary definitions for delete
ListStatuses ::= SEQUENCE OF SEQUENCE{
ResultSetId,
DeleteSetStatus}
DeleteSetStatus ::= [33] IMPLICIT INTEGER{
success (0),
resultSetDidNotExist (1),
previouslyDeletedByTarget (2),
systemProblemAtTarget (3),
accessNotAllowed (4),
resource-control-at-origin (5),
resourceControl-at-target (6),
bulkDeleteNotSupported (7),
notAllRsltSetsDeletedOnBulkDlte (8),
notAllRequestedResultSetsDeleted (9)}
-- 7 and 8 used only if operation is "all".
-- end auxiliary definitions for delete
-- Access Control APDUs
AccessControlRequest ::= SEQUENCE{
referenceId ReferenceId OPTIONAL,
securityChallenge [37] IMPLICIT OCTET STRING}
AccessControlResponse ::= SEQUENCE{
referenceId ReferenceId OPTIONAL,
securityChallengeResponse [38] IMPLICIT OCTET STRING}
-- Resource Control APDUs
ResourceControlRequest ::= SEQUENCE{
referenceId ReferenceId OPTIONAL,
suspendedFlag [39] IMPLICIT BOOLEAN, -- true = suspended
resourceReport [40] IMPLICIT ResourceReport OPTIONAL,
partialResultsAvailable [41] IMPLICIT INTEGER{
subset (1),
interim (2),
none (3)} OPTIONAL,
ResourceControlResponse ::= SEQUENCE{
referenceId ReferenceId OPTIONAL,
continueFlag [42] IMPLICIT BOOLEAN, -- true = continue
resultSetWanted [43] IMPLICIT BOOLEAN OPTIONAL}
"true" = "result set wanted", required during a search if
Continue flag is false; otherwise should not occur
-- Begin auxiliary definitions for access and resource control
ResourceReport ::= SEQUENCE{
resourceReportId [1] IMPLICIT OBJECT IDENTIFIER,
estimates [2] IMPLICIT SEQUENCE OF Estimate,
message [3] IMPLICIT VisibleString}
Estimate ::= SEQUENCE
{estimateType [1] IMPLICIT INTEGER,
from table, determined by ResourceReportId
estimateValue [2] IMPLICIT INTEGER}
the actual estimate
-- End auxiliary definitions for resource and access control
-- begin global auxiliary definitions
ReferenceId ::= [2] IMPLICIT OCTET STRING
-- value provided by the service originator in the Request APDU, target
-- required to send it back unaltered in corresponding response APDU
DatabaseName ::= [105] IMPLICIT VisibleString
ResultSetId ::= [31] IMPLICIT VisibleString
-- end global auxiliary definitions
END -- ANSIZ39-50-2
END.
4.2 PROTOCOL PROCEDURES
4.2.1 Services Required
4.2.1.1 Service Required from the Presentation Layer
The protocol uses the presentation service as defined in ISO
8822 to provide a presentation connection for communication between two
information retrieval applications. The presentation services required are
those contained in the presentation kernel functional unit and the session
duplex functional unit. The common application association control protocol
may have additional requirements for presentation services.
All Information Retrieval protocol data units will be mapped
onto the P-Data service. The communication service that supports this
protocol is a connection-oriented service using the P-DATA service, defined
in ISO 8822 in an established application association, in combination with
the ACSE, ISO 8649.
A Z39.50 origin establishes application-associations as
necessary with the target with whom it is engaged in Z39.50 activity. The
Z39.50 application-service-element (ASE) may then use the P- DATA service
defined in ISO 8822 directly to transmit Z39.50 APDUs. This provides a
connection- oriented interaction between Z39.50 systems. A single
application-association can be used to send a series of Z39.50 APDUs
relating to multiple searches. A single system can be engaged in multiple
application associations with multiple remote systems simultaneously.
4.2.1.2 Association Control Services Assumed
The protocol assumes the services of the association control
service elements as defined in ISO 8649. The services required are:
1) orderly association release, where both sides agree to the release
and there is no loss of data in transit (the IR-release service is
directly mapped to this service without any Information Retrieval
protocol control information), and
2) association abort, which allows either origin or target, at any
time, to explicitly terminate the association, immediately and
unconditionally. Data in transit may be lost (the IR-abort service
is directly mapped to this service without any Information
Retrieval protocol control information).
It is assumed that the Information Retrieval service user will
handle the association control services required to establish an
association with an application context encompassing the Information
Retrieval service.
4.2.2 Protocol Model
To specify protocol procedure, the abstract,
implementation-independent concepts of service-user, service-provider, and
service primitive are used.
A service-provider provides a communication path between two
service users. A service primitive is an element of interraction between
the service-user and the service-provider.
There are four types of service primitives:
1) Request - A primitive issued by the origin service-user to the
service-provider in order to invoke some procedure.
2) Indication - A primitive issued by the service-provider to the
target service-user to indicate that a procedure has been invoked
by its peer.
3) Response - A primitive issued by the target service-user to the
service-provider at the completion of the procedure previously
invoked by an indication.
4) Confirmation - A primitive issued by the service-provider to the
origin service-user to complete the procedure previously invoked by
a request.
Primitives are conceptual and their use neither specifies nor
precludes any specific implementation of a service. Only primitives that
correspond to some element of the service involving the exchange of
information between systems are defined.
From the perspective of the service-user, the service-provider
is system-independent. For the exchange of protocol however, a distinction
is made between those portions of the service-provider residing on the
origin and target systems (respectively, the origin service-provider and
the target service-provider). See figure 4.2.2-1. The sequence of
interractions is:
1) Request Primitive from origin service-user to service-provider.
2) Protocol Message from origin service-provider to target service-provider.
3) Indication Primitive from service-provider to target service-user.
4) Response Primitive from target service-user to service-provider.
5) Protocol Message from target service-provider to origin service-provider.
6) Confirmation Primitive from service-provider to origin service-user.
_____________________ Figure_______________________________________________
ORIGIN TARGET
SERVICE-USER SERVICE-USER
^ ^ ~
3 3 3 3
3 3 3 3
3 36)Confirmation 3)Indication 3 3
3 3 3 3
3 3 3 3
3 3 3 3
1)Request3 3 3 34)Response
3 3 3 3
3 3 3 3
3 3 3 3
3 3 2) Protocol 3 3
\~/ ~ Message ~ \~/
ORIGIN ~DDDDDDDDDDDDDDDDDDDD> TARGET
SERVICE-PROVIDER <~DDDDDDDDDDDDDDDDDDD~SERVICE-PROVIDER
5) Protocol
Message
_____________________________________________________________________
The following illustrates the sequence of interactions which
occur for a Search operation:
1) Search request from origin service-user to service-provider.
2) Search APDU (Application Protocol Data Unit) from origin
service-provider to target service-provider.
3) Search indication from service-provider to target service-user.
4) Search response from target service-user to service-provider.
5) Search-response APDU from target service-provider to origin service-provider.
6) Search confirm from service-provider to origin service-user.
represented by steps 1 and 6 for the origin, and by steps 3 and 4 for the
target, are described solely to facilitate the specification of protocols.
These steps do not represent intersystem communication, and therefore, the
means by which they are implemented are not constrained by this
specification. In an actual implementation, step 4, for example, might
consist of several messages from the target service user to service
provider. On the other hand, both the target service user and service
provider could be combined in a single program, in which case steps 3 and 4
might not have any real physical manifestation.
4.2.3 State Tables
This section defines two Information Retrieval Protocol Machines
(IRPMs) in terms of state tables. One state table is defined for the origin
(table 4-4) and one state table is defined for the target (table 4-5).
Each state table shows the inter-relationship between the state of an
Information Retrieval association, the incoming events that occur in the
protocol, the actions taken, and, finally, the resulting state of the
association. The IRPM state table does not constitute a formal definition
of the IRPM. It is included to provide a more precise specification of the
protocol procedures. The following conventions are used in the state
tables.
State Table Cells The intersection of an incoming event (row) and a state
(column) forms a cell. A blank cell represents the combination of an
incoming event and a state that is not defined for the IRPM. A non blank
cell represents an incoming event and state that is defined for the IRPM.
Such a cell contains one or more actions, separated by semi-colons (;).
Actions to be Taken by the IRPM The IRPM state tables define the action to
be taken by the IRPM in terms of one or more outgoing events (separated by
semi-colons) and the resulting state (in parenthesis) of the Information
Retrieval association.
Invalid Intersections Blank cells indicate an invalid intersection of an
incoming event and state. The state tables define correct operation only.
They do not specify actions to be taken in response to incorrect operation
(for example, erroneous protocol control information, incorrect protocol
control actions, etc). Such actions are not within the scope of the
specification, although implementations must consider them.
Table 20: Events and Actions
The following tables list the events and actions which occur in the
state tables and their abbreviations as used in the state tables.
Incoming Events -- Origin Abbreviation
Init request Init req
Init-response PDU Init resp PDU
Search request Srch req
Search-response PDU Srch resp PDU
Present request Prsnt req
Present-response PDU Prsnt resp PDU
Delete request Dlte req
Delete-response PDU Dlte resp PDU
Resource-control PDU Rsc PDU
Resource-control response Rsc resp
Access-control PDU Acc PDU
Access-control response Acc resp
P-P-abort indication Pab ind
IR-abort request Iab req
IR-release request Irel req
A-release confirm Arel conf
Outgoing Actions -- Origin Abbreviation
Init PDU Init PDU
Init confirm Init conf
Search PDU Srch PDU
Search confirm Srch conf
Present PDU Prsnt PDU
Present confirm Prsnt conf
Delete PDU Dlte PDU
Delete confirm Dlte conf
Resource-control indication Rsc ind
Resource-control-response PDU Rsc resp PDU
Access-control indication Acc ind
Access-control-response PDU Acc resp PDU
IR-abort indication Iab ind
A-abort request Aab req
A-release request Arel req
IR-release confirm Irel conf
Save current state stkst
Restore previously saved state popst
Incoming Event -- Target Abbreviation
Init PDU Init PDU
Init response Init resp
Search PDU Srch PDU
Search response Srch resp
Present PDU Prsnt PDU
Present response Prsnt resp
Delete PDU Dlte PDU
Delete response Dlte resp
Resource-control request Rsc req
Resource-control-response PDU Rsc resp PDU
Access-control request Acc req
Access-control-response PDU Acc resp PDU
A-P-abort indication Apab ind
A-abort indication Aab ind
IR-abort request Iab req
A-release indication Arel ind
IR-release response Irel resp
Outgoing Action -- Target Abbreviation
Init indication Init ind
Init-response PDU Init resp PDU
Search indication Srch ind
Search-response PDU Srch resp PDU
Present indication Prsnt ind
Present-response PDU Prsnt resp PDU
Delete indication Dlte ind
Delete-response PDU Dlte resp PDU
Resource-control PDU Rsc PDU
Resource-control confirm Rsc conf
Access-control PDU Acc PDU
Access-control confirm Acc conf
IR-abort indication Iab ind
Outgoing Action -- Target (continued) Abbreviation
A-abort request Aab req
IR-release indication Irel ind
A-release response Arel resp
Save current state stkst
Restore previously saved state popst
Table 21: Definition of States
Origin states
1. Closed: the origin is awaiting an Init request from the application
2. Init sent: the origin has transmitted an Init APDU to the target
3. Open: the origin is awaiting a Search, Present, or Delete request
4. Search sent: the origin has transmitted a Search APDU
5. Prsnt sent: the origin has transmitted a Present APDU
6. Delete sent: the origin has transmitted a Delete APDU
7. Rsctrl recvd: the origin has issued a Resource-control indication
8. Acctrl recvd: the origin has issued an Access-control indication
9. Rlease sent: the origin has issued an A_release request
Target states
1. Closed: the target is awaiting an Init APDU
2. Init recvd: the target has issued an Init indication
3. Open: the target is awaiting a Search, Present, or Delete APDU
4. Search recvd: the target has issued a Search indication
5. Prsnt recvd: the target has issued a Present indication
6. Delete recvd: the target has issued a Delete indication
7. Rsctrl sent: the target has transmitted a Resource-control APDU
8. Acctrl sent: the target has transmitted an Access-control APDU
9. Rlease Recvd: the target has issued an IR_rel indication.
10. Reject: the target has transmitted an Init Response APDU (REJECT)
Table 22: State Table for Origin Systems
STATE
EVENTclosed
1 Init
sent
2 Open
3Search
sent
4Prsnt
sent
5Delete
sent
6Rsctrl
recvd
7Acctrl
Recvd
8Rlease
sent
9Init
reqInit PDU
(2)Init resp
PDU (ACCEPT)Init conf+
(3)Init resp
PDU
(REJECT)Init conf-
;Arel req
[(9)Srch
reqSrch
PDU (4)Srch resp PDUSrch
conf (
Table 22 (continued): State Table for Origin Systems
STATE
EVENTClosed
1Init
sent
2OpenSearch
sent
4Prsnt
sent
5Delete
sent
6Rsctrl
recvd
7Acctrl
recvd
8Rlease
sent
9Prsnt reqPrsnt
PDU
(5)Prsnt resp
PDUPrsnt
conf (3)Dlte reqDlte
PDU
(6)Dlte resp
PDUDlte
conf (3)Rsc PDURsc
ind;
stkst
(7)Rsc ind;
stkst (7)Rsc ind;
stkst (7)Rsc ind;
stkst (7)Rsc respRsc
resp
PDU;
popstAcc PDUAcc
ind;
stkst
(8)Acc ind;
stkst (8)Acc ind;
stkst (8)Acc ind;
stkst (8)Acc respAcc
resp
PDU;
popst Aab indIab ind
(1)Iab
ind (1)Iab ind
(1)Iab ind
(1)Iab ind
(1)Iab ind
(1)Iab ind
(1)Iab ind
(1)Apab indIab ind
(1)Iab
ind (1)Iab ind
(1)Iab ind
(1)Iab ind
(1)Iab ind
(1)Iab ind
(1)Iab ind
(1)Iab reqAab
req (1)Aab
req (1)Aab req
(1)Aab req
(1)Aab req
(1)Aab
req (1)Aab
req (1)Aab req
(1)Irel reqArel
req (9)Arel confIrel conf
(1)Table 23: State Table for Target Systems
\ State
\
Event\Closed Init
recvd
2Open
3Search
recvd
4Prsnt
recvd
5Delete
recvd
6Rsctrl
sent
7Acctrl
sent
8Rlease
recvd
9Reject
10Init
PDUInit
ind
(2)Init
resp
(ACCEPT)Init
resp
PDU(+)
(3)Init
resp
(REJECT)Init
resp
PDU(-)
(10)Srch
PDUSrch
ind
(4)Srch
respSrch
resp
PDU
(3)Prsnt
PDU Prsnt
ind
(5)Prsnt
respPrsnt
resp
PDU
(3)Dlte
PDUDlte
ind
(6)Dlte
respDlte
resp
PDU
(3)Rsc
reqRsc
PDU;
stkst
(7)Rsc
PDU;
stkst
(7)Rsc
PDU;
stkst
(7)Rsc
PDU;
stkst
(7)Table 23 Continued
\
State
\
Event\Closed Init
recvd
2Open
3Search
recvd
4Prsnt
recvd
5Delete
recvd
6Rsctrl
sent
7Acctrl
sent
8Rlease
recvd
9Reject
10Rsc
resp
PDURsc
conf;
popstAcc
reqAcc
PDU;
stkst
(8)Acc
PDU;
stkst
(8)Acc
PDU;
stkst
(8)Acc
PDU;
stkst
(8)Acc
resp
PDUAcc
conf;
popstAab
indIab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Apab
indIab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
ind
(1)Iab
reqAab
req
(1)Aab
req
(1)Aab
req
(1)Aab
req
(1)Aab
req
(1)Aab
req
(1)Aab
req
(1)Aab
req
(1)Aab
req
(1)Arel
indIrel
ind
(9)Irel
ind
(9)Irel
respArel
resp
(1)
4.2.4 Protocol Errors
Any events not listed in the tables of section 4.2.3 are not valid and
are considered to be protocol errors. With exceptions specified in section
4.3, incorrectly formatted APDU's or APDU's with invalid data are also
considered to be protocol errors. This standard does not specify the
actions to be taken upon detection of protocol errors. [An application
context may contain such a specification.
4.3 RULES FOR EXTENSIBILITY
All syntactical errors in received APDUs are considered to be protocol
errors except for the following case: Unknown data elements, and unknown
options within the Options data element, will be ignored on received Init
APDUs.
4.4 CONFORMANCE
A system claiming to implement the procedures in this standard shall
comply with the requirements in sections 4.4.1, 4.4.2, and 4.4.3.
4.4.1 Static Requirements
The system shall:
a) act in the role of an origin (by sending Init, Search, and
Present APDUs and recieving Init-response, Search-response and
Present-response APDUs), or target (by responding properly to
Init, Search, and Present APDUs with appropriate Init-response,
Search-response and Present-response APDUs), or both; and,
b) support the syntax in section 4.1, and
c) support the Type-1 Query.
4.4.2 Dynamic Requirements
The system shall exhibit external behavior consistent with having implemented:
a) an Information Retrieval ASE which follows all the procedures
specified in sections 4.1.1, 4.2, and 4.3;
b) the mapping onto the Association Control Service and
Presentation Service (see 4.2.1); and
c) assignment of values to APDU data elements according to the
procedures describes in section 3.
d) encoding of APDUs by applying the ASN.1 Basic Encoding Rules
(ISO 8825) to the abstract syntax defined in section 4.1.1.
e) the type-1 query whose abstract syntax is defined in section
4.1.1 and whose structure is and rules for evaluation are
described in the comments within section 4.1.1.
4.4.3 Statement Requirements
1. The following shall be stated by the implementer:
a) whether the system is capable of acting in the role of origin,
b) whether the system is capable of acting in the role of target,
c) that the system supports [versions 1 and 2 of [the Z39.50-1991
protocol.
2. If the system claims capability of acting in the role of origin the implementor shall state whether
the system:
a) accepts Access-control APDUs and sends Access-control-response
APDUs,
b) accepts Resource-control APDUs and sends Resource-control-response
APDUs,
c) sends Delete APDUs and accepts Delete-response APDUs,
d) sends Search and Present APDUs specifying named result sets
other than "default".
3. If the system claims capability of acting in the role of target, the
implementor shall state whether the system:
a) sends Access-control APDUs and accepts Access-control-response
APDUs,
b) sends Resource-control APDUs and accepts Resource-control-response
APDUs,
c) accepts Delete APDUs and sends Delete-response APDUs,
d) accepts Search and Present APDUs specifying named result sets
other than "default",
e) unilaterally deletes result sets.
4. The implementor shall state to what extent result sets may be specified
as operands in a type-1 query:
a) whether named result sets in general, or only the default result
set, may be used as an
operand in a Type-1 query,
b) whether result sets may be specified only as the first operand
in a Type-1 query, or that they
may be specified as any operand,
c) with which operators (AND, OR, AND-NOT) may result sets be used
as operands.
5. The implementor shall state to what extent element set names are
supported in Search and Present APDUs:
a) whether the parameter Element-set-names is supported,
b) if the parameter element-set-names is supported, whether
database names corresponding to element set names may be
specified, or only a single element set name and no
corresponding database name may be specified.
6. The implementor shall state:
a) for each optional parameter in each APDU, whether or not the
parameter is supported;
f) which encoding rules are supported;
a) the maximum number of database names which may be specified in a
Search APDU;
e) which attribute sets are supported.
APPENDIX A: Object Identifiers Assigned in This Standard
This appendix is part of the standard.
The following object identifier value has been assigned to this
standard, ANSI-standard-Z39.50:
{ iso (1) member-body (2) US (840) ANSI-standard-Z39.50 (10003)}
This standard assigns the following values at the level immediately
subordinate to ANSI-standardZ39.50:
1 = application context
2 = abstract syntax
3 = attribute set
4 = diagnostic set
5 = record syntax
6 = resource report format
A.1 Application Context
This standard assigns the following object identifier for the
application-context-definition 'basic-Z39.50-ac', contained in Appendix B:
{ iso member-body US ANSI-standard-Z39.50 application-context (1)
basic-Z39.50-ac (1) }
A.2 Abstract Syntax
This standard assigns the following object identifier for the ASN.1
module, contained in section
4.1, defining the Z39.50 APDUs:
{ iso member-body US ANSI-standard-Z39.50 abstract-syntax (2) Z39.50-apdus (1) }
syntax for apdus. The transfer syntax results from the application of the
ASN.1 Basic Encoding Rules (ISO 8825). For the purposes of Presentation
Context negotiation, this syntax is identified by a pair of object
identifiers, one for the abstract-syntax (Z39.50-apdus) and one for the
basic encoding rules:
{ joint-iso-ccitt asn1 (1) basic-encoding (1) }
A.3 Attribute set
This standard assigns the following object identifier for the
attribute-set definition 'bib-1', contained in Appendix C:
{ iso member-body US ANSI-standard-Z39.50 attribute-set (3) bib-1 (1) }
A.4 Diagnostic Set
This standard assigns the following object identifier for the
diagnostic set definition contained in appendix D.
{ iso member-body US ANSI-standard-Z39.50 diagnostic-set (4) bib-1 (1)}
A.5 Record Syntax
Object identifier for Record syntaxes are contained in appendix E.
A.6 Resource Report Format
This standard assigns the following object identifier for the resource
report format defined in appendix F.
{ iso member-body US ANSI-standard-Z39.50 resource-report-format (6) bib-1 (1)}
APPENDIX B: Definition of Application Context basic-Z39.50-ac
This appendix is part of the standard.
This appendix defines the application context basic-Z39.50-ac. The
object identifier for application context basic-Z39.50-ac is defined and
registered in Appendix A.
Definition of application context basic-Z39.50-ac
ANSI-standard-Z39.50 application context basic-Z39.50-ac, supports an
application-entity that contains only the following two application service
elements (ASEs):
a) the Association Control service element (ACSE, ISO 8650), and
b) the Z39.50 service element.
[Z30.50 and ACSE are used according to the procedures in section 4.2.1.
The P-Data service is used to transmit Z39.50 APDUs.
In the event of protocol errors, the system detecting the error shall abort
the association.
APPENDIX C: Attribute Set bib-1
This appendix is part of the standard.
This Appendix defines the attribute-set bib-1. [Attribute-set
bib-1 is intended for use with bibliographic databases. The object
identifier for attribute set bib-1 is defined and registered in Appendix A.
When the value of AttributeSetId (within the RPNDefinition within
the Search APDU) equals the object identifier for this attribute-set, then:
a) AttributeType (within AttributeElement within AttributeList) takes
values from the Attribute type table below, and
b) AttributeValue takes values from the corresponding value table.
Attribute-Type Values
Attribute-type Value
Use 1
Relation 2
Position 3
Structure 4
Truncation 5
Completeness 6
USE Values
Use Value Use Value
Personal-name 1 MESH-subject 25
Corporate-name 2 PA-subject 26
Conference-name 3 LC-subject-heading 27
Title 4 RVM-subject-heading 28
Title-series 5 Local-subject-index 29
Title-uniform 6 Date 30
ISBN 7 Date-of-publication 31
ISSN 8 Date-of-acquisition 32
LC-card-number 9 Title-key 33
BNB-card-number 10 Title-collective 34
BGF-number 11 Title-parallel 35
Local-number 12 Title-cover 36
Dewey-classification 13 Title-added-title-page 37
UDC-classification 14 Title-caption 38
Bliss-classification 15 Title-running 39
LC-call-number 16 Title-spine 40
NLM-call-number 17 Title-other-variant 41
NAL-call-number 18 Title-former 42
MOS-call-number 19 Title-abbreviated 43
Local-classification 20 Title-expanded 44
Subject-heading 21 Subject-precis 45
Subject-Rameau 22 Subject-rswk 46
BDI-index-subject 23 Subject-subdivision 47
INSPEC-subject 24 Number-natl-bibliography 48
Number-legal-deposit 49 Name-and-title 57
Number-govt-publication 50 Name-geographic 58
Number-publisher-for-music 51 Place-publication 59
Number-db 52 CODEN 60
Number-local-call 53 Microform-generation 61
Code-language 54 [Abstract 62
Code-geographic-area 55 [Note 63
Code-institution 56
Author-title 1000 [Author 1007
NUC-code 1001 [Author-name-personal 1008
Combination-of-use 1002 Author-name-corporation 1009
System-control-number 1003 Author-name-conference 1010
Subject-classification 1004 Identifier-standard 1011
Record-type 1005 Subject-LC-children's 1012
Name 1006 Subject-name-personal 1013
Relation Values
Relation Value
equal 3
greater than 5
greater or equal 4
less than 1
less than or equal 2
not equal 6
Position Values Structure Values
Position Value Structure Value
first in field 1 phrase 1
first in subfield 2 word 2
key 3
year 4
any position in field 3 date 5
word list 6
Truncation Values Completeness Values
Truncation Value Completeness Value
do not truncation 100 incomplete subfield 1
right truncation 1 complete subfield 2
left truncation 2 complete field 3
left and right 3
process # in search arg
101APPENDIX D: Diagnostic Set bib-1 (This appendix is part of the Standard.)
This Appendix defines the diagnostic set bib-1. The object
identifier for diagnostic set bib-1 is defined and registered in Appendix
A. When the value of DiagnosticSetId (within DiagRec within the auxiliary
definitions for Search Response and Present Response APDUs) equals the
object identifier for this diagnostic set, then "condition" (within
DiagRec) takes values from the "Condition" column in the table below.
CONDITION MEANING TYPE
1 Permanent system error (1)
2 Temporary system error (1)
3 Unsupported search (2)
4 Terms only exclusion (stop) words (2)
5 Too many argument words (2)
6 Too many boolean operators (2)
7 Too many truncated words (2)
8 Too many incomplete subfields (2)
9 Truncated words too short (2)
10 Invalid format for rec no (search term) (2)
11 Too many characters in search statement (2)
12 Too many records retrieved (2)
13 Present request out-of-range (see note) (3)
14 System error in presenting records (4)
15 Record not authorized to be sent intersystem (4)
16 Record exceeds Preferred-message-size (4)
17 Record exceeds Maximum-record-size (4)
18 Result set not supported as a search term (2)
19 only single rslt set as srch trm supported (2)
20 only ANDing of a single result set as search term supported (2)
21 result set exists and replace indicator off (2)
22 result set naming not supported (2)
23 combination of specified databases not supported(2)
24 Element set names not supported (1)
25 Specified element set name not valid for specified database (1)
26 only a single element set name supported (1)
27 Result set no longer exists - unilaterally deleted by target (1)
28 Result set is in use (1)
29 One of the specified databases is locked (1)
30 Specified result set does not exist (1)
31 Resources exhausted - no results available (2)
32 Resources exhausted - unpredictable partial results available (2)
33 Resources exhausted - valid subset of results available (2)
100 Access-control failure (1)
101 Security challenge required but could not be issued - request
terminated (1)
102 Security challenge required but could not be issued - record
not included (4)
103 Security challenge failed - record not included (4)
104 Terminated by negative continue response (1)
TYPES: (1) May occur when search-status or present-status
= "failure".
(2) May occur only when search-status = "failure".
(3) May occur only when present-status = "failure".
(4) May occur only as a surrogate for a database record.
request is partially or wholly out-of-range, and includes the case when
result-count is zero, but does not include the case where the specified
result set does not exist.
APPENDIX E: Record Syntaxes
This appendix is part of the Standard.
This appendix defines and registers object identifiers for record
syntaxes. Names are assigned using the ASN.1 notation (ISO 8824) for
OBJECT IDENTIFIER values:
ANSI-Z39-50-2 DEFINITIONS ::=
BEGIN
Z39-50 OBJECT IDENTIFIER ::= { iso (1) member-body (2) US (840)
ANSI-standard-Z39.50 (10003)}
RecordSyntax OBJECT IDENTIFIER ::= { Z39-50 (5) }
Unimarc ::= OBJECT IDENTIFIER { RecordSyntax (1) }
Intermarc ::= OBJECT IDENTIFIER { RecordSyntax (2) }
CCF ::= OBJECT IDENTIFIER { RecordSyntax (3) }
US-MARC ::= OBJECT IDENTIFIER { RecordSyntax (10) }
UK-MARC ::= OBJECT IDENTIFIER { RecordSyntax (11) }
NORMARC ::= OBJECT IDENTIFIER { RecordSyntax (12) }
LIBRISMARC ::= OBJECT IDENTIFIER { RecordSyntax (13) }
DANMARC ::= OBJECT IDENTIFIER { RecordSyntax (14) }
FINMARC ::= OBJECT IDENTIFIER { RecordSyntax (15) }
MAB1 ::= OBJECT IDENTIFIER { RecordSyntax (16) }
CAN/MARC ::= OBJECT IDENTIFIER { RecordSyntax (17) }
SBN ::= OBJECT IDENTIFIER { RecordSyntax (18) }
PICAMARC ::= OBJECT IDENTIFIER { RecordSyntax (19) }
END
NOTES:
(1) The above object identifiers are intended to be used as the values
of PreferredRecordSyntax in Search and Present APDUs.
(2) For the purposes of Presentation Context negotiation, record syntax
is identified by a pair of object identifiers, one from the above list for
the abstract-syntax and one for the transfer syntax. No object identifiers
are assigned by this standard for transfer syntax for bibliographic
records. However, an object identifiers has been assigned (outside of this
standard) for the transfer-syntax for bibliographic records defined in ISO
2709:
{ iso standard 2709 transfer-syntax (1) character-encoding (1) }
APPENDIX F: Resource Report Format bib-1
This appendix is part of the standard.
This Appendix defines the resource report format bib-1. The
object identifier for resource report format bib-1 is defined and
registered in Appendix A.
When the value of ResourceReportId (within ResourceReport within
the auxiliary definitions for the Resource Request APDU) equals the object
identifier for this resource report format, then EstimateType (within
Estimate) takes values from the "type" column in the table below.
Type Meaning
1 estimate of current result for search
2 estimate of result at end of search if it completes
3 estimate of current result for present
4 estimate of result at end of present if it completes
5 processing time used by this command so far
6 estimated total processing time for command if allowed to complete
7 estimate of processing time used by association so far
8 estimate of cost for this command so far
9 estimate of cost for command if completed
10 estimate of cost for this association so far
------------------------------
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.