Browse Prior Art Database

Uniform Resource Locators for Z39.50 (RFC2056)

IP.com Disclosure Number: IPCOM000002607D
Original Publication Date: 1996-Nov-01
Included in the Prior Art Database: 2019-Feb-16
Document File: 7 page(s) / 10K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Denenberg: AUTHOR [+2]

Related Documents

10.17487/RFC2056: DOI

Abstract

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. [STANDARDS-TRACK]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 26% of the total text.

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 d...

Processing...
Loading...