Uniform Resource Locators for Z39.50
RFC 2056
|
| Document |
Type |
|
RFC - Proposed Standard
(November 1996; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
RFC 2056 (Proposed Standard)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
Show full document text