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.

• 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

1. The origin must accept the parameter additionalSearchInfo in a Search response.
2. The origin must accept both the VisibleString and InternationalString form of the addInfo parameter within a diagnostic record.
3. The origin must accept diagnostics in both the default and external forms.
4. The origin must accept multiple non-surrogate diagnostic records in a Search or Present response.
5. The origin must accept the parameter otherInfo in any APDU.
6. The origin must support receipt of a Close request.
7. 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

1. The target must recognize search terms in a type-1 query of type OCTET STRING, INTEGER, InternationalString, OBJECT IDENTIFIER, GeneralizedTime, EXTERNAL, IntUnit, or NULL.
2. 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.
3. The target must recognize the operand 'resultAttr' within a type-1 query .
4. The target must recognize the operator 'prox' within a type-1 query.
5. 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.
6. The target must recognize a type-102 query.
7. The target must accept the parameter additionalSearchInformation in a Search request.
8. The target must recognize the parameter AdditionalRanges on a Present request.
9. The target must recognize the 'complex' (in addition to the 'simple') form of the parameter recordComposition on a Present request.
10. The target must accept the parameter otherInfo in any APDU.
11. The target must support receipt of a Close request.
12. 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

1. 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.
2. 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

1. 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.
2. If the target implements resource control, the target must recognize the parameter OpId of the Resource-report request.