Summary

  • RFC 1274 was published in November 1991 as an IAB standards-track specification for an implementation-independent COSINE and Internet X.500 pilot schema. It argued that the standard X.500 definitions were useful but insufficient for a large pilot, and that privately repeating common definitions would leave remote systems unable to determine their semantics.
  • It set a deliberately modest conformance floor: a DSA must store the specified values and a DUA must identify each type. Correct matching, object-class enforcement, correct display and previous-version compatibility were desirable rather than required. A class could be enhanced by optional attributes; changing mandatory attribute types required a new class and expiry of the old one.

A shared name was useful because private repetition lost meaning

RFC 1274 did not begin from the belief that every directory had to be identical. It accepted that local, esoteric and highly experimental requirements should remain private. A large pilot, however, could not remain intelligible if every site invented a private version of the same common person, organization or service description. A remote system might receive a familiar-looking field and still have no dependable way to know what that private type meant.

The proposed schema was therefore a coordination device. It allowed sites with support for the same recurring need to use a common definition and asked the process to avoid duplicate types for essentially similar real-world objects. That is a gain in vocabulary, not a transfer of authority. A schema says how a type is named and described inside a directory system; it does not establish that a particular value is true, current, authorised, complete or safe to disclose.

This limit matters because a well-known label can look stronger than it is. The fact that two systems use the same attribute name tells a reader that they have adopted a common term. It does not show that they collected the value by the same method, matched it with the same care, or have any right to speak for the person or institution described.

Storable and recognisable were a compatibility floor

The conformance section makes the narrowness explicit. A Directory System Agent claiming conformance had to be able to store the listed attribute and object-class values. A Directory User Agent had to identify each type to a user with an appropriate representation. Large values came with a stated qualification: a conforming DSA need not store them and a DUA need not display them, although presence had to be indicated.

Those requirements are meaningful. Without storage, a common schema cannot travel between sites; without type identification, a user cannot tell what kind of value is being presented. Yet the RFC did not turn that baseline into a claim that every value had been understood in every important sense.

A system can hold a field without validating the world behind it. A client can name a type without rendering its value correctly. A directory record can be available without proving the identity, mandate, privacy treatment or current status of the subject it names. RFC 1274 did not erase those distinctions by making the vocabulary common.

Desirable behavior was not a completed semantic claim

The document lists four things that were desirable but not required: correct matching on all defined syntaxes, enforcement of the implied object-class schema, correct display by DUAs and compatibility with a previous schema version. The list is an unusually valuable historical map of what shared definitions alone could not guarantee.

Correct matching concerns how a system compares values. Enforcement concerns whether a system actually respects the class rule suggested by the definitions. Display concerns what a human reader is shown. Compatibility concerns whether a new version continues to work with an older one. Each is related to the schema; none can be inferred merely because a system stores an attribute or can print the type name.

The boundary is evidentiary as well as technical. A displayed directory entry is evidence that a particular system rendered a particular stored value. It is not, without separate support, evidence that the value is accurate, that the implementation matched it correctly, that the class rule was enforced, or that a real-world principal authorised the entry.

Optional growth could preserve identity; mandatory change could not

RFC 1274’s procedure for change prevented a quieter confusion. If an existing object class gained only additional optional attributes, the class could be enhanced. Existing instances did not need a newly compulsory fact in order to remain instances of that class.

The rule changes when mandatory attribute types would be altered. The RFC proposed creating a new object class and expiring the original rather than silently revising what every existing instance was required to mean. This is not a cosmetic version label. A mandatory attribute participates in the condition for belonging to the class. Alter it, and the old shared identifier would begin to describe a different semantic promise.

The new-class rule leaves an auditable boundary. Readers can ask which class was used, what attributes were mandatory at that point, and whether an entry crossed to the new definition. A silent rewrite would make the past record appear to have always carried a condition it did not carry.

A schema governed vocabulary, not the world it described

The pilot’s design makes a final separation visible. Common definitions can improve exchange between independent systems. They do not settle the truth of an address, the identity of a person, the authority of a directory administrator, the privacy of a value, or the result of a lookup in a specific deployment.

That restraint is what gives the document its continuing historical value. The schema could coordinate a language without claiming to become the thing named by that language. Its evolution rule did the same: it gave optional refinement a path, but declined to let a changed mandatory meaning borrow the old class’s history without disclosure.

Sources and evidence limits

This article uses RFC 1274 — The COSINE and Internet X.500 Schema. It supports the 1991 status and scope of the pilot schema, its common-versus-local definition policy, conformance requirements and desired behaviours, and its optional-versus-mandatory class-change procedure. It does not establish a live directory, a particular DSA or DUA, a directory value’s accuracy, identity, authorisation, privacy, matching, enforcement, display, compatibility or current service outcome.