[73] in Information Retrieval
["Mark H. Needleman" : ]
daemon@ATHENA.MIT.EDU (Tim McGovern)
Tue Mar 10 11:49:38 1992
Date: Tue, 10 Mar 92 11:53:39 EST
From: tjm@Eagle.MIT.EDU (Tim McGovern)
To: elibdev@MIT.EDU
------- Forwarded Message
Date: Tue, 10 Mar 1992 06:56:24 -0800
Reply-To: "Z39.50 Implementors Workshop" <Z3950IW%NERVM.BITNET@uga.cc.uga.edu>
Sender: "Z39.50 Implementors Workshop" <Z3950IW%NERVM.BITNET@uga.cc.uga.edu>
From: "Mark H. Needleman" <mhn@STUBBS.UCOP.EDU>
X-To: Z3950IW%NERVM.BITNET@uccvma.ucop.edu
To: Multiple recipients of list Z3950IW <Z3950IW%NERVM.BITNET@uga.cc.uga.edu>
Clifford asked me to post the following for discussion.
Mark Needleman
Implementation of Z39.50 in a TCP/IP Environment
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.
<question: it would be possible to provide a form of negotiation
for record syntaxes by permitting the server to generate a
resource control message containing a list of supported record
transfer syntaxes, and then having the client reply with the
subset of these syntaxes that are supported within a SEARCH or
PRESENT operation. Is this a desirable extension?>
Acknowledgements
(to be added)
References
(to be added)
------- End of Forwarded Message
