This specification has been approved as Z39.50-1995 Amendment 3, October 1999.
This amendment designates option bit 15 for encapsulation, defined as follows.
- Encapsulation is negotiated during initialization. Option bit 15 is
designated. If the client sets option bit 15 in the Init request, then:
- The client proposes that "encapsulation be in effect" for the
z-association (or limited to the Init operation if version 2 is proposed; see rule 5 below).
- The Init request may also (but need not) include one or more PDUs
as described in (2).
- If the server also sets option bit 15, then encapsulation is in
effect for the Z-association (or limited to the Init operation, if version 2 is negotiated). In that case, if the Init request
had included encapsulated PDUs, the server's behavior (as concerns
the Init response) is as described below.
- If the server does not set option bit 15, encapsulation is not in
effect. (If the server
does not even recognize option bit 15, it will ignore it and not set the bit
in the response, as per the general rules for negotiation.) In this case if
the server includes information that appears to be encapsulated PDUs in the Init response, the client should not assume that the information is encapsulated PDUs, and this specification does not prescribe client behavior in this situation.
- If encapsulation is in effect, then within an operation-initiating PDU (referred to hereafter as the "base PDU"),
the client may include, within otherInfo (or, if the base PDU is Init, within the userInfo parameter using UserInfo-1 to simulate OtherInfo; see Implementor Agreement Use of Init Parameters for Negotiation and User Information), one or more PDUs, including any operation-initiating PDU (excluding Init), optionally followed by Close. These are referred to as "encapsulated PDUs".
The first encapsulated PDU is included in the otherInfo parameter of the base PDU (or in the userInfo parameter, if the base PDU is Init). The next encapsulated PDU is included in the otherInfo parameter of the first encapsulated PDU, and so on.
Each encapsulated PDU is included in otherInfo as CHOICE externallyDefinedInfo, where the oid for the external is 1.2.840.10003.2.1 (the oid for Z39.50 PDUs).
- This specification assumes only a single occurence (at most) of an encapsulated PDU within the base PDU, and only a single occurence (at most) of an encapsulated PDU within an encapsulated PDU (informally: arbitrary nesting is permitted, but multiple threads are not). When this is not the case, the prescribed behavior is not defined by this specification.
- The use of the otherInfo and/or userInfo parameter is specified in order to support encapsulation within version 2 or 3. In a future version of the protocol, there
might be explicit encapsulation parameters in certain PDUs.
- For version 2, encapsulation may be supported only within the Init operation. Thus, when version 2 is negotiated, encapsulation may also be negotiated, but for use only within Init.
- When the client includes encapsulated PDUs the intent is that the server
execute the PDUs serially in the order that they are nested (from shallowest to most deeply nested), and include PDU
responses similarly nested in the PDU response to the
base PDU, and formatted in the manner described in (2), that is, with each encapsulated PDU included in otherInfo as CHOICE externallyDefinedInfo, where the oid for the external is 1.2.840.10003.2.1.
- If encapsulation is in effect, the server may not simply ignore
encapsulated PDUs. The server may choose not to execute encapsulated
PDUs, but if so, must include in the response to the base PDU an
appropriate diagnostic (see 10), for example: "this specific sequence of PDUs is
- Based on pre-screening analysis, the server may decide to execute neither the base PDU nor any encapsulated PDUs, for example in the case where in the server's opinion the client intent was that if the server did not expect to be able to execute the full sequence of PDUs, then it should not attempt to execute any of them. Similarly, in this case the server should include in the response to the base PDU an appropriate diagnostic (see 10).
- If encapsulation is in effect, the server may choose to execute some but
not all of a sequence of nested PDUs. In that case it should not
execute any encapsulated PDU following one that it chose not to execute
(and similarly should include an appropriate diagnostic in the base-PDU
response, see 10). Thus if there are N encapsulated PDUs, the server will always
execute either none, or the first M PDUs (M less than or equal to N).
The server should also not execute any PDUs following a PDU that it
attempted to execute but execution failed.
- The server may use the General Diagnostic Container format to supply diagnostics in these cases described in 7, 8, and 9.
- Encapsulated PDUs do not initiate individual Z39.50 operations. From a
modelling perspective, Access-control and resource-control apply to
the operation initiated by the base PDU. However, as a practical matter, Access-control and
Resource-control formats may be developed to allow a server to indicate
to what specific encapsulated PDU the Access-control or Resource-control
Similarly, for trigger-resource-control: the client might send a
base PDU with several PDUs nested, and later send a
trigger-resource-control request. From a modelling perspective it
applies to the base PDU. But the request could actually be asking (based
on the report-id requested) "how far into the sequence are you?" and
subsequently the client might issue a second trigger request specific to the embedded
request, which (again, from an operation model perspective) would still
apply to the base PDU.
- Encapsulation is not intended to support segmentation.
There are distinct optimization objectives of encapsulation. Three examples are:
This amendment does not specify the intent of any specific
encapsulation sequences, however, a Z39.50 profile that specifies
encapsulation may provide guidance regarding the intent of the usage of
- Lookahead. Characterized by a Sort encapsulated within a
Search, allowing the server to optimize the search by knowing, a
priori, the desired sort order.
- Single-round-trip. Characterized by a Present encapsulated
within a Search, allowing the search and retrieval to be combined
into a single transaction.
- Stateless operation. Characterized by several PDUs nested within an Init, the last of which is Close.
- Sort encapsulated in a Search
- A profile might state the assumption that whenever a Sort is
encapsulated in a Search the intent is lookahead, and the profile
may recommend that if the server determines that if cannot create
a result set sorted as desired, then the it should not execute the
- Present encapsulated within a Search
- A profile might state the assumption that whenever a Present
is encapsulated in a Search the intent is single-round-trip.
- Present encapsulated in Sort encapsulated in Search
- A profile might state the assumption that whenever a Sort and
Present are encapsulated in a Search, the Sort is intended for
lookahead and the Present for single-round-trip.
- Delete encapsulated in Present encapsulated in Search
- A profile might state the assumption that whenever a Present
and Delete are encapsulated in a Search, the client is conveying
that it does not need the server to maintain a result set (thus
the delete is intended for lookahead, so the server may choose not
to create a real result set).
- Several PDUs, the last of which is Close, nested in Init
- A profile may state the assumption that whenever a sequence of PDUs, ending with Close, is nested in an Init, the intent is
to simulate statelessness.