Summary

  • RFC 2056 defined z39.50s for entering or reusing an interactive Z39.50 session that remains open, and z39.50r for a bounded known-item retrieval built from an opaque server-defined docid.
  • The retrieval form specifies a Type-1 query, requires exactly one Search hit, and uses Present when Search Response does not carry the record; element-set and record-syntax choices govern what is exported, not the truth or completeness of the underlying bibliographic object.
  • RFC 2056 is documented today as a Proposed Standard in the IETF Datatracker's Legacy stream, while IANA lists z39.50s and z39.50r as Permanent URI schemes. Those are documentary and registry facts, not evidence of present deployment or current best practice.

RFC 2056 arrived in November 1996 with a problem that the familiar language of “a URL retrieves a resource” did not quite fit. Z39.50 inquiry was not necessarily a single request followed by a single response. Its normal shape could be conversational: a client began a session, a search unfolded in steps, and a step might pause because the server needed additional parameters. A user could remain inside that stateful exchange and continue working.

The RFC nevertheless recognized a narrower case. If the desired object was already known well enough to the server, the interaction could collapse into what the document describes as a degenerate one-search request/response session. RFC 2056 encoded that difference at the beginning of the locator itself. z39.50s meant session; z39.50r meant retrieval. A user interface could therefore know whether it was opening an interactive environment or attempting to obtain one item without first deciphering the rest of the URL.

The session scheme, z39.50s, is intentionally permissive. A host is required and the default port is 210. Other parameters are optional. The client may create a new session or reuse one already open to the same host and port. When a docid is present, a database must also be named and the specified search is carried out. Without a docid, the remaining parameters do not all acquire mandatory force: a client may treat them as requirements, preferences, or hints it can ignore. The defining operational outcome is that the session remains open for the user.

The retrieval scheme, z39.50r, narrows the client's discretion. Host and database are required, again with port 210 as the default. A URL lacking docid has undefined meaning. The docid itself is defined by the server and is completely opaque to the client. The client does not interpret it as a bibliographic key or portable identifier. Instead, it places the unchanged string into a precisely prescribed Z39.50 Search: a Type-1 query using Bib-1, Use=docid, Structure=URx, with the docid as the single term in general format tag 45.

That construction leads to an unusually crisp success condition. Search must produce exactly one hit. Zero hits do not satisfy the retrieval, and neither do two or more; for any count other than one, retrieval is unsuccessful and subsequent application behavior is undefined. If the one record is already included in Search Response, no additional retrieval operation is needed. If it is not, the client issues Present. After receiving the record, the client may close the session or retain it.

The grammar records the same mechanism compactly. RFC 2056 shares the common URL syntax of RFC 1738. It permits one or more database names separated by +, an optional ?docid, an ;esn= parameter, and a single ;rs= parameter whose multiple record-syntax values are separated by +. The two scheme names are exactly z39.50s and z39.50r.

Record selection and record representation are separate parts of the exchange. A Z39.50 Search creates a server-side result set containing pointers to records selected from the named database or databases. RFC 2056 also distinguishes the local database record, a shared abstract database record, and the retrieval record exported to the client. elementset determines which logical elements are selected for retrieval; recordsyntax determines how those selected elements are represented for transfer.

The defaults preserve client choice. If esn is absent, the client chooses the element set. If it is supplied, it is used in the named parameters of Search or, when retrieval proceeds separately, Present. If rs is absent, the client chooses the record syntax. When the single rs parameter contains several +-separated values, the client should prefer the first one it supports and send that value as PreferredRecordSyntax. RFC 1729 provides contemporary interoperability context for this detail: a server's inability to supply a client's preferred syntax could cause practical difficulty.

This machinery makes the retrieval operation exact without making its result omniscient. An exactly-one-hit result describes what the server selected in response to the prescribed query. It does not establish that the selected record is the work a human intended, that its bibliographic description is correct, or that the server has not replaced what a token once denoted. Likewise, receiving an exported record says that a representation was delivered. Element selection can omit information, and record syntax can change the transfer representation; neither operation guarantees semantic completeness or safe downstream parsing.

The same distinction applies earlier in the path. Resolving a host and accepting a connection on port 210 do not establish the endpoint's identity, ownership, authority, continued availability, or conformance to the intended profile. A database name is a protocol coordinate, not proof of a stable catalogue, collection, custodian, or authorization domain. A server-defined docid is useful precisely because the client need not understand it, but that opacity also supplies no basis for treating it as globally persistent, authentic, content-addressed, or portable.

RFC 2056's own security section gives these limitations practical force. It warns that a locator may cease to point to the object originally intended. It also warns that an apparently harmless retrieval may cause a damaging remote operation. Successful resolution and record delivery therefore cannot, by themselves, answer questions about identity, authority, harmlessness, continuing authorization, user intent, or the success of whatever external purpose motivated the retrieval.

RFC 1625 is nearby history but not an interchangeable specification. Its WAIS profile used a Type-3 query and stateless result handling. RFC 2056's retrieval URL instead mandates its Type-1 known-item construction and may require Present. The contrast helps explain the design space of the period, but substituting the WAIS mechanism would erase the very behavior RFC 2056 specified.

The documentary record is clear about what survives on paper. The RFC Editor and IETF Datatracker currently label RFC 2056 a Proposed Standard; Datatracker places it in the Legacy stream, and the captured records show no explicit relationship marking it updated or obsolete. The IANA URI Schemes registry lists z39.50s and z39.50r as Permanent and the older z39.50 entry as Historical. None of those records measures current traffic, active implementations, deployment health, operational endorsement, or present-day suitability. They describe standards and registry status, not a census of running systems.

Sources