As per Relevance of the word environment, we have this rfc below:
Network Working Group C.
Request for Comments: 1729 University of
Category: Informational Office of the
December 1994
Using the Z39.50 Information Retrieval
in the Internet
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This memo describes an approach to the implementation of
ANSI/NISO Z39.50-1992 Standard for Information Retrieval in
TCP/IP environment which is currently in wide use by the Z39.50
implementor community
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
Information Standards Organization (NISO), an ANSI-
standards development body that serves the publishing, library,
information services communities. The closely related
standard, ISO 10162 (service definition) [3] and 10163 (protocol
[4], colloquially known as Search and Retrieve or SR, reached
International Standard (IS) status in 1991. Work is ongoing
ISO Technical Committee 46 Working Group 4 Subgroup 4 to
various extensions to SR through the international standards process
The international standard is essentially a compatible subset of
current US Z39.50-1992 standard. Z39.50 is an applications
protocol within the OSI reference model, which assumes the
of lower-level OSI services (in particular, the presentation
[5]) and of the OSI Association Control Service Element (ACSE) [6]
within the application layer
Many institutions implementing this protocol chose, for
reasons, to layer the protocol directly over TCP/IP rather than
implement it in an OSI environment or to use the existing
that provide full OSI services at and above the OSI Transport
on top of TCP connections (as defined in RFC 1006 [7]
implemented, for example, in the ISO Development
Lynch [Page 1]
RFC 1729 Using the Z39.50 in the Internet Environment December 1994
software). These reasons included concerns about the size
complexity of OSI implementations, the lack of availability of
OSI software for the full range of computing environments in use
these institutions, and the perception of relative instability of
architectural structures within the OSI applications layer (
opposed to specific application layer protocols such as Z39.50
itself). Most importantly, some of these institutions were
that the complexity introduced by the OSI upper layers would
the relatively meager return in functionality that they were
to gain. Thus, for better or worse, the decision was taken
implement the Z39.50 protocol directly on top of TCP (with
understanding that this decision might be revisited at some point
the future).
During 1991-1993, a group of implementing institutions agreed
participate in the Z39.50 Interoperability Testbed project (
referred to by the acronym "ZIT") under the auspices of the
for Networked Information (CNI). Their primary objective was
encourage the development of many interoperable Z39.50
implementations running over TCP/IP on the Internet. By mid-1993,
number of independent Z39.50 implementations were operational
able to interoperate across the Internet
The Library of Congress, in its role as the Z39.50 Maintenance
for NISO, maintains a registry of the implementors [8],
includes members of the Z39.50 interoperability testbed
This document describes implementation decisions by
implementors of Z39.50 in the Internet environment. These have
proven within the ZIT project and are being used by most of
members of the Z39.50 Implementors' Group (ZIG), an informal
that meets quarterly to discuss implementation and
issues and to develop extensions to the Z39.50 protocol targeted
inclusion in future versions of the standard. Intended as a guide
other implementors who seek to develop interoperable Z39.50
implementations running over TCP/IP, this document focuses on
related to TCP/IP, and it does not address other
interoperability problems or agreements that have been reached
the implementors to address these problems. It does include a
notes about extensions to the existing Version 2 protocol that
being used in the implementor community which have
implications. Potential implementors of Z39.50 should subscribe
the Z3950IW LISTSERV [9] to obtain information specific to the Z39.50
protocol and extensions under development as well as details
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
ANSI/NISO Z39.50-1992, sometimes called Z39.50 Version 2 (
obsolete original version is referred to as Z39.50-1988 or Z39.50
Version 1). The approach defined should also be applicable,
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
base Z39.50 protocol as they become stable
The Z39.50 standard specifies its application protocol data
(APDUs) in Abstract Syntax Notation One (ASN.1) [10]. These
include EXTERNAL references to other ASN.1 and non-ASN.1 objects
as those defining record transfer syntaxes to be used in a
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
that can be transmitted across a TCP/IP connection. The
restriction on the use of BER to produce this byte stream is
direct, rather than indirect, references must be used for
objects. This is necessary because there is no presentation
in the TCP/IP environment to support indirect reference. A Z39.50
implementation developed according to this specification and
over TCP/IP should produce a valid byte stream according to
Z39.50 standard, in the sense that the same byte stream could
passed to an OSI implementation. However, not all byte streams
can be produced by applying BER to the APDUs specified in the Z39.50
standard in an OSI environment will be legitimate under
specification for the TCP/IP environment; this specification
a subset of the possible byte streams valid in a pure OSI
which excludes those using indirect reference for EXTERNAL objects
All other BER features should be tolerated by Z39.50
running over TCP/IP, including the ability to accept
length encodings, although it is preferable that implementations
not generate such encodings since they have caused problems for
ASN.1/BER parsers. It should also be noted that at least to the
of the author's knowledge, there are no implementations at
that use ASN.1/BER representations of floating point numbers
instead, integers with scaling factors have been used for
purposes. It should also be noted that Z39.50 version 2 does
really address character set encoding issues; these questions,
their interactions with ASN.1/BER support for multiple
sets, are under active discussion as part of the effort to
Z39.50 version 3.
Lynch [Page 3]
RFC 1729 Using the Z39.50 in the Internet Environment December 1994
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
opens a TCP connection to port 210 on the server and then, as soon
the TCP connection is established, transmits a Z39.50 INIT APDU
the BER encoding of that INIT APDU as described above
Implementors should be aware that there is a substantial
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
encoding and Z39.50 Version 1 INIT APDUs look very different from
INIT APDUs of Z39.50 Version 2. Implementations of Z39.50 should
least be prepared to reject gracefully WAIS-type INIT APDUs.
implementations recognize such INIT APDUs and revert to the Z39.50
Version 1 variant used in WAIS upon encountering them, thus
backwards compatibility with the existing base of WAIS clients and
the usual means of checking for a WAIS, as opposed to Z39.50
2, client is to see if the first byte sent on the connection is
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
case ASCII string "wais" appears starting at byte 12.) Work
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
Interest Group. This profile is expected to be compatible with
layering defined in this RFC
Service
The Z39.50 standard maps Z39.50 services onto a variety
association control and presentation layer services.
establishment has already been discussed. The other two
control services that are relevant to Z39.50 are ABORT and RELEASE
The mapping of the RELEASE service to a standard TCP CLOSE
straightforward. The Z39.50 protocol itself does not, in the
version, include a Z39.50 CLOSE APDU. When the client has
its interaction with the server, it calls the IR-RELEASE service
which is directly mapped to association control's orderly
release. In the TCP/IP environment, the client should simply
a TCP CLOSE. The mapping for association abort is more complex
partially because some TCP/IP implementations cannot distinguish
TCP reset from the other side of the connection from other events.
accomplish an abort (that is, a mapping of the IR-ABORT service
the Z39.50 protocol) in the TCP/IP environment, client or server
only terminate the TCP connection either via TCP ABORT or TCP CLOSE
Lynch [Page 4]
RFC 1729 Using the Z39.50 in the Internet Environment December 1994
Real-world implementations need to be prepared to deal with both
ABORT and CLOSE anyway, so this approach presents no
problems, other than the somewhat ambiguous nature of the type
association termination
It is expected that Z39.50 Version 3 will include a
service which will involve an exchange of Z39.50 CLOSE APDUs
followed by an association RELEASE (which would presumably, in
Internet environment, be mapped to a TCP CLOSE). This new
service is expected to support both graceful and abrupt termination
Of course, robust implementations will still need to be prepared
encounter TCP CLOSE or ABORT
Service mappings for the transmission of data by client and
(to the presentation layer P-DATA service) are trivial: They
simply mapped to TCP transmit and receive operations. TCP
such as expedited data are not used by Z39.50 in a TCP environment
At the point when the TCP connection is established on TCP port 210,
client and server should both assume that the application
given in Appendices A and B of the Z39.50-1992 standard are in place
These are the ASN.1 definitions of the Z39.50 APDUs and the
syntax defined by applying the BER to these APDUs
Implementations can reasonably expect that the diagnostic set BIB-1
is supported, and, if resource control is being used, the
report format BIB-1 is supported as well
In the absence of a presentation negotiation mechanism, clients
servers should be cautious about using alternative attribute sets
diagnostic record formats, resource report formats, or other
defined by optional EXTERNALs within the Z39.50 ASN.1, such
authentication parameters, unless there is known to be
agreement to support them. Of course, either participant in
association can reference such an object by object ID in an APDU,
there is no guarantee that the other partner in the association
be able to understand it. Robust implementations should be
to encounter unknown or unsupported object IDs and
appropriate diagnostics. Over time, the default, commonly known
of object IDs may be expanded (for example, to support
parameters).
Implementors should refer to the document [14] issued by the Z39.50
maintenance agency in June 1992 for more details on the
contexts and object identifiers
Lynch [Page 5]
RFC 1729 Using the Z39.50 in the Internet Environment December 1994
Record syntaxes present a serious practical problem. In the
environment, the partners in a Z39.50 association are assumed
agree, either through presentation negotiation as part of
establishment, or later, dynamically, as part of the PRESENT
(through the use of the alter presentation context function at
presentation layer), on which record syntaxes the two
commonly know. There is a preferred record syntax parameter that
be supplied by the client to guide this negotiation. A number
registered record syntaxes exist; some are based on ASN.1 and
use formats such as the MARC standard for the interchange of
readable cataloging records which predate ASN.1, but are
implemented. In the TCP/IP environment, if the server cannot
the record in the preferred syntax, it has no guarantee that
client will understand any other syntax in which it might
the record back to the client, and has no means of negotiating
syntaxes
Several proposals have been suggested to solve this problem. One
which will likely be part of Z39.50 Version 3, is to replace
preferred record syntax parameter with a list of
preferred syntaxes supplied by the client, plus a flag
whether the server is allowed to substitute a record syntax not
the list provided by the client. The currently proposed ASN.1
this extension is upwards compatible with Z39.50 Version 2,
the details are still under discussion within the Z39.50
Implementor's Group. As the Version 3 ASN.1 becomes stable in
area, Z39.50 servers are encouraged to accept the extended ASN.1
generalized preferred record syntax. The extensibility rules
Z39.50 negotiation let clients and servers negotiate the use
Z39.50 Version 2 plus the generalized preferred syntax feature
Version 3. Thus, a client could support the generalized
record syntax, propose its use to any server, and, if the
rejects the proposal, revert to the Version 2 preferred
feature
A second alternative (not incompatible with the Version 3 extension
would be to adopt a convention for TCP/IP implementations that
server not return a record in a syntax not on the preferred
syntax list provided by the client. Instead, it would return
diagnostic record indicating that a suitable record transfer
was not available. This strategy could be viewed as
implementing a subset of the Version 3 solution, and should
considered by implementors of servers as a possible interim measure
Lynch [Page 6]
RFC 1729 Using the Z39.50 in the Internet Environment December 1994
Other Interoperability
Version 3 will include an "other" data field in each APDU, which
be used to carry implementation-specific extensions to the protocol
A number of implementations are already employing this field,
interoperable implementations might be wise to include code which
least ignores the presence of such fields rather than
their presence an error (in contravention of the standard).
[1] National Information Standards Organization (NISO).
National Standard Z39.50, Information Retrieval
Definition and Protocol Specifications for Library
(New Brunswick, NJ: Transaction Publishers; 1988).
[2] ANSI/NISO Z39.50-1992 (version 2) Information Retrieval
and Protocol: American National Standard, Information
Application Service Definition and Protocol Specification
Open Systems Interconnection, 1992.
[3] ISO 10162 International Organization for Standardization (ISO).
Documentation -- Search and Retrieve Service Definition, 1992.
[4] ISO 10163 International Organization for Standardization (ISO).
Documentation -- Search and Retrieve Protocol Definition. 1992.
[5] ISO 8822 - Information Processing Systems - Open
Interconnection - Connection Oriented Presentation
Definition, 1988.
[6] ISO 8649 - Information Processing Systems - Open
Interconnection - Service Definition for the Association
Service Element, 1987. See also ISO 8650 - Information
Systems - Open Systems Interconnection - Protocol
for the Association Control Service Element, 1987.
[7] Rose, M., and D. Cass, "ISO Transport Layer Services on Top
the TCP, Version 3", STD 35, RFC 1006, Northrop Research
Technology Center, May 1987.
[8] Registry of Z39.50 Implementors, available from the Z39.50
Maintenance Agency (Ray Denenberg, ray@rden.loc.gov
Lynch [Page 7]
RFC 1729 Using the Z39.50 in the Internet Environment December 1994
[9] To subscribe to the Z39.50 Implementor's Workshop list send
message: SUB Z3950IW yourname to: LISTSERV@NERVM.NERDC.UFL.
(or NERVM.BITNET). Current drafts of the Version 3
document are available through the Library of Congress
server, MARVEL.LOC.GOV
[10] ISO 8824 - Information Processing Systems - Open
Interconnection - Specifications for Abstract Syntax Notation
(ASN.1), 1987
[11] ISO 8825 Information Processing Systems - Open
Interconnection - Specification of Basic Encoding Rules
Abstract Syntax Notation One (ASN.1) 1987
[12] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
USC/Information Sciences Institute, October 1994.
[13] WAIS Profile of Z39.50 Version 2, Revision 1.4, April 26, 1994,
available from WAIS Inc
[14] Registration of Z39.50 OSI Object Identifiers (Z39.50-MA-024),
available from the Z39.50 Maintenance Agency (Ray Denenberg
ray@rden.loc.gov).
Security
This document does not discuss security considerations. However,
should be noted that the Z39.50 protocol includes mechanisms
authentication and security that implementors should review
Author's
Clifford A.
University of California, Office of the
300 Lakeside Drive, 8th
Oakland, CA 94612-3550
Phone: (510) 987-0522
EMail: clifford.lynch@ucop.
Lynch [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
