Summary

  • RFC 1292 is FYI 11, an Informational memo published in January 1992. It catalogued stated availability and capabilities of commercial and openly available X.500 implementations; it did not specify an Internet standard or certify the implementations it named.
  • The catalog's keyword classes made a description easier to compare. They did not prove that a named DSA or DUA was installed, reachable, secure, interoperable in a particular configuration, suitable for an organisation, or able to complete a directory operation.

The title of RFC 1292 is modest but its practical ambition was large. X.500 was a directory-service architecture whose pieces could appear in different forms: a Directory System Agent, a Directory User Agent, a client that asked a DUA to speak on its behalf, a commercial package, a freely available package, a source distribution, an offering bound to a particular transport or machine. For an administrator or researcher, the first difficulty was often not choosing among tested alternatives. It was discovering what alternatives claimed to exist at all.

The Directory Information Services Infrastructure Working Group, DISI, responded with a catalog. Its introduction says that the document contains descriptions of currently available X.500 implementations, both commercial products and openly available offerings. It says the descriptions cover DSAs, DUAs and DUA client applications; it gives readers a keyword index meant to help identify implementations meeting their own criteria. That was a real service to a community faced with a spread of software, pilots and transports. But the document also draws unusually clear limits around the service it offers.

Those limits are the history worth retaining.

The catalog recorded descriptions, not measurements

RFC 1292 did not send a neutral laboratory to inspect every implementation. It says that DISI assembled the catalog by soliciting input from X.500 communities on several Internet mailing lists. More importantly, it says that the implementation descriptions were written by implementors and vendors, rather than by DISI members. DISI worked with their authors on readability, but gave no guarantee of the descriptions' validity or of the value of the implementations. The short warning — caveat emptor — is not ornamental. It identifies who made the underlying assertions and who declined to certify them.

That provenance creates at least four distinct records. An implementor can state that a package has a DSA, a DUA, an API, a transport binding or a client interface. A catalog editor can decide that the statement belongs under a keyword. An independent tester can run a specified version in a particular environment against another specified implementation. Finally, an organisation can decide that the tested arrangement is worth operating for its own users. None of those acts is a mere restatement of the previous one.

The value of the catalog sits mainly in the first two. It preserves a historical map of claims and categories. It does not collapse the map into a test result. A reader who treats a catalog row as proof of interoperability has silently added configuration, version, schema, transport, authentication, operational support and test evidence that RFC 1292 does not supply. A reader who treats it as a recommendation has also supplied a decision that the editors explicitly refused to make.

The distinction is especially useful because an early directory system did not present one indivisible product boundary. A DSA stored or served part of the directory information tree. A DUA gave a user-facing agent a way to make directory requests. A lightweight DUA client might use a non-OSI application protocol to reach a DUA, which in turn communicated with a DSA. A row saying that an offering had one of these forms did not say it had all of them, that the components were configured together, or that a user could reach a useful directory entry through the whole chain.

A keyword was a classification of an explicit claim

The catalog's keywords are often more precise than a retrospective label such as “supports X.500.” RFC 1292 says they were abbreviated attributes derived from the implementation descriptions. An implementation was indexed under a keyword because the description explicitly — not merely implicitly — referred to a capability, or because the description's author supplied the input. This is a disciplined indexing rule. It prevents an editor from promoting an inference into a feature claim simply because a related component is present.

Yet a disciplined indexing rule still has a narrow object: the wording of a description. It does not execute the feature. The catalog's availability section, for example, distinguishes availability via FTAM, availability via FTP, commercial availability, free availability, source availability and a state called Potentially Unavailable. These are not interchangeable. “Source” says source code is available, possibly for additional cost; it does not say a reader can build it in every environment. “Free” says there is no charge while warning that other restrictions may apply; it does not say the software is maintained, portable or fit for a given task. “Commercially Available” says an implementation can be purchased; it does not tell a reader which release, licence, support channel or integration cost applies.

Potentially Unavailable is even more revealing. The definition says the implementation was not available when the document was written. A catalog that can preserve such a state is acknowledging its own time boundary. An entry can be historically true as a report of a condition at compilation and useless as a claim about later access. The label does not become false merely because time passes; it becomes insufficient for a new question. Someone looking for software must still observe the then-current distribution point, terms and version. Someone reconstructing history must still avoid reading “available” as a timeless property.

The same limitation applies to the list of operating environments. A package described as running on a named platform says something about a stated environment. It does not prove that the reader's hardware, operating-system revision, compiler, transport stack, directory schema or administrative policy matches it. A compatibility matrix can narrow the search space. It cannot, by itself, bind the two sides of an eventual connection.

Transport labels did not perform the connection

RFC 1292 includes an internetworking-environment category: CLNP, unspecified OSI transport, RFC 1006 and X.25. The entries help a reader ask the right preparatory question. A package described as using RFC 1006 uses TCP/IP transport service in the document's taxonomy; a package described under CLNP uses that OSI network protocol. But the keyword is not a transcript of a successful association.

For a working directory request, many further conditions could matter: which protocol profiles were enabled; how names were represented; which schema attributes and object classes were recognised; whether the peers trusted one another; whether a route existed; which versions were installed; how referrals or errors were handled; and which policy allowed access. RFC 1292 does not deny those conditions. It simply does not claim to resolve them. Its categories preserve the difference between a compatible-looking ingredient and an observed end-to-end exchange.

This is where a catalog can tempt a later reader into an overstatement. A row may show “RFC-1006,” a DSA/DUA form and an operating system. It is tempting to narrate that row as “this implementation connected X.500 over TCP/IP.” The document supports a narrower statement: an author described the implementation using those attributes and the catalog placed the description in those keyword classes. A connection is an event. It needs participants, a time, configuration and a result. The index is not secretly that event.

Pilot connectivity had direction and scope

The pilot-connectivity definitions show the same care. A DUA connectivity entry means that the DUA can be connected to the pilot and that information on a pilot entry can be looked up; it can display standard attributes and object classes, as well as those defined in COSINE and Internet Schema. A DSA connectivity entry means that the DSA is connected to the directory information tree and that information in that DSA is accessible from any pilot DUA. The two labels are not just two spellings of “on the pilot.” They describe different roles and directions of access.

Even those definitions must be read inside their document date and claim provenance. They identify the sort of connectivity an implementation description asserted. They do not name a particular remote DSA, certify a route, establish that the pilot stayed accessible, prove that every object class behaved the same way, or show what a reader's query returned. A DUA's ability to display an attribute is not proof that the attribute is current. A DSA's advertised accessibility is not proof that every pilot DUA reached it during an outage or under a later policy.

This matters because directory systems make a good demonstration of how quickly “knows about a directory” can become “the directory works.” There is a wide interval between having client software, configuring a transport, reaching an agent, resolving a name, receiving entries, interpreting their schema, deciding that they are current and relying on them. RFC 1292 stands at the beginning of that interval. It helps identify candidates. It does not certify the rest.

No recommendation was a substantive design choice

The scope section explicitly says that the memo does not provide instructions on how to install, run or manage the listed implementations. It gives no recommendations because organisations' needs and computing environments differ greatly. This is not an evasion of usefulness. It is a statement about where the catalog's authority stops.

Recommendation requires criteria and accountability. A recommendation for one organisation could depend on existing transport, staff skills, directory schema, security requirements, licensing, support arrangements, migration cost, user population and tolerance for operational risk. The catalog supplies a vocabulary from which a reader may build such a comparison. It does not select weights for the reader or promise that a package is appropriate after those weights are applied.

The line between information and recommendation is easily lost when a catalog is well organised. A cross-reference can make alternatives look ranked even if no ranking is intended. A list can make omission look like negative assessment even if the editors merely lacked a description. A mature reader therefore keeps the source's verbs intact: it catalogs, describes, indexes and aims to make options known. It does not install, operate, endorse or guarantee.

Updating the catalog was itself a governance process

RFC 1292 also says that new or updated descriptions are welcome, and that DISI will produce new versions after a sufficient number of changes have arrived. Whether the number is sufficient is to be determined subjectively by the DISI chairperson. That sentence makes maintenance visible. A catalog does not update because the world has changed; someone has to receive a report, decide that it merits publication, prepare a revision and distribute it.

The consequences are practical. Between editions, a newly available product may be absent. A withdrawn product may remain listed. A changed capability may be described in an old form. An implementor may submit a claim that is clear but incomplete. The catalog's usefulness depends on a social path from implementor to mailing list to editor to new version. None of those handoffs is a live probe of the software.

This does not make the document weak. It makes it legible. The catalog preserves a 1992 snapshot of how a community tried to reduce a lack-of-information barrier around X.500. Its disclaimers, explicit-keyword rule and update policy are part of the information architecture, not embarrassing caveats at the margin. They tell readers what kind of object they are holding: a maintained index of self-described options, not a directory-service verdict.

The RFC leaves security and outcomes elsewhere

RFC 1292 speaks about availability and capability, not an assurance program. It does not establish authentication properties, confidentiality, integrity, vulnerability status or operator practices for a listed implementation. Nor does it prove that a pilot connection was authorised, that a directory entry was accurate, or that an organisation achieved a useful service outcome after choosing a package.

That evidence boundary is important in historical work. A 1992 catalog can establish that a specific kind of choice was visible to its contributors and that the contributors used particular categories to make the choice discussable. It cannot be converted into present product advice, a security attestation, a deployment census or an interoperability test. The historical record gains precision when the catalog remains a catalog.

Source and evidence limits

This article uses RFC 1292 — A Catalog of Available X.500 Implementations. The source supports the January 1992 FYI/Informational status, DISI's catalog purpose, the DSA/DUA/client distinction, mailing-list solicitation, self-authored implementation descriptions, the absence of validity/value guarantees, explicit-claim keywording, availability/transport/pilot categories, no-install/no-recommendation scope and subjective revision threshold. It does not prove installation, availability after publication, current support, a licence, successful build, reachable host, pilot access, interoperability, security, suitability, recommendation, completed lookup or organisational outcome.