Uniform Resource Locators for Z39.50
RFC 2056

Network Working Group                                       R. Denenberg
Request for Comments: 2056                           Library of Congress
Category: Standards Track                                       J. Kunze
                                 University of California, San Francisco
                                                                D. Lynch
                                          SilverPlatter Information Ltd.
                                                                 Editors
                                                           November 1996

                  Uniform Resource Locators for Z39.50

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

1. Introduction

   Z39.50 is an information retrieval protocol that does not fit neatly
   into a retrieval model designed primarily around the stateless fetch
   of data.  Instead, it models a general user inquiry as a session-
   oriented, multi-step task, any step of which may be suspended
   temporarily while the server requests additional parameters from the
   client before continuing.  Some, none, or all of these client/server
   interactions may require participation of the client user, depending
   only on the client software (the protocol itself makes no such
   requirements).

   On the other hand, retrieval of "well-known" data may be performed in
   a single step, that is, with a degenerate Z39.50 session consisting
   of exactly one protocol search request and response.  Besides the
   basic search sub-service, there are several ancillary sub-services
   (e.g., Scan, Result Set Delete).  Among the functions covered by
   combinations of the sub-services, two core functions emerge as
   appropriately handled by two separate URL schemes:  the Session URL
   and the Retrieval URL.

   Using two schemes instead of one makes a critical distinction between
   a Z39.50 Session URL, which opens a client session initialized for
   interactive use by the user, and a Z39.50 Retrieval URL, which opens
   and closes a client session to retrieve a specific information item.
   Making this distinction at the scheme level allows the user interface
   to reflect it on to the user, without requiring the user interface to

Denenberg, et. al.          Standards Track                     [Page 1]
RFC 2056                    URLs for Z39.50                November 1996

   parse otherwise opaque parts of the URL (consistent with current
   practice).

2. Some Basic Concepts

   This section briefly describes the usage of Z39.50-specific
   terminology within the URL definitions below: specifically, the terms
   database, elementset, recordsyntax, and docid.

   The Z39.50 protocol specifies various information retrieval
   operations, the two most basic of which are Search and Present. In a
   Search operation a client provides search criteria and indicates a
   database (or several databases) on the server to search.  The
   essential result of a Search operation is that a result set is
   created at the server, consisting of pointers to the selected
   database records.

   Z39.50 models database records, abstract database records, and
   retrieval records.  A database record is a unit of information in a
   database, represented in a data structure local to the server.  An
   abstract database record is an abstract representation of that
   information, where the client and server share a common understanding
   of the representation.  This allows logical elements to be addressed
   and selected for transfer, via an element set specification, or, as
   used below, an "elementset".  A retrieval record is the set of
   selected elements packaged in an exportable structure, by the
   application of a "recordsyntax".

   Thus a Search operation results in entries pointing to database
   records; via a Present operation, a client requests a retrieval
   record, corresponding to a database record, corresponding to an entry
   in the result set. The client indicates the composition and format of
   the retrieval record by specifying an elementset and recordsyntax,
   respectively.

   A special case of a Z39.50 search is a "known-item" search, when a
   client intends that a search identify a single, known database
   record, or "document" (for purposes of illustration, assume that a
   database record corresponds to a document), and further, the client
   knows an identifier for the document that can be used to effect this
   known-item search.  In this case, this identifier is often referred