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.
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:
SEQUENCE{That is, 'category' is omitted and the CHOICE for 'information' is 'externallyDefinedInfo' .
externallyDefinedInfo [4] IMPLICIT EXTERNAL}
An example of a negotiation record is character set/language negotiation.
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.
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.
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
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.
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