Summary

  • RFC 1625’s WAIS Type-3 query could carry both a reader’s seed text and a full document or selected portion as relevance feedback; the server returned ranked citations rather than the documents themselves.
  • The server did not retain a result set for later presentation. A client retrieved a chosen citation with another Search request naming its Doc-ID, format and, if needed, a byte, line or paragraph range.
  • The RFC defined the query and response envelope, not a universally comparable relevance scale, a complete deployment census or a reason for WAIS’s later decline.

The document joined the question

In June 1994, the Internet community received an informational description of how WAIS used Z39.50-1988. The document explicitly said it did not specify an Internet Standard. Its focus was a practical interface between a client and a server: keep the client simple, let it send the reader’s text, and do not require it to translate that text into a server-specific Type-1 query or know every supported Z39.50 attribute.

WAIS called that plain-text form a Type-3 query. But the query was not just a string. It could contain “seed words” typed by the reader and a list of document objects. A document object could be a whole item or a portion, identified with a Doc-ID, object type, chunk code and start/end positions. The chunk code specified whether a range counted bytes, lines or paragraphs.

That second input created relevance feedback. A reader could select an item or passage and ask for other documents similar to it. The source document did not have to be reduced to keywords by the client and then forgotten. It could travel as an object inside the next query, alongside whatever seed text the reader supplied. The server still decided how to search its own database; the protocol described what could cross the boundary, not a single ranking algorithm shared by every index.

This is a narrower story than “the Internet learned to search.” WAIS was one networked information-retrieval system with clients, servers, databases and a protocol. RFC 1689’s August 1994 status report described early WAIS clients as accepting natural-language queries and reported more than 100 databases and 5,000 users worldwide. Those are figures in a contemporaneous tool survey, not an independently audited census or a measure of later adoption.

A rank was a citation, not the answer

The response returned a list of WAIS Citations. Each could include a headline, relevance rank, available formats, Doc-ID and byte length. The RFC normalized the top score to 1000. That makes the response legible as an ordered list; it does not make 900 on one server comparable with 900 on another, establish that the top item was objectively relevant, or show that the reader found it useful.

A citation referred to an object on a server. It was not the object’s body. The distinction shaped retrieval. RFC 1625 describes WAIS as stateless: a server did not store a search result set and could delete it after sending the response. WAIS therefore did not use Z39.50’s Present Facility for this path. To obtain a selected item, the client sent another Search request, this time with a Type-1 query that named the Doc-ID and requested format. Optional range terms selected a start and end position.

The follow-up could return one document or one part of it. RFC 1625 notes that full-text records and images could exceed a client’s receive buffer, so clients could request chunks. That is a design rationale and an option, not proof that every client used chunking. A returned excerpt also did not silently become the complete source: the requested range and the server’s returned range still mattered.

The pattern has three separate records: what the reader supplied, what the server ranked, and what the client later retrieved. A Type-3 search could combine typed words with a selected passage. A citation could point to one format of one server-held object. A second request could bring back a bounded portion. Treating those records as one “search result” hides where interpretation, storage and retrieval actually occurred.

The identifier had a typed context

The later 1994 URL specification gave WAIS its own URL forms for a database, a search within a database, or an individual document. It also cautioned that a wais: URL was not a general address for arbitrary Z39.50 services. The scheme made the service and the kind of target more explicit; it did not turn every citation into a universally available resource.

A 2005 update preserved the historic wais: URI scheme and added a terse status note: WAIS was not widely implemented and almost no WAIS servers were then in use. That is evidence of the later state described by the RFC, not an explanation of why it happened. The available record does not support a claim that a particular successor displaced WAIS or that its relevance loop caused broad search adoption.

The close comparison inside this archive is RFC 1432’s 1993 book bibliography, which asks whether a listed book, price or contact remained obtainable. This article covers a different layer: how a selected document became input to another query, how a server ranked citations, and how a client named a document and range for retrieval. Finding a reference and retrieving a particular object were already separate operations, but the argument here is the protocol loop, not the condition of the catalog shelf.

Sources and evidence limits

The primary record is RFC 1625, with contemporary context from RFC 1689. The URI boundary appears in RFC 1738; its later historical note appears in RFC 4156. None of these documents supplies a complete implementation census, a cross-server ranking benchmark or a causal history of WAIS’s decline.