Profiles and Conformance Classes: Narrowing a Standard Without Editing It

A general standard defines the union of behaviours its participants could agree on. Each participant implements an intersection, chosen by its own product requirements. Two implementations of the same general standard may therefore satisfy the same document while sharing almost no functionality, and the standard’s promise of interoperability is honored only by the clauses both chose.

A profile is the remedy: a document that selects a subset of a base specification, fixes the choices the base left open, and declares that the combination is required for a named purpose. The base standard remains unchanged. The profile is a separate document with its own ballot, and its authority derives entirely from the base’s.

The conceptual framework was written down as ISO/IEC TR 10000, which distinguished base standards, functional standards, and profiles, and gave profiles a taxonomy. The technology it was written for did not survive commercially, but the structure did, and it describes what every modern profile actually does.

What a profile is permitted to change

A profile has two operations available to it, and nothing else.

Selection: the profile names which optional features of the base are required, which are permitted, and which are forbidden within the profile. A base with 30 optional capabilities admits a profile that requires 8, permits 4, and forbids the rest. The base’s optionality remains in the base; the profile does not delete anything.

Restriction: the profile fixes values the base left implementation-defined, or narrows ranges the base allowed broadly. A base that permits timers between one and sixty seconds can be profiled to a single value for a closed network. A base that allows either encoding of a string may be profiled to one.

A profile cannot add a requirement the base does not permit, and it cannot contradict the base. Where a profile appears to add functionality, the addition is an optional base feature being made mandatory. This constraint is what keeps profiles composable: a profile of a base specification remains consistent with the base, so an implementation that conforms to both is possible by construction.

The common defect in practice is a profile that states a requirement in its own words rather than by reference to base clauses. Wording drifts, and a requirement restated in a profile is a new requirement with its own ambiguity, whose resolution now requires its own errata process.

Conformance classes and the shape of the ladder

A conformance class is a named set of requirements within a single document, and it lets one specification serve several markets without forking. The pattern is familiar from POSIX-style documents: a base class covering a minimal set of interfaces, with further classes adding units that a particular application domain needs.

Two properties matter to an implementer. First, classes are normally cumulative or nested, so that an implementation claiming a higher class also satisfies the lower ones; a ladder allows a product to state its capability as a single name. Second, the classes must partition cleanly, meaning the boundary between two adjacent classes is a list of named requirements rather than a judgement. A class defined by “the functionality typically required for real-time applications” is not a class; it is a theme.

The design cost of classes is that they multiply the test matrix. A document with four classes requires either four suites or one suite with four configurations, and the combinations that fall between classes are tested by whichever configuration the suite’s author picked. Implementers claiming an intermediate combination are outside the certification machinery even though every individual requirement they satisfy is certified somewhere. The verdicts a suite issues are themselves a policy choice, as the account of conformance testing explains.

Why profiles proliferate

The incentive structure pushes in one direction. A base standard accommodates the union of what vendors will accept, so optionality accumulates. Each market then needs a narrower target: a profile that makes a compliance claim meaningful to a buyer, and a test suite that can be run in a day rather than a month.

The consequences accumulate too.

Profiles become the operative specification. An implementer building to a market does not read a base standard; it reads the profile, and the profile is what gets tested. This is functionally identical to writing a new standard, and the base’s authority is nominal.

Profiles diverge from their bases as the base is revised. A profile written against a revision pins that revision. When the base gains features, the profile must be revised to permit them, and a profile that is not actively maintained becomes a prescription for an obsolete subset. Implementations that track the base and implementations that track the profile then disagree about what a conforming product is, without either being wrong.

Profiles fork into incompatible siblings. Two industry groups profiling the same base for adjacent markets choose different restrictions, which is correct — different constraints force different values. The result is that a device supporting both must implement two profiles that may demand contradictory behaviour from the same option code, and the device must know which profile a peer expects before it can interpret a byte.

Chaining is the fourth mechanism people reach for and it is the one that damages the guarantee. A profile may incorporate another profile, producing a chain. A chain of three profiles is a document whose requirements can only be recovered by transitively resolving three subsets, and where the base specification’s own optionality resurfaces at every level. Tools that check conformance must implement the resolution, and a single mis-ordered reference silently changes the requirements.

Analysis of a profile’s promise

A profile’s value to an implementer is exactly the strength of the claim it makes possible. A profile that says “conforming to the base, with these twelve requirements mandatory” gives a buyer something to check: whether each of the twelve is present. A profile that says “targeted at a market segment” gives nothing checkable and is not doing the work a profile exists to do.

The discipline that makes a profile useful is therefore negative. The document must state which base optional features are excluded, not only which are included, because exclusion is what makes two conforming products guaranteed to share functionality. A profile that specifies only a required core, without forbidding the optional features that make behaviour unpredictable, has narrowed the test surface without narrowing the behaviour.

Maintaining a profile against a moving base

A profile’s maintenance load is set by the base’s revision rate, not its own. Every base revision creates a decision per clause: does the profile’s restriction still make sense, has the base made the restricted behaviour normative, has it added a feature the profile should now require? A profile that is not revised alongside its base slowly becomes a specification of an obsolete subset, and implementers discover the lag when a base conference or a test suite exercises functionality the profile still forbids.

The cheap mechanism for avoiding this is a statement in the profile of the base revision it applies to, plus a published conformance matrix mapping profile requirements to base clauses. The matrix is what makes the profile checkable by a tool rather than by reading two documents side by side, and it is the artefact that lets a conformance suite be generated from the profile instead of hand-written against it.

The relationship between the profile, the base, and the conformance suite is the same three-layer structure discussed in the account of conformance laboratories, applied recursively. The profile narrows the abstract test suite, and the suite’s derivation gap reappears at the narrowed level. Profiles reduce the space in which independent implementations can differ; they do not eliminate it, and the remaining space is where interoperability events still find defects decades into a standard’s life.