RFC 1729 (rfc1729) - Page 3 of 8

Using the Z39

RFC 1729      Using the Z39.50 in the Internet Environment December 1994


   Except where otherwise noted, the version of Z39.50 discussed here is
   ANSI/NISO Z39.50-1992, sometimes called Z39.50 Version 2 (the
   obsolete original version is referred to as Z39.50-1988 or Z39.50
   Version 1). The approach defined should also be applicable, perhaps
   with some minor changes, to future versions of the Z39.50 protocol,
   and specifically to Version 3 which is currently under development.
   This document will probably be updated to address new versions of the
   base Z39.50 protocol as they become stable.

Encoding

   The Z39.50 standard specifies its application protocol data units
   (APDUs) in Abstract Syntax Notation One (ASN.1) [10]. 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.

   The standard Basic Encoding Rules (BER) [11] are applied to the ASN.1
   structures defined by the Z39.50 protocol to produce a byte stream
   that can be transmitted across a TCP/IP connection. The only
   restriction on the use of BER to produce this byte stream is that
   direct, rather than indirect, references must be used for EXTERNAL
   objects. This is necessary because there is no presentation context
   in the TCP/IP environment to support indirect reference. A Z39.50
   implementation developed according to this specification and running
   over TCP/IP should produce a valid byte stream according to the
   Z39.50 standard, in the sense that the same byte stream could be
   passed to an OSI implementation. However, not all byte streams that
   can be produced by applying BER to the APDUs specified in the Z39.50
   standard in an OSI environment will be legitimate under this
   specification for the TCP/IP environment; this specification defines
   a subset of the possible byte streams valid in a pure OSI environment
   which excludes those using indirect reference for EXTERNAL objects.

   All other BER features should be tolerated by Z39.50 implementations
   running over TCP/IP, including the ability to accept indefinite
   length encodings, although it is preferable that implementations do
   not generate such encodings since they have caused problems for some
   ASN.1/BER parsers.  It should also be noted that at least to the best
   of the author's knowledge, there are no implementations at present
   that use ASN.1/BER representations of floating point numbers;
   instead, integers with scaling factors have been used for these
   purposes. It should also be noted that Z39.50 version 2 does not
   really address character set encoding issues; these questions, and
   their interactions with ASN.1/BER support for multiple character
   sets, are under active discussion as part of the effort to develop
   Z39.50 version 3.




Lynch