rfc1729.txt

RFC 的详细文档！

Network Working Group                                           C. Lynch
Request for Comments: 1729                      University of California
Category: Informational                          Office of the President
                                                           December 1994


            Using the Z39.50 Information Retrieval Protocol
                      in the Internet Environment

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Summary

   This memo describes an approach to the implementation of the
   ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the
   TCP/IP environment which is currently in wide use by the Z39.50
   implementor community.

Introduction

   Z39.50 is a US national standard defining a protocol for computer-
   to-computer information retrieval that was first adopted in 1988 [1]
   and extensively revised in 1992 [2]. It was developed by the National
   Information Standards Organization (NISO), an ANSI-accredited
   standards development body that serves the publishing, library, and
   information services communities. The closely related international
   standard, ISO 10162 (service definition) [3] and 10163 (protocol)
   [4], colloquially known as Search and Retrieve or SR, reached full
   International Standard (IS) status in 1991. Work is ongoing within
   ISO Technical Committee 46 Working Group 4 Subgroup 4 to progress
   various extensions to SR through the international standards process.
   The international standard is essentially a compatible subset of the
   current US Z39.50-1992 standard. Z39.50 is an applications layer
   protocol within the OSI reference model, which assumes the presence
   of lower-level OSI services (in particular, the presentation layer
   [5]) and of the OSI Association Control Service Element (ACSE) [6]
   within the application layer.

   Many institutions implementing this protocol chose, for various
   reasons, to layer the protocol directly over TCP/IP rather than to
   implement it in an OSI environment or to use the existing techniques
   that provide full OSI services at and above the OSI Transport layer
   on top of TCP connections (as defined in RFC 1006 [7] and
   implemented, for example, in the ISO Development Environment



Lynch                                                           [Page 1]

RFC 1729      Using the Z39.50 in the Internet Environment December 1994


   software). These reasons included concerns about the size and
   complexity of OSI implementations, the lack of availability of mature
   OSI software for the full range of computing environments in use at
   these institutions, and the perception of relative instability of the
   architectural structures within the OSI applications layer (as
   opposed to specific application layer protocols such as Z39.50
   itself). Most importantly, some of these institutions were concerned
   that the complexity introduced by the OSI upper layers would outweigh
   the relatively meager return in functionality that they were likely
   to gain. Thus, for better or worse, the decision was taken to
   implement the Z39.50 protocol directly on top of TCP (with the
   understanding that this decision might be revisited at some point in
   the future).

   During 1991-1993, a group of implementing institutions agreed to
   participate in the Z39.50 Interoperability Testbed project (sometimes
   referred to by the acronym "ZIT") under the auspices of the Coalition
   for Networked Information (CNI). Their primary objective was to
   encourage the development of many interoperable Z39.50
   implementations running over TCP/IP on the Internet. By mid-1993, a
   number of independent Z39.50 implementations were operational and
   able to interoperate across the Internet.

   The Library of Congress, in its role as the Z39.50 Maintenance Agency
   for NISO, maintains a registry of the implementors [8], which
   includes members of the Z39.50 interoperability testbed.

   This document describes implementation decisions by current
   implementors of Z39.50 in the Internet environment. These have been
   proven within the ZIT project and are being used by most of the
   members of the Z39.50 Implementors' Group (ZIG), an informal group
   that meets quarterly to discuss implementation and interoperability
   issues and to develop extensions to the Z39.50 protocol targeted for
   inclusion in future versions of the standard. Intended as a guide for
   other implementors who seek to develop interoperable Z39.50
   implementations running over TCP/IP, this document focuses on issues
   related to TCP/IP, and it does not address other potential
   interoperability problems or agreements that have been reached among
   the implementors to address these problems. It does include a few
   notes about extensions to the existing Version 2 protocol that are
   being used in the implementor community which have interoperability
   implications.  Potential implementors of Z39.50 should subscribe to
   the Z3950IW LISTSERV [9] to obtain information specific to the Z39.50
   protocol and extensions under development as well as details of
   current implementations.






Lynch                                                           [Page 2]

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                                                           [Page 3]

RFC 1729      Using the Z39.50 in the Internet Environment December 1994


Connection

   In the Internet environment, TCP Port 210 has been assigned to Z39.50
   by the Internet Assigned Numbers Authority [12]. To initiate a Z39.50
   connection to a server in the TCP/IP environment, a client simply
   opens a TCP connection to port 210 on the server and then, as soon as
   the TCP connection is established, transmits a Z39.50 INIT APDU using
   the BER encoding of that INIT APDU as described above.

   Implementors should be aware that there is a substantial installed
   base of implementations of the Wide Area Information Server (WAIS)
   system. The original versions of this software employed Z39.50
   Version 1 with some extensions. Z39.50 Version 1 did not use BER
   encoding and Z39.50 Version 1 INIT APDUs look very different from the
   INIT APDUs of Z39.50 Version 2.  Implementations of Z39.50 should at
   least be prepared to reject gracefully WAIS-type INIT APDUs. Some
   implementations recognize such INIT APDUs and revert to the Z39.50
   Version 1 variant used in WAIS upon encountering them, thus providing
   backwards compatibility with the existing base of WAIS clients and;
   the usual means of checking for a WAIS, as opposed to Z39.50 Version
   2, client is to see if the first byte sent on the connection is an
   ASCII zero, which indicates a WAIS client. (In version 1 of WAIS,
   bytes 0-9 of the first PDU contain an ASCII packet length; the lower
   case ASCII string "wais" appears starting at byte 12.) Work is
   currently underway to specify a WAIS profile for use with Z39.50
   version 2 [13]; it is expected that this will be issued as a Z39.50
   Applications Profile through the NIST OIW Library Automation Special
   Interest Group. This profile is expected to be compatible with the
   layering defined in this RFC.

Service Mappings

   The Z39.50 standard maps Z39.50 services onto a variety of
   association control and presentation layer services. Connection
   establishment has already been discussed. The other two association
   control services that are relevant to Z39.50 are ABORT and RELEASE.
   The mapping of the RELEASE service to a standard TCP CLOSE is
   straightforward. The Z39.50 protocol itself does not, in the current
   version, include a Z39.50 CLOSE APDU. When the client has completed
   its interaction with the server, it calls the IR-RELEASE service,
   which is directly mapped to association control's orderly association
   release. In the TCP/IP environment, the client should simply initiate
   a TCP CLOSE. The mapping for association abort is more complex,
   partially because some TCP/IP implementations cannot distinguish a
   TCP reset from the other side of the connection from other events. To
   accomplish an abort (that is, a mapping of the IR-ABORT service in
   the Z39.50 protocol) in the TCP/IP environment, client or server need
   only terminate the TCP connection either via TCP ABORT or TCP CLOSE.



Lynch                                                           [Page 4]