Model for Z39.50 Negotiation During Initialization

January 29, 1999

1. Introduction

Negotiation between a Z39.50 origin and target may be carried out during initialization of a z-association, via the InitRequest and InitResponse. Negotiation of protocol version, message size, and options (via option bits) is supported by explicit parameters within the Init messages.

Additional negotiation may be carried out via the use of the otherInfo parameter in the InitRequest and InitResponse (or by simulation of otherInfo using the userInformationField; see implementor agreement Use of Init Parameters for Negotiation and User Information ).

This model pertains to the use of otherInfo in an InitRequest and InitResponse for purposes of negotiation.

2. Negotiation Records

The otherInfo parameter is defined as:
OtherInformation	 ::= [201] IMPLICIT SEQUENCE OF SEQUENCE{
	category  			[1]   IMPLICIT InfoCategory OPTIONAL,
	information  			CHOICE{
		characterInfo			[2] IMPLICIT InternationalString,
		binaryInfo			[3] IMPLICIT OCTET STRING,
		externallyDefinedInfo		[4] IMPLICIT EXTERNAL,
		oid				[5] IMPLICIT OBJECT IDENTIFIER}}
--
	InfoCategory ::= SEQUENCE{
			categoryTypeId	[1] 	IMPLICIT OBJECT IDENTIFIER OPTIONAL,
			categoryValue	[2] 	IMPLICIT INTEGER}

Thus it is one or more occurrences of the following structure:
  SEQUENCE{
	category  			[1]   IMPLICIT InfoCategory OPTIONAL,
	information  			CHOICE{
		characterInfo			[2] IMPLICIT InternationalString,
		binaryInfo			[3] IMPLICIT OCTET STRING,
		externallyDefinedInfo		[4] IMPLICIT EXTERNAL,
		oid				[5] IMPLICIT OBJECT IDENTIFIER}}
Refer to each instance of this structure as an otherInfo unit.

Refer to an otherInfo unit in an InitRequest or InitResponse as a Negotiation Record, if the following two conditions are met:

  1. It conforms to the following sub-structure:
    SEQUENCE{
    externallyDefinedInfo [4] IMPLICIT EXTERNAL}
    That is, 'category' is omitted and the CHOICE for 'information' is 'externallyDefinedInfo' .

  2. The definition explicitly states that it is to be used as a negotiation record as defined in this model.
The InitRequest and Response otherInfo parameter may include one or more otherInfo units, some of which may be negotiation records. This model describes the exchange of negotiation records only. OtherInfo units that are not negotiation records (as defined in this model), may be interspersed arbitrarily among the negotiation records without violating this model.

An example of a negotiation record is character set/language negotiation.

3. Rules Pertaining to the Use of Negotiation Records

  1. When the origin includes a negotiation record in the InitRequest, if the target does not recognize the negotiation record type (i.e. its object identifier) it should ignore the record, and should not include a negotiation record of that type in the InitResponse.
  2. A target should never include a negotiation record in an InitResponse unless the origin has included a negotiation record of that type in the InitRequest. See, however, "Target-Mandated Negotiation" below.
  3. When the origin includes a negotiation record of a particular type in the InitRequest, negotiation (as defined in the definition of the negotiation record) is considered to be carried out if the target also includes a negotiation record of that type in the InitResponse. Note that "carried out" does not necessarily mean "successful".
  4. If the origin includes a negotiation record of a particular type in the InitRequest and the target does not include a corresponding negotiation record in the InitResponse, then no negotiation (as defined in the definition of the negotiation record) is assumed to take place; for practical purposes, the origin may simply assume that the target does not recognize the negotiation record.
  5. If the target includes an OtherInfo unit in the InitResponse that the origin does not recognize, the origin should ignore it.

4. Target-Mandated Negotiation

This model does not support target-initiated negotiation. Thus, as stated in rule 2 above, the target should not supply in the InitResponse a negotiation record of a type that the origin has not supplied in the request, because there is no way the target can determine whether the origin even recognized the negotiation record.

However there may be instances where the target is not willing to enter into an z-association without certain negotiable rules established, and where the target cannot effect the necessary negotiation because the origin has not supplied the appropriate negotiation record in the InitRequest. In this case, it is recommended that the target reject the z-association with bib-1 diagnostic 1054: required negotiation record not included indicating the object identifier of the required negotiation record.

There may also be instances where the target cannot ascertain whether the origin even supports this model. 5.2 below (Dynamic Adherence) addresses this.

5. Adherence to this Model

5.1 Static Adherence

As stated in section 2, in order for this model to be effectively employed, when a negotiation record is intended to be used in accordance with this model, its definition should state that it is intended to be used in accordance with this model.

5.2 Dynamic Adherence

Z39.50 option bit 17 is assigned to correspond to this negotiation model.

When the origin sets this option bit, it signifies adherence to the 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 this 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 this 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 bib-1 diagnostic 1055: negotiation option required.

The reason an option bit is neccessary is that a target might operate according to some other (perhaps implicit) model for information exchange during initialization. For example, suppose a target routinely echoes, in the InitResponse, all of the information supplied in the InitRequest. In the absense of an explicit mechanism to determine whether or not this model is in effect, the origin may be falsely led to believe that negotiation has been carried out.

6. Development and Registration of Negotiation Records

6.1 Negotiating Behavior

This model is intended to support negotiation of behavior elements, where a behavior element is identified by an object identifier that correspond to a definition of the behavior. For example, a behavior element definition might state:that its object identifier "may be used within a negotiation record such as BehaviorNegotiation-1 to negotiate the rules specified in section x.y.z of profile xyz" where definition BehaviorNegotiation-1 is a a (hypothetical) negotiation record that might be defined as follows:
BehaviorNegotiation-1
{Z39-50-negotiationRecord negotiateBehaviorElements (x)} DEFINITIONS ::=
BEGIN
NegotiateBehaviorElements ::= CHOICE{
   proposal [1]   IMPLICIT SEQUENCE OF OBJECT IDENTIFIERS,
   response [2]   IMPLICIT SEQUENCE OF OBJECT IDENTIFIERS
        -- The target response must be a subset of the set proposed
        -- by the origin. if the target requires a particular behavior
        -- element to be in effect that the origin has not supplied,
        -- then the target should reject the Init, with bib-1 diagnostic
        -- 1054 indicating the oid(s) of the required
        -- behavior element.
                          }
END

6.1.1 Registration of Behavior Elements

The Z39.50 Maintenance Agency will not attempt to register all behavior elements. As aluded to in the example in 6.1 above, it is assumed that there will be behavior elements defined within profiles. The Maintenance Agency will assign an object identifier to a profile, upon request by the editor of the profile, who is then the registration authority for that object identifier and may assign object identifiers subordinate to that object identifier, defining behavior elements. Those definitions might refer to sections in the profile that describe levels of conformance or functional units for the profile.

If there is a need to define behavior elements outside of profiles, they will be registered by the Z39.50 Maintenance Agency (or they may be registered privately by implementors). For example, if there is a need to negotiate that a particular Implementor Agreement be in effect, it will be assigned an object identifier.

6.2 Negotiating Support

The following hypothetical example of a negotiation record illustrates negotiation of support for specific functionality.

SupportNegotiation-1
{Z39-50-negotiationRecord negotiateBehaviorElements (y)} DEFINITIONS ::=
BEGIN
NegotiateSupport ::= CHOICE{
   proposal [1]   IMPLICIT SEQUENCE OF DatabaseTriple,
   response [2]   IMPLICIT SEQUENCE OF DatabaseTriple}
-- Origin proposes a set of triples, and target responds with
-- a set of triples that will be supported. Target set
-- need not be a subset of the origin set, nor need it be
-- exhaustive (absence of a database, or an attribute set id
-- or record syntax for a given database, does not necessarily
-- mean that it will not be supported).

DatabaseTriple ::=  SEQUENCE OF SEQUENCE{
           databaseName    [1] IMPLICIT InternationalString,
           attributeSets   [2] IMPLICIT SEQUENCE OF OBJECT IDENTIFIER,
           recordSyntaxes  [3] IMPLICIT SEQUENCE OF OBJECT IDENTIFIER}
END
In this hypothetical example the origin proposes a set of databases available for searching, and for each, a list of proposed attribute set ids and a list of proposed record syntaxes. The target responds with a list of databases, and for each, a list of attribute set ids and a list of record syntaxes.that will be supported.

In this particular example the target list may or may not be a subset of the origin list. Alternatively, a different negotiation definition might mandate that the target explicitly respond -- for each database, attribute set, and record syntax -- whether or not it will be supported.

Note that specific behavior is not negotiated by this (example) negotiation record. If support, for example, for a particular record syntax (for a database) is negotiated, that does not mean that the target will support that syntax for every record (in the database).


Library of Congress