[Table of Contents | Previous Section | Next Section]

4.2 Protocol Procedures
Protocol procedures are described in this section. Rules for extensibility and conformance requirements are specified in sections 4.3 and 4.4 respectively.

[Note: These protocol procedures are amended by Z39.50-1995 Amendment 3: Z39.50 Encapsulation.]

4.2.1 Presentation and Association Control Services
The Information Retrieval protocol may be used in conjunction with the presentation layer and the association control service element (ACSE).

4.2.1.1 Service Provided by the Presentation Layer
Z39.50 may use the presentation service as defined in ISO 8822 to provide a presentation connection for communication between a Z39.50 origin/target pair. The communication service that supports this protocol is a connection-oriented service defined in ISO 8822 in an established application association, in combination with ACSE, ISO 8649.

A Z39.50 origin establishes application-associations as necessary with the target. 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.

4.2.1.2 Association Control Services
The complete application service may include ACSE, and one or more specific application services, such as the Information Retrieval application service.

ACSE, defined in ISO 8649, is used to establish an A-association, and provides association management. The life of an A-association has three distinct phases: establishment, information transfer, and termination. ACSE provides services for the establishment and termination phases, including the selection of an application context, specifying information including the set of service elements that are valid during the information transfer phase. Prior to the exchange of Z39.50 APDUs, the Information Retrieval service user invokes the association control services required to establish an association with an application context encompassing the Information Retrieval service. The application context "basic-Z39.50-ac" is defined and registered in Appendix 2, CTX.

A single application-association can be used to support a series of Z-Associations. A single system can be engaged in multiple application associations with multiple remote systems simultaneously.

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. In this model, the service-provider is analogous to the application layer composed of the Z39.50 origin/target pair. The client is modeled as a service-user together with an origin, and the server is modeled as a service-user together with a target. The two service users are referred to as the origin service-user and target service-user.

A service primitive is an element of interaction between a service-user and the service-provider. There are four types of service primitives: Request, Indication, Response and Confirmation. For a confirmed service initiated by the origin (i.e., for Z39.50: Init, Search, Present, Delete, Resource-report, Sort, Scan, Extended-services) they are used as follows:

• Request - A primitive issued by the origin to the service-provider in order to invoke some procedure.
• Indication - A primitive issued by the service-provider to the target service-user to indicate that a procedure has been invoked by its peer.
• Response - A primitive issued by the target service-user to the service-provider at the completion of the procedure previously invoked by an indication.
• Confirmation - A primitive issued by the service-provider to the origin service-user to complete the procedure previously invoked by a request.

Notes:

1. For a confirmed service initiated by the target (i.e., for Z39.50: Access-control and Resource-control) the roles of origin and target are reversed.
2. For a non-confirmed service (i.e., for Z39.50: Segment, Trigger-resource-control, Close) only the Request and Indication primitives are used.

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 drawn between the portion of the service-provider residing on the client and the portion of the service-provider residing on server (respectively, the origin and the target). The sequence of interactions for a confirmed service initiated by the origin is:

1. Request Primitive from origin service-user to service-provider.
2. Protocol Message from origin to target.
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 to origin.
6. Confirmation Primitive from service-provider to origin service-user.

Notes:

1. For a confirmed service initiated by the target, the roles of origin and target are reversed.
2. For a non-confirmed service, only steps 1 through 3 apply.

The following illustrates the sequence of interactions that occur for a Search operation:

1. Search request from origin service-user to service-provider.
2. Search APDU from origin to target.
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 to origin.
6. Search confirm from service-provider to origin service-user.

The interactions between service user and service-provider, as represented by steps 1 and 6 for the client, and by steps 3 and 4 for the server, are described solely to facilitate the specification of protocols. These steps do not represent intersystem communication, and the means by which they are implemented are not constrained by this specification. For example, in an actual implementation the target service-user and service-provider might be combined in a single program, and steps 3 and 4 might not have any real physical manifestation.

4.2.3 State Tables

This section defines Information Retrieval Protocol Machines (IRPMs) in terms of state tables. For both origin and target, there are three protocol machines defined, one for the Z-Association (called the "Z-machine") and two for Z39.50 operations (called "O-machines"). One O-machine is for a Present operation and one O-machine is for any other type operation, excluding Init which is included in the Z-machine.

There is one instance of the Z-machine (within a given application association) each for the origin and target; there may be multiple concurrent instances of the O-machines.

Each state table shows the interrelationship between the state of an operation or Z-Association, the incoming events that occur in the protocol, the actions taken, and, finally, the resulting state. The state tables do not constitute a formal definition of the IRPM. They are 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 (;). The last such action specified is always a transition to the resulting state, in parentheses.

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.

Predicates. Some actions are predicated on a certain condition, or "predicate." The notation for these actions takes one of the following two forms:

:[predicate] actions:
or
:[predicate] actions else actions:

where "actions" is either a single action or multiple actions separated by semicolon. The following predicates are defined:

Predicate and Meaning:

resp "Response required" on a Resource Control PDU.

noResp "No response required" on a Resource Control PDU.

conc Concurrent operations in effect.

noOps No active operations.

Variables. The following variables are used:

Variable and Meaning:

<op> An operation type (other than Init): search, present, delete, scan, sort, resource-report, Extended-services.

opCnt Number of active operations.

retSt Return state. An integer; the action "(retSt)" means "go to the state whose value is retSt".

Notes pertaining to the tables:

1. Access-control and resource-control events, actions, and states are distinguished according to whether they pertain to an operation or to the Z-association. (If concurrent operation is not in effect, all pertain to an operation. During initialization, all pertain to the initialization operation.) Those that pertain to an operation are reflected in the operation state table, except for those that occur during initialization (those are shown in part 1 of the Z-association table) and those that pertain to an aborted operation (those apply to part 3 of the Z-association table). Those that pertain to the Z-association are shown in part 2 of the Z-association table (except as noted in notes 4 and 5). All abbreviations for states, events, and actions for access- or resource-control beginning with "Z-" (e.g. "Z-Acc PDU") pertain to the Z-association. All others (e.g. "Acc PDU") pertain to an operation.
2. During initialization, access control or resource control requests may be received by the origin but only if the origin has indicated support (though this is not reflected in the state tables). The origin may not send Trigger-resource-control, because initialization is not complete so it has not yet been successfully negotiated. Neither the origin nor target may initiate Close during initialization.
3. "End-operation indication" is a pseudo-action by the O-machine and corresponding event to the Z-machine. The O-machine issues the indication to the Z-machine, which receives it also as an indication. Its meaning is that an operation has ended (it is necessary for the Z-machine to keep track of the number of active operations so that it will know whether there are zero, one, or multiple concurrent active operations).
4. After the origin sends a Close PDU, PDUs may arrive that were sent before the target receives the Close PDU. When the origin is in "Close sent" state, it ignores all such PDUs if they pertain to an (aborted) operation. If an Access-control request pertaining to the Z-association is received, it is similarly ignored. However, if a Resource-control request pertaining to the application is received, and if it specifies that "no response is required" it is passed to the application, because it may include useful information. If a resource-control request specifies "response required" it is ignored.
5. After the target sends a Close PDU, it ignores any received PDUs until it receives a Close PDU. When the target is in "Close Recvd" state, it may send one or more Resource-control requests before sending the Close PDU, but they must indicate "no response required".

Definition of States

Origin States

Origin States for Z-association

0. Closed: The origin is awaiting an Init request from the service-user.

1. Init Sent: The origin is awaiting an Init-response PDU from the target.

2. Acc Recvd: During initialization the origin has received an Access-control PDU and is awaiting an Access-control response from the service-user.

3. Rsc Recvd: During initialization the origin has received a resource-control PDU and is awaiting a Resource-control response from the service-user.

4. Serial Idle: The Z-association is established, there are no active operations, and 'serial operations' is in effect.

5. Concurrent Idle: The Z-association is established, there are no active operations, and 'concurrent operations' is in effect.

6. Serial Active: There is an active operation and 'serial operations' is in effect.

7. Concurrent Active: There is at least one active operation, and 'concurrent operations' is in effect.

8. Z-Acc recvd: The origin has received an Access-control PDU pertaining to the Z-association and is awaiting an Access-control response from the service-user.

9. Z-Rsc recvd: The origin has received a Resource-control PDU pertaining to the Z-association and is awaiting a Resource-control response from the service-user.

10. Close sent: The origin is awaiting a Close PDU from the target.

11. Close Received: The origin is awaiting a Close response from the service-user.

Origin States for Operation

1. For Present operation: Present sent: The origin is awaiting a Present-response PDU from the target. For operation other than Present: <Op> sent: The origin is awaiting an <Op>-response PDU from the target.
2. Rsc recvd: The origin has received a Resource-control-request PDU pertaining to the operation and is awaiting a Resource-control response from the service-user.
3. Acc recvd: The origin has received an Access-control-request PDU pertaining to the operation and is awaiting an Access-control response from the service-user.

Target States

Target States for Z-association

0. Closed: The target is awaiting an Init PDU from the origin.

1. Init recvd: The target is awaiting an Init Response from the service-user.

2. Acc Sent: During initialization the target has sent an Access-control PDU and is awaiting an Access-control-response PDU from the origin.

3. Rsc sent: During initialization the target has sent a Resource-control PDU and is awaiting a Resource-control-response PDU from the origin.

4. Serial Idle: The Z-association is established, there are no active operations, and 'serial operations' is in effect.

5. Concurrent Idle: The Z-association is established, there are no active operations, and 'concurrent operations' is in effect.

6. Serial Active: There is an active operation and 'serial operations' is in effect.

7. Concurrent Active: There is at least one active operation, and 'concurrent operations' is in effect.

8. Z-Acc sent: The target has sent an Access-control PDU pertaining to the Z-association and is awaiting an Access-control-response PDU from the origin.

9. Z-Rsc sent: The target has sent a Resource-control PDU pertaining to the Z-association and is awaiting a Resource-control-response PDU from the origin.

10. Close sent: The target is awaiting a Close PDU from the origin.

11. Close Received: The target is awaiting a Close response from the service-user.

Target States for Operation

1. For Present operation: Present sent: The target is awaiting a Present response from the service-user. For operation other than Present: <Op> sent: The target is awaiting an <Op>-response PDU from the service-user.
2. Rsc sent: The target has sent a Resource-control PDU pertaining to the operation and is awaiting a Resource-Control-response PDU from the origin
3. Acc sent: The target has sent an Access-control PDU pertaining to the operation and is awaiting an Access-control-response PDU from the origin.

Events and Actions

Listed below are the events and actions that appear in the tables. Those corresponding to a service primitive or APDU are listed first (in alphabetical order by the abbreviation used in the tables) followed by miscellaneous actions.

Table 16: Abbreviations of Events and Actions in State Tables

Table 17, part 1: State Table for Origin Z39.50 Association: Initialization Phase
State Event	Closed 0	Init sent 1	Acc recvd 2	Rsc recvd 3
Init req	Init PDU; (1)
Init resp PDU+		Init conf+; set opCnt = 0; :[conc] (5) else (4):
Init resp PDU-		Init conf-; (0)
Acc PDU		Acc ind; (2)
Acc resp			Acc resp PDU; (1)
Rsc PDU		Rsc ind; :[resp] (3) else (1):
Rsc resp				Rsc resp PDU; (1)

4.2.4 Protocol Errors
Any event not listed in the tables of section 4.2.3 is not valid and is considered to be a protocol error. With exceptions specified in section 4.3, incorrectly formatted APDUs or APDUs 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.

Additional conditions that may be treated as protocol errors are described in 4.4.2.2.

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 conformance requirements in 4.4.1. These requirements are elaborated in 4.4.2.

4.4.1 General Conformance Requirements
The system shall:

a) Act in the role of origin or target.
b) Support the Init, Search, and Present services. See 4.4.2.2.1.
c) Support the syntax in 4.1.
d) Support the Type-1 Query. See 4.4.2.2.2.
e) Support (at minimum) version 2 of the protocol.[Note: For minimum requirements beyond version 2, for a Z39.50 implementation to claim conformance to version 3, see Z39.50 Version 3 Baseline Requirements.]
f) Follow the procedures specified in sections 3, 4.1, 4.2, and 4.3.
g) Assign values to APDU data elements according to the procedures of sections 3 and 4.1.

4.4.2 Specific Conformance Requirements
4.4.2.1 provides a table of Z39.50 features for which 4.4.2.2 specifies conformance requirements. In particular, conformance requirements are described as they pertain to version 2 and version 3 respectively.

4.4.2.1 Z39.50 Features
The following table of Z39.50 features indicates the applicable protocol version (2 or 3), a reference to a description of the feature, and a reference to the section within 4.4.2.2 that describes conformance requirements for the feature. The "item" column is used by the sections within 4.4.2.2 to refer back to the table.

Table 23: Z39.50 Features, Protocol Version, and Conformance

4.4.2.2 Detailed Requirements

4.4.2.2.1 Init, Search, and Present Services (See items 1, 2 and 14 above.)
A system must support the Init, Search, and Present services.

This means that an origin must be capable of sending Init, Search, and Present requests and receiving the respective responses. A target must respond properly to Init, Search, and Present requests with respective responses.

An origin may indicate (via option bits) during initialization that it does not intend to utilize the Present service during the Z-association; this does not constitute non-conformance. If, however, an origin indicates that it does intend to utilize the Present service, and the target refuses, this does constitute non-conformance on the part of the target.

This requirement is independent of version.

4.4.2.2.2 Type-1 Query (See item 3 above.)
An origin must be capable of formulating a type-1 query within a Search request, and a target should expect to receive a type-1 query.

An origin or target may support other query types. If the origin fails to send a type-1 query during a Z-association, this does not constitute non-conformance on the part of the origin. If, however, the origin does send a type-1 query and the target responds with a diagnostic indicating "query type not supported" this does constitute non-conformance on the part of the target.

This requirement does not mean that any specific feature of the type-1 query must be supported. A target that receives a type-1 query that conforms to the type-1 query syntax but which includes a feature that it does not support must not treat this condition as a protocol error (but instead should return an appropriate diagnostic, however, that diagnostic must not indicate "query type not supported").

This requirement is independent of version.

4.4.2.2.3 Multiple attribute sets, Multiple data types for search term, Complex attribute values, result set restriction, and Proximity (See items 4, 5, 6, 7, and 8 above.)
For version 2, the origin may not use any of these features in a type-1 query. If target receives a type-1 query with any of these features, it may treat this condition as a protocol error.

For version 3, the origin may but is not required to use any of these features in a type-1 query. The target should expect type-1 queries to include any or all of these features, but is not required to support any of these features. If the target receives a type-1 query which includes any of these feature that it does not support, it must not treat this condition as a protocol error (but rather should return an appropriate diagnostic).

4.4.2.2.4 Query types 0, 2, 100, and 101 (See items 9 and 10 above.)
An origin is not required to support queries of any of these types. A target should expect to receive, but need not support queries of these types. If a target receives a query of one of these types that it does not support it must not treat this condition as a protocol error but instead should return a diagnostic indicating that the query type is not supported.

This requirement is independent of version.

4.4.2.2.5 Query Type-102 (See item 11 above.)
For version 2, an origin may not use the type-102 query. If a target receives a type-102 query it may treat this condition as a protocol error.

For version 3, an origin may, but need not support the type-102 query. A target should expect to receive, but need not support, type-102 queries; if it receives a type-102 query it must not treat this condition as a protocol error.

Note: Z39.50-1995 lists type-102 as a valid query type (for version 3) but does not include a definition.

4.4.2.2.6 Additional-search-information parameter in Search request or response; Other-information parameter in any request or response other than Scan, Sort, or Extended Services (See items 12 and 39 above.)
For version 2, a system may not use these parameters; if a system receives one of these parameters it may treat this condition as a protocol error.

For version 3, a system is never required to use any of these parameters. However, a system should expect to receive these parameters, but is not required to interpret or process the information contained within the any of these parameter.

4.4.2.2.7 Additional-ranges and Comp-spec parameters on Present request (See item 15 above.)
For version 2, the origin may not use these parameters. If the target receives one of these parameters it may treat this condition as a protocol error.

For version 3, the origin is not required to, but may use either of these parameters. The target should expect to receive, but need not support either of these parameters. If the target receives but does not support one of these parameters, it should not treat this condition as a protocol error (but instead should return an appropriate status value and/or diagnostic).

4.4.2.2.8 Max-segment-count, Max-segment-size, and Max-record-size parameters on Present request (See item 16 above.)
For version 2, as well as for version 3 when segmentation is not in effect, the origin may not use these parameters; if the target receives any of these parameters it may treat this condition as a protocol error.

For version 3:

• If level-1 segmentation is in effect:
  • The origin may but is not required to support Max-segment-count. The target should expect to receive, but need not support Max-segment-count. If the target receives but does not support Max-segment-count, it must not treat this condition as a protocol error (but instead should return an appropriate status value and/or diagnostic).
  • The origin may not use Max-segment-size or Max-record-size. If target receives either it may treat this condition as a protocol error.
• If level-2 segmentation is in effect:
  • The origin may but is not required to support any of these three parameters. The target should expect to receive, but need not support any of these parameters. If the target receives but does not support a parameter, it must not treat this condition as a protocol error (but instead should return an appropriate status value and/or diagnostic).

4.4.2.2.9 Diagnostic format (See items 17 and 18 above.)
For version 2, the target may send diagnostics in a Search or Present response using the default form only. If the origin receives a diagnostic which does not conform to the default form, it may treat this condition as a protocol error.

Note: This rule applies to Search and Present responses only. Responses other than Search or Present that include diagnostics are not affected.

For version 3, the target may send diagnostics using the default or external form. The origin should expect to receive diagnostics in either form.

4.4.2.2.10 Addinfo of default diagnostic format (See items 19 and 20 above.)
For version 2, when the target sends a diagnostic in a Search or Present response using the default form, the addinfo parameter must be of ASN.1 type VisibleString. If the origin receives a diagnostic that violates this rule, it may treat this condition as a protocol error.

For version 3 the addinfo parameter may be of either type VisibleString or InternationalString.

4.4.2.2.11 Multiple non-surrogates in Search or Present response (See item 21 above.)
For version 2, the target must not include multiple non-surrogate diagnostics in a Search or Present response; if it does so, the origin may treat this condition as a protocol error.

Note: This rule applies to Search and Present responses only. There are responses other than Search or Present that include diagnostics, and these are not affected.

For version 3, the target may (but is not required to) include multiple non-surrogate diagnostics in a Search or Present response and if it does, the origin must not treat this condition as a protocol error.

4.4.2.2.12 Segmentation (See items 22, 23, and 24 above.)
For version 2, as well as for version 3 when segmentation is not in effect, the target may not send a Segment request, and if it does, the origin may treat this condition as a protocol error.

For version 3, level-1 or level-2 segmentation may be negotiated, however neither the target not the origin is required to support segmentation.

4.4.2.2.13 Delete service, Trigger-resource-control service, Resource-report service, Sort service, Scan service, and Extended-Services service (See items 25, 30, 31, 34, 35, and 36 above.)
A system is not required to support any of these services. They are independently negotiable. If the target receives a request of one of these types and the respective service is not in effect, it may treat this condition as a protocol error.

This requirement is independent of version.

4.4.2.2.14 Access-control and Resource-control services (See items 27 and 29 above.)
A system is not required to support either of these services. They are independently negotiable. If the origin receives an Access-control or Resource-control request and the respective service is not in effect (or if the request occurs while the origin is awaiting an Init response and the origin has not proposed the respective option in the Init request), it may treat this condition as a protocol error.

This requirement is independent of version.

4.4.2.2.15 'failure-10' value of Delete-list-status on Delete response (See item 26 above.)
For version 2, the target may not return this value; if it does the origin may treat this condition as a protocol error.

For version 3, the target may return this value.

4.4.2.2.16 Security-challenge-response and Diagnostic in Access-control response (See item 28 above.)
For version 2, the origin must include in the Access-control response the parameter Security-challenge-response, and may not include a diagnostic. If the target receives an Access-control response that violates this rule it may treat this condition as a protocol error.

For version 3, the origin may include a diagnostic, and if so, the parameter securityChallengeResponse may be omitted.

4.4.2.2.17 Op-id parameter of Resource-report request (See item 32 above.)
For version 2, the origin may not use this parameter; if the target receives this parameter it may treat this condition as a protocol error.

For version 3, the origin may, but is not required to include this parameter. The target should expect to receive, but need not support the parameter. If the target receives but does not support this parameter, it should not treat this condition as a protocol error (but instead should return an appropriate status).

4.4.2.2.18 failure-5 and failure-6 Resource-report-status in Resource-report response (See item 33 above.)
For version 2, the target may not return either value for this status; if it does the origin may treat this condition as a protocol error.

For version 3, the target may return either value.

4.4.2.2.19 Close service (See item 37 above.)

For version 2, the Close service may not be used. If a system receives a Close request, it may treat this condition as a protocol error.

For version 3, a system must expect to receive a Close request, and must be capable of responding with a Close response. A system is not required to send a Close request.

4.4.2.2.20 Explain facility (See item 38 above.)
There are no conformance requirements pertaining to the Explain facility, either for version 2 or version 3. A system may choose to support or not support Explain.

Note that implementation of Explain requires, at minimum, support for searching the Explain database and for the Explain record syntax. This standard does not require support for searching any particular database or support for any particular record syntax.

4.4.2.2.21 Other-information parameter in Scan, Sort, and Extended Services request (See item 40 above.)
The parameter Other-information may occur in a Scan, Sort, or Extended Services request or response. A system should expect to receive this parameter, but is not required to interpret or process the information contained within the parameter.

This requirement is independent of version.

4.4.2.2.22 Concurrent Operations (See item 41 above.)
For version 2, as well as for version 3 when concurrent operations is not in effect, if an origin attempts to initiate concurrent operations (i.e. attempts to initiate an operation when an operation is already active), the target may treat this as a protocol error.

For version 3, a system may choose to support or not to support concurrent operations.

4.4.2.2.23 Named Result sets (See item 13 above.)
A system may choose to support or not support named result sets. If the target receives a Search request where the value of the parameter Result-set-id is other than 'default' and the target does not support named result sets, the target should not treat this condition as a protocol error but should instead return an appropriate diagnostic.

This requirement is independent of version.

4.4.2.2.24 InternationalString Definition (See item 42 above.)
For version 2, a value of a parameter of ASN.1 type InternationalString must conform to the VisibleString definition. A system which receives a value that violates this rule may treat this condition as a protocol error.

For version 3, a value of a parameter of ASN.1 type InternationalString must conform to the GeneralString definition. A system which receives a value that does not conform to the VisibleString definition (but does conform to the GeneralString definition) must not treat this condition as a protocol error.

4.4.2.2.25 Reference-id (See item 43 above.)
For both version 2 and version 3, an origin may choose to support or not support the Reference-id parameter; a target must support the Reference-id parameter. Note, however, for version 3, origin support of concurrent operations (see 4.4.2.2.23) implies support for the reference-id parameter.