Z39.50 Option Bits

Updated: February 11, 2000
All of the Z39.50 options represented by option bits will be listed here -- those listed in the text of the standard as well as additional options registered after publication of Z39.50-1995.
Option BitOptionDescriptionSource
0 Search See Note 1 Z39.50-1995
1 Present See Note 1 Z39.50-1995
2 Delete Result Set See Note 1 Z39.50-1995
3 Resource Report See Note 1 Z39.50-1995
4 Trigger Resource Control See Note 2 Z39.50-1995
5 Resource Control See Note 3 Z39.50-1995
6 Access Control See Note 3 Z39.50-1995
7 Scan See Note 1 Z39.50-1995
8 Sort See Note 1 Z39.50-1995
9 (unused) Z39.50-1995
10 Extended Services See Note 1 Z39.50-1995
11 Level 1 Segmentation See Note 4 Z39.50-1995
12 Level 2 Segmentation See Note 4 Z39.50-1995
13 Concurrent Operations See Note 5 Z39.50-1995
14 Named Result Sets See Note 6 Z39.50-1995
15 Encapsulation Z39.50-1995 Amendment 3: Z39.50 Encapsulation
16 resultCount parameter in Sort Response See Note 8 Z39.50-1995 Amendment 1: Add resultCount parameter to Sort Response
17 Negotiation Model See Note 9 Model for Z39.50 Negotiation During Initialization
18 Duplicate Detection See Note 1 Z39.50 Duplicate Detection Service
19 Query type 104 See Note 10 Z39.50-1995 Amendment 4: Query Type 104
Notes:
  1. For Z39.50 operations -- search, present, delete, resource-report, scan, sort, extended-services, duplicate detection -- the origin indicates whether it wishes to initiate operations of that type; if so, the target indicates whether it is willing to process an operation of that type. If the origin proposes 'not in effect' for a particular operation type, the target must also specify 'not in effect'.
  2. The origin may propose to submit Trigger-resource-control requests; if so, the target indicates whether it will accept Trigger-resource-control requests. If the origin proposes 'not in effect,' the target must also specify 'not in effect'. If the target specifies 'in effect' for Trigger-resource-control, but 'not in effect' for 'resource-control,' then the origin may use only the Cancel function of Trigger-resource-control.
    The target may indicate unwillingness to accept Trigger-resource-control requests even if it specifies 'in effect' for 'resource-control'.
    The target's indication of willingness to accept Trigger-resource-control requests does not imply that the target will take any action as a result of a Trigger-resource-control request.
  3. The origin indicates whether it wishes the target to invoke Resource-control and/or Access-control (i.e. send Resource-control and/or Access-control requests). The target specifies whether it plans to invoke Resource-control and/or Access-control.
    If the target specifies 'not in effect' for resource-control (or access-control) then it will not invoke resource-control (or access control) even if the origin has proposed 'in effect'.
    If the origin proposes 'not in effect' for resource-control, and the target indicates 'in effect' for resource-control, indicating that it is not willing to suppress Resource-control requests, and if indeed the origin cannot accept Resource-control requests, the origin should terminate the Z-association.
    If the origin proposes 'not in effect' for access-control, 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 a Z-association, then the target should reject the Z-association (by setting the parameter Result to 'reject,' and specifying 'in effect' for 'access-control').
    However, security may be invoked at different levels. In addition to authentication at the outset of a Z-association, security might be invoked to control access to a particular database, record, result-set, resource-report format, or use of an operation. Thus if the origin proposes 'not in effect' for access-control, and the target normally invokes security (other than at the Z-association level), the target need not necessarily reject the Z-association.
    The target might wish to invoke a security challenge during an Init operation to determine whether the origin is authorized to use a capability it has proposed. If the origin has proposed 'not in effect' for access-control, the target may simply refuse the use of that particular operation via the Options parameter.
    If the origin proposes 'not in effect' for access-control, and the target chooses to accept the Z-association, and if the origin subsequently initiates an action that would precipitate an Access-control request (for example, if the origin issues a Search specifying a database for which it has not yet established credentials), the target should suppress the Access-control request and instead respond with an error status indicating that a security challenge was required but could not be issued.
  4. The origin proposes one of the following:
    • "no segmentation", by specifying 'not in effect' for both level 1 and level 2 segmentation;
    • "level 1 segmentation", by specifying 'in effect' for level 1 and 'not in effect' for level 2 segmentation; or
    • "level 2 segmentation", by specifying 'in effect' for level 2 segmentation.
    If the origin proposes 'in effect' for level 2 segmentation then it may also propose 'in effect' for level 1 segmentation to indicate that if the target is unable to support level 2 segmentation, the origin wishes level 1 segmentation to be in effect.
    "segmentation" is said to be 'in effect' if either level 1 or level 2 segmentation is in effect.
    Segmentation may be in effect only when version 3 is in force.
    The target response indicates which, if either, form of segmentation it intends to perform. If the target specifies neither level 1 nor level 2 then 'no segmentation' is in effect, regardless or what the origin has proposed.
    If the target specifies level 1 (but not level 2) segmentation, it will not perform level 2 segmentation, and the origin must be prepared to accept level 1 segmentation, regardless of what the origin has proposed.
    If the target specifies level 2 segmentation, the origin must be prepared to accept level 2 segmentation regardless of what it has proposed (the target value for level 1 should be 'not in effect').
    When 'no segmentation' is in effect, the target response to a Present request must consist of a single message (a single "segment", i.e. a Present response only, with no intervening Segment requests), containing an integral number of records. When 'Level 1 segmentation' is in effect the target may respond to a Present request with multiple segments (i.e. a Present response, with possibly one or more intervening Segment requests); each must contain an integral number of records. When 'Level 2 segmentation' is in effect the target may respond to a Present request with multiple segments, and individual records may span segments.
    Segmentation procedures are detailed in section 3.3 of Z39.50-1995.
  5. The origin may propose to initiate concurrent operations; if so, the target indicates whether it will accept concurrent operations. If the origin proposes 'not in effect,' the target must also specify 'not in effect'.
  6. The origin may propose to use named-result sets (i.e. to specify result set names other than "default" as the value of Result-set-name within a Search request); if so, the target specifies whether it will support named-result-sets. If the origin proposes 'not in effect,' the target must also specify 'not in effect'.
  7. (Note 7 deleted.)
  8. Rules for negotiation of resultCount parameter in Sort Response are as follows:
    • If the origin sets bit 8 (proposing that it wishes to initiate Sort operations) then it may also sets bit 16 indicating that it supports the resultCount parameter in the response.
    • The origin must not set bit 16 if it does not set bit 8.
    • If the origin does not set bit 16, then the target must not set bit 16 under any circumstance.
    • If the origin sets bit 8 and not bit 16, and if the target sets bit 8, accepting the proposal that Sort operations may be submitted (the target must not set bit 16 as noted above), the target must not include the resultCount parameter in a Sort response.
    • If the origin sets bits 8 and 16, and the target also sets bits 8 and 16, the target may include the resultCount parameter in Sort responses. However, the target, by setting bit 16, does not obligate itself to supplying the resultCount parameter.
    • If the origin sets bits 8 and 16, and the target sets bit 8 but not bit 16, the target indicates that it will accept Sort requests, but will not include the resultCount parameter in a Sort response.
  9. When the origin sets the "negotiation model" option bit, it signifies adherence to the negotiation model. If the origin and target both set the option bit (in the InitRequest and Response respectively) both may assume that negotiation is carried out in accordance with the model.

    If the origin sets this option bit and the target does not, the origin should not assume that negotiation has been carried out in accordance with the model.

    If the origin does not set this option bit, but the target requires that negotiation be carried out in accordance with this model, the target may reject the z-association and supply diagnostic 1055: "negotiation option required".

    The reason an option bit corresponding to the negotiation model is neccessary is that otherwise a target might operate according to some implicit model for information exchange during initialization. For example, the target may echo in the InitResponse all of the information supplied in the InitRequest. In such a case, the origin may be falsely led to believe that negotiation has been carried out.

  10. When the origin sets the "query type 104" bit it proposes to submit queries of type 104. If the target also sets this bit, then it will accept queries of type 104 -- this means the target will not consider it to be a protocol error if the origin submits a type 104 query; it does not mean that the target agrees to support any specific external query-definition.
Library of Congress