Z39.50 Version 3 Baseline Requirements
The following analysis of Z39.50 version 3 Baseline Requirements
is considered approved, as of December 1, 1995.
This document is based on analysis of versions 2 and 3 of Z39.50 to
determine the minimum requirements, beyond version 2, for a Z39.50
implementation to claim conformance to version 3, that is, to (legally)
indicate in an Init request or response that it supports version 3.
I.e., what must a conforming V2 system implement in order to migrate to V3?
Purpose
The primary purpose of this analysis is to provide a basis to begin
interoperability testing of V3 implementations. This will be refined, if
necessary, as V3 implementation and testing proceeds. The objective is to
develop, among Z39.50 V3 implementors, a common understanding of minimum
requirements for V3 conformance.
An ancillary purpose is to confront apprehensions about the complexity of
V3 relative to V2. Z39.50-1995 (which specifies both V2 and V3) reflects
functional requirements posed by many and diverse companies and is
significantly richer in functionality than Z39.50-1992 (which specifies V2
only). As such, a single product generally would not implement the complete
Z39.50-1995 standard, but only a subset relevant to the functionality that the
product is intended to support. The complexity of that subset will depend on
the complexity of the required functionality. Thus a simple subset will be
marginally more complex than a baseline V3 implementation, which in turn is
marginally more complex than V2, which is now recognized as relatively
straightforward to implement. The latter, baseline, margin of complexity is
represented by the requirements listed below.
The Version 3 Baseline Requirements include core and
conditional requirements.
Core requirements apply to all version 3 implementations.
Conditional requirements pertain to features that are optional in version
2. These are requirements that are applicable in version 3 only if a
particular, optional feature is implemented, and only if that feature was part
of version 2. Only the Delete, Access-control, and Resource-report Services
are affected.
Requirements are listed separately for origin and target.
In the rules below, the terms accept, recognize and
support have the following meaning:
- Rules stating that a system must accept a particular object
mean that the system must not declare a protocol error due to receipt of
that object; the system is not required to interpret or process
information within the object.
- Rules stating that a system must recognize a particular object
mean that the system must not declare a protocol error due to receipt of
that object, and must either support the object (see below) or must
respond appropriately (e.g. with a diagnostic) that it does not support
the object.
- Rules stating that a system must support a particular function
mean that the system must implement the function and exhibit behavior
prescribed in the standard pertaining to that function.
Core Requirements
V3 Core Requirements for Origin
- The origin must accept the parameter additionalSearchInfo in a Search
response.
- The origin must accept both the VisibleString and InternationalString
form of the addInfo parameter within a diagnostic record.
- The origin must accept diagnostics in both the default and external
forms.
- The origin must accept multiple non-surrogate diagnostic records in a
Search or Present response.
- The origin must accept the parameter otherInfo in any APDU.
- The origin must support receipt of a Close request.
- In the absence of character-set negotiation, the origin must accept all
values conforming to the GeneralString definition for parameters of
ASN.1 type InternationalString.
V3 Core Requirements for Target
- The target must recognize search terms in a type-1 query of type OCTET
STRING, INTEGER, InternationalString, OBJECT IDENTIFIER,
GeneralizedTime, EXTERNAL, IntUnit, or NULL.
- The target must recognize within a type-1 query (in addition to the
global attribute set id) an attribute set id qualifying any individual
attribute within the query.
- The target must recognize the operand 'resultAttr' within a type-1 query
.
- The target must recognize the operator 'prox' within a type-1 query.
- The target must recognize (in addition to numeric attribute values)
attribute values of form 'complex'(as defined in the ASN.1 for APDUs)
within a type-1 query.
- The target must recognize a type-102 query.
- The target must accept the parameter additionalSearchInformation in a
Search request.
- The target must recognize the parameter AdditionalRanges on a Present
request.
- The target must recognize the 'complex' (in addition to the 'simple')
form of the parameter recordComposition on a Present request.
- The target must accept the parameter otherInfo in any APDU.
- The target must support receipt of a Close request.
- In the absence of character-set negotiation, the target must accept all
values conforming to the GeneralString definition for parameters of
ASN.1 type InternationalString.
Conditional Requirements
V3 Conditional Requirements for Origin
- If the origin implements the Delete service as well as concurrent
operations: the origin must accept a value of 'failure-10' for the
Delete-list-status on Delete response.
- If the origin implements the Resource-report service, the origin must
accept a value of failure-5 or failure-6 for Resource-report-status in
Resource-report response.
V3 Conditional Requirements for Target
- If the target implements access control, the target must accept an
Access-control response where the parameter Security-challenge-response
is omitted and which includes a diagnostic.
- If the target implements resource control, the target must recognize the
parameter OpId of the Resource-report request.
Library
of Congress
Library of Congress Help Desk
(02/14/96)