[Table of Contents | Previous Section | Next Section]

Appendix 9 USR: User Information Formats (Normative)

User Information formats are defined for the following: userInformationField in the Init and InitResponse APDUs, additionalSearchInfo in the Search and SearchResponse APDUs, and otherInfo in all APDUs.

This standard defines and registers the userInformation format SearchResult-1, defined for use within a SearchResponse APDU. The following object identifier is assigned:

SearchResult-1

{Z39-50-userInfoFormat 1} (See USR.1)

User Information formats may include negotiation records, defined for the parameters userInformationField and otherInfo in the Init and InitResponse APDUs. These are described in USR.2.

USR.1 User Information Format SearchResult-1
SearchResult-1 is for use primarily within the AdditionalSearchInformation parameter in the Search Response. The format allows the target to provide information per query component (the whole query or a sub-query, possibly restricted to a subset of the specified databases). The target may also create and provide access to a result set for each query component.

This format may also be used as a Resource Report format, within the ResourceReport parameter of the resource-control request, to allow the target to report on the progress of the search. However, when used in this manner, the target should not create a result set for a query component unless processing for that component is complete.

UserInfoFormat-searchResult-1

[Link to UserInfoFormat-searchResult-1]

USR.2 Negotiation Records
Negotiation records are defined for use within the parameters otherInfo (version 3 only) and userInformationField in the Init and InitResponse APDUs. No negotiation records are defined by this standard. Publicly defined negotiation record definitions are available from the Z39.50 Maintenance Agency, at http://www.loc.gov/z3950/agency/defns/oids.html#15

[See Model for Z39.50 Negotiation During Initialization]

In general, a negotiation record is defined for use as follows: the origin includes the negotiation record within the Init APDU (identified by its OID) to propose that some condition be in effect for the Z-association. The target may (but is not obligated to) respond to the proposal, using the same negotiation record format, and the target's response, if any, indicates whether the proposal is accepted, or may indicate a counter-proposal, which will then be in effect for the Z-association. Thus a negotiation record definition should include the format of both the origin proposal and the target response.

The following rules and guidelines apply to the definition and use of negotiation records: A negotiation record should be defined for the purpose of negotiating a single item of information, except in the following case:

• negotiation of related items may be defined for the same negotiated record, where it is not practical to separate their negotiation, for example, because of interdependence among the negotiation of these items. If the origin does not propose negotiation (i.e. does not submit a negotiation record) for a given item, then it is considered that "no negotiation takes place" for that item.
• If the origin does propose negotiation for an item, but the target does not respond (i.e. does not include a corresponding negotiation record), similarly, no negotiation takes place for that item.
• A negotiation record definition must not specify behavior governing the condition where no negotiation takes place. (If no negotiation takes place, neither origin nor target can be assumed to know any rules associated with the negotiation record definition.)
• If the target does not recognize the oid for a negotiation record submitted by the origin, it should ignore it (and not return a negotiation record of that type).
  Note: When the target does not recognize the oid of a negotiation record, the target cannot be certain that it is indeed a negotiation record. Therefore, care should be taken in general in defining user information formats, to ensure that if the target does not recognize an oid it may ignore it with impunity.
• If the origin does not submit a negotiation record of a particular type in the Init request, then the target is not to include a negotiation record of that type in the response.
• If multiple negotiation records are included in an Init request, there is no significance to their order, and there is no relationship between them: for example, if the origin includes two negotiation records, and the target does not recognize the first (in which case negotiation fails for the first) negotiation may still succeed for the second.