Clifford A. Lynch March 8, 1992 D R A F T (for discussion at 3/12 ZIT meeting) Note to ZIT members: there are some issues raised at the end of this document that we should discuss at our meeting. Note to ZIG members not part of the ZIT: your comments are also invited, particularly on the issues raised at the end of this document. Please send them to me or post them to the list. Thank you. Introduction This document defines the means by which members of the CNI Z39.50 Interoperability Testbed (the "ZIT") are running the American National Standard Computer-to-Computer Information Retrieval Protocol Z39.50-1992 (reference) over TCP/IP. Z39.50 is an OSI application-layer protocol that was designed to assume the presence of the OSI Application Common Service Element (ACSE) and the services of the OSI presentation layer. For various reasons, the ZIT concluded that the approach of layering all of the higher-level OSI protocols over TCP/IP (as used, for example, in the ISO Development Environment software) was inappropriate; these reasons included the size of the resulting implementation, and the lack of availability of ISODE-type software for the full range of computing environments used by ZIT members, as well as a general desire to reduce complexity in order to get implementations running quickly. Z39.50 implementors should also be aware that the ZIT has defined some extensions to the ASN.1 in the Z39.50-1992 standard (which hopefully will be added to a future revision of the Z39.50 standard); these changes are documented in (reference). However, the methods described here apply both to the ASN.1 definition given in Z39.50 and the extended ASN.1 definition being used by the ZIT. The topics covered here are the encoding of Z39.50 messages over a TCP connection; how to contact the Z39.50 service on a server host; the remapping of various lower-layer OSI services used by Z39.50 to TCP services; and the handling of various presentation contexts used by Z39.50 during a connection in a TCP environment without a presentation layer. Encoding The Z39.50 standard specifies the Application protocol data units (APDUs) in ASN.1; these APDUs include EXTERNAL references to other ASN.1 and non-ASN.1 objects such as those defining record transfer syntaxes to be used in a given application association. Standard Basic Encoding Rules (reference) are applied to the ASN.1 Structures defined by the Z39.50 protocol in order to produce a data stream that can be transmitted across a TCP/IP connection. The only restriction in the use of the BER to produce this data stream is that direct, rather than indirect, reference must be used for EXTERNALs. This is necessary because there is no presentation context to support indirect reference. Implementors using ASN.1 compilers might wish to note the following possible change to the Z39.50 ASN.1 which could then be employed to force the use of direct reference. Note that this does not change the results of using the existing Z39.50 ASN.1 definition in a context where BER has been adjusted to always generate direct references; however, it may be useful in eliminating ambiguity in specific implementations. This change was suggested by Terry Sullivan of the Florida State Center for Library Automation. Replace the EXTERNAL ASN.1 type in the Z39.50 ASN.1 with the actual definition: UNIVERSAL 8 IMPLICIT SEQUENCE ( direct-reference OBJECT IDENTIFIER OPTIONAL, indirect-reference INTEGER OPTIONAL, data-value-descriptor ObjectDescriptor OPTIONAL, encoding CHOICE ( single-asn1-type 0 ANY, octet-aligned 1 IMPLICIT OCTET STRING, arbitrary 2 IMPLICIT BIT STRING ) ) Note that all other BER features should be supported, including the ability to accept indefinite length descriptors, although it is preferable that implementations do not generate these. Connection The Z39.50 service on a host has been assigned TCP Port 210 under the IAB/IETF Assigned Numbers (reference). To initiate a Z39.50 session with a server in a TCP/IP environment, a client opens a TCP connection to port 210, and then transmits an INIT APDU using the BER as described above. Service Mappings The IR-ABORT service is mapped to a TCP abort; the IR-CLOSE service is mapped to a TCP close. Contexts At the point when the TCP connection is established on port 210, client and server should assume that the following context is in place: The ASN.1 definitions for the Z39.50 APDUs, along with the transfer syntax defined by applying the BER to these APDUs. See Appendix A and B of the Z39.50 Standard. In addition, the following ObjectIds are assumed to be know to both partners in the association, along with the obvious (BER applied to ASN.1) transfer syntax: attribute set bib-1 diagnostic set bib-1 resource report format bib-1 The client may request a particular record syntax for database records through the preferred record syntax parameter of the SEARCH and PRESENT APDUs; the actual response APDUs containing database records include explicit objectIds defining the record syntax being returned from the server. At present, there are a number of record syntaxes (both ASN.1 and non-ASN.1 - for example US MARC) registered either by the Z39.50 standard, by the Z39.50 Implementor's group, or by the ZIT. There is currently no way for client and server, in the TCP/IP environment, to negotiate a subset of these record syntaxes which are mutually supported by client and server, or to agree to common client and server use of other attribute sets, diagnostic sets, or resource report formats; of course, either participant in an association can reference such a thing by objectId in an APDU, but there is no guarantee that the other side of the association will be able to understand it. As a general rule, a server should provide records in the record syntax indicated in the preferred record syntax parameter of the SEARCH or PRESENT APDUs, and simply return the diagnostic NO RECORD SYNTAX AVAILABLE if it cannot provide records in this preferred record syntax. A diagnostic should be added for UNSUPPORTED ATTRIBUTE SET. Diagnostic set BIB-1 and resource report format BIB-1 should always be used unless there is prior agreement between a client and server to use something else. Acknowledgements (to be added) References (to be added)