RFC 2056

Uniform Resource Locators for Z39.50

📅 published November 1996, from ietf

RFC 2056: Uniform Resource Locators for Z39.50 💖

okay bestie, this is RFC 2056, called Uniform Resource Locators for Z39.50. It's on the Standards Track and it sits in the Network Working Group. It came out in November 1996. The editors are R. Denenberg (Library of Congress), J. Kunze (University of California, San Francisco), and D. Lynch (SilverPlatter Information Ltd.). It doesn't list any RFCs that it obsoletes or updates 🎀

Status of this Memo ✨

This document is a specification for an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

1. Introduction ✨

okay so Z39.50 is an information retrieval protocol, and it is NOT a "grab it and go" kinda protocol 🙅‍♀️ It doesn't fit neatly into a retrieval model that's mostly built around the stateless fetch of data. Instead, it treats a general user inquiry as a session-oriented, multi-step task. Any step of that task may be suspended temporarily while the server asks the client for more parameters before it continues. Some, none, or all of these client/server interactions may need the client user to take part. That depends only on the client software, since the protocol itself makes no such requirements 💅

On the other hand, retrieval of "well-known" data may happen in a single step. That's a degenerate Z39.50 session made of exactly one protocol search request and response, which is so efficient 🦋 Besides the basic search sub-service, there are several ancillary sub-services (for example, Scan and Result Set Delete). When you look at what the sub-services do together, two core functions emerge, and they're best handled by two separate URL schemes: the Session URL and the Retrieval URL 🌸

Using two schemes instead of one makes a critical distinction. A Z39.50 Session URL opens a client session that's set up for interactive use by the user. A Z39.50 Retrieval URL opens and closes a client session to retrieve one specific information item. Making this distinction at the scheme level means the user interface can show it to the user, without having to parse the otherwise opaque parts of the URL (which is consistent with current practice) 🧚

2. Some Basic Concepts 🍓

This section gives a quick rundown of the Z39.50-specific terminology used in the URL definitions below. The terms are database, elementset, recordsyntax, and docid, and the vibe is "learn these and you're set" 🤓

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

Z39.50 models three things: database records, abstract database records, and retrieval records. A database record is a unit of information in a database, represented in a data structure that's local to the server. An abstract database record is an abstract representation of that information, where the client and the server share a common understanding of the representation. This lets logical elements be addressed and selected for transfer, using 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 applying a "recordsyntax" 💜

So a Search operation results in entries that point to database records. Then, through a Present operation, a client requests a retrieval record. That record corresponds to a database record, which corresponds to an entry in the result set. The client says what the retrieval record is made of and how it's formatted by specifying an elementset and a recordsyntax, respectively 👑

Now for the special case: a "known-item" search. This is when a client intends for a search to identify a single, known database record, or "document" (for illustration, assume a database record corresponds to a document). On top of that, the client knows an identifier for the document that can be used to run this known-item search. That identifier is often called a document identifier, or "docid" 🎀

3. The Z39.50 Session URL ✨

The Z39.50 Session URL can be described informally as the mechanism that switches the user over to a Z39.50 client application. Here's how it works, bestie 💖

  • Host is required.
  • Port is optional, and defaults to 210.
  • All other parameters are optional.
  • The Z39.50 client will start a session to the specified host/port. Alternatively, it doesn't need to explicitly start a session, and can instead use an already open session to the same host/port.
  • A database must be included if docid is included.
  • If docid is included, the client will perform the specified search (in the same manner as for the retrieval URL, specified below).
  • If docid is not included, and other parameters (besides host/port) are specified, the client may use those parameters as "hints". Various clients may choose to treat them as requirements, or as preferences, or ignore them.
  • In any case (whether a search is performed or not), the client will leave the Z39.50 session open for the user, to do retrievals, new searches, etc. This is the main distinction from the Retrieval URL, which leaves it up to the client whether or not to keep the Z39.50 session open. 🦋

4. The Z39.50 Retrieval URL 🌈

The Z39.50 Retrieval URL is meant to let a Z39.50 session be used as a transparent transfer mechanism for retrieving one specific information object. A Z39.50 client uses the information in the URL to formulate a Search Request. The server's Search Response says how many records match the Request. If the number of matching records does not equal one, the retrieval is considered unsuccessful, and the client application's behavior is not defined 😭 If the number of matching records equals one, the server may have already included the desired record in the Search Response. If it hasn't, the client requests transmission of the record with a Present Request. After the client has received the specified record, it can close the Z39.50 session right away, or keep it open for later retrievals 💅

  • Host is required.
  • Port is optional, and defaults to 210.
  • A database is required.
  • The meaning of a retrieval URL with no docid is undefined.
  • The docid is placed into a type-1 query, as the single term, in the general format (tag 45), using the Bib-1 attribute set, with a Use attribute value of docid, and a structure attribute of URx. The docid string is server-defined and completely opaque to the client. 🔥
  • If element set name (esn) is not specified, it is the client's choice. If esn is specified, it should be used either in the Search request for the value of small- and/or medium-set-element-set-names, or in a Present request following a Search. These terms and their use are defined within the Z39.50 Standard [2].
  • If record syntax (rs) is not specified, it is the client's choice. If one or more record syntaxes are specified, the client should select one (preferably the first in the list that it supports) and use it in a Search or Present request as the value of PreferredRecordSyntax. 🍓

5. BNF for Z39.50 URLs 💜

The Z39.50 Session and Retrieval URLs follow the Common Internet Scheme Syntax as defined in RFC 1738, "Uniform Resource Locators (URL)" [1]. In the definition, literals are quoted with "", optional elements are enclosed in [brackets], "|" is used to designate alternatives, and elements may be preceded with <n>* to designate n or more repetitions of the following element. n defaults to 0. 🫶

z39.50url      = zscheme "://" host [":" port]
                      ["/" [database *["+" database]
                             ["?" docid]]
                           [";esn=" elementset]
                           [";rs=" recordsyntax *[ "+" recordsyntax]]]

zscheme        = "z39.50r" | "z39.50s"
database       = uchar
docid          = uchar
elementset     = uchar
recordsyntax   = uchar

Future extensions to these URLs will be of the form of [;keyword=value]. ✨

The following definitions are from RFC 1738. Between the Internet Draft version and RFC 1738, two relevant changes were made: '=' was moved from the <extra> character class to <reserved>, and <national> was removed from the alternatives in <unreserved>. Neither <national> nor <punctuation> is referred to in this document or in RFC 1738 🦋

lowalpha       = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                 "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                 "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                 "y" | "z"
hialpha        = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
                 "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
                 "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"

alpha          = lowalpha | hialpha
digit          = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                 "8" | "9"
safe           = "$" | "-" | "_" | "." | "+"
extra          = "!" | "*" | "'" | "(" | ")" | ","
national       = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
punctuation    = "<" | ">" | "#" | "%" | <">

reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "="
hex            = digit | "A" | "B" | "C" | "D" | "E" | "F" |
                 "a" | "b" | "c" | "d" | "e" | "f"
escape         = "%" hex hex
unreserved     = alpha | digit | safe | extra
uchar          = unreserved | escape
xchar          = unreserved | reserved | escape
digits         = 1*digit

9. Editors' Addresses ✨

okay so this is the part where the editors get their moment 💅 here's where you can find all three of them, bestie:

Ray Denenberg, from the Library of Congress 📚

  • Collections Services
  • Network Development/MSO
  • Washington DC 20540
  • Phone: (202) 707-5795
  • Fax: (202) 707-0115
  • EMail: ray@rden.loc.gov

John A. Kunze, from the Center for Knowledge Management at UCSF 🦋

  • University of California, San Francisco
  • 530 Parnassus Ave, Box 0840
  • San Francisco, CA 94143-0840
  • Phone: (415) 502-6660
  • Fax: (415) 476-4653
  • EMail: jak@ckm.ucsf.edu

Denis Lynch, from SilverPlatter Information Ltd. 🌸

  • 10 Barely Mow Passage
  • Chiswick, London W4 4PH
  • U.K.
  • Voice: +44 (0)181-995-8242
  • Fax: +44 (0)181-995-5159
  • EMail: DenisL@SilverPlatter.com

Appendix. Examples of Z39.50 URLs 🧚

okay the examples are the best part, no cap 🫶 these show you what the URLs actually look like in the wild

A basic session URL 🎀

this is a basic Z39.50 session URL a client might use to open a connection to the MELVYL union catalog "cat" at the University of California:

z39.50s://melvyl.ucop.edu/cat

A retrieval URL for a magazine article 📖

this one would open the MELVYL magazine database just long enough to fetch an article from volume 30, number 19 of a hypothetical periodical, which is so iconic 😭

z39.50r://melvyl.ucop.edu/mags?elecworld.v30.n19

A full MARC record retrieval URL 💜

as a final example, here's another retrieval URL a client could use to request a full record (element set "f") in the MARC syntax from a hypothetical database called TMF at CNIDR 🍓

z39.50r://cnidr.org:2100/tmf?bkirch_rules__a1;esn=f;rs=marc

same as the previous example, the part of the string after the ? is determined by the server, so the server gets to decide that bit 🙈 in this one the server is running on the non-standard port 2100, which is literally a lil plot twist ✨

📦 where this page comes from