Read a long-lived standard closely and you'll find things no engineer would ever design: options nobody implements, two ways to express the same thing, extension points that go nowhere. Those aren't mistakes. They're the shape of an agreement, in the same way a planning application is the shape of an argument with the neighbours.
What a standards body is¶
A room containing competitors. Each one has shipping implementations, existing customers and commercial interests, and between them they have to produce one document.
A feature in the final text usually means one of three things:
- Everybody agreed it was necessary.
- One participant had already shipped it and wouldn't take it out.
- Two participants disagreed, and the compromise was to make it optional.
The third case is where interoperability goes to die. An optional feature is one half the implementations have, so every implementation has to handle both cases and the test matrix doubles. Stack up enough optionality and "conforming" stops implying "interoperable" at all.
Why you should care as an engineer¶
It changes how you read the document and what you then build.
Expect the ambiguity to be on purpose. If a specification is vague about behaviour in some case, the most likely explanation is that the participants couldn't agree and vagueness was the settlement. Don't assume you've misread it; you probably haven't.
Implement the common subset, not the whole document. Conformance to the full standard is often neither achievable nor useful. What matters is the subset used by the implementations you have to talk to.
Test against implementations, not the spec. The spec is what was agreed in the room. The implementations are what exists in the world, and where the two differ, the implementations win every time.
The counter-example worth holding onto¶
WireGuard shows the other path: one cipher suite, no negotiation, no options. The result is small, analysable and free of downgrade attacks.
That was possible because one party designed it, outside a standards process, with the authority to say no. The trade is that it can't accommodate anybody who needs something different. Compare TLS, which has to serve everybody, and whose history of downgrade attacks is substantially a history of negotiation complexity.
Neither model wins outright. A protocol that has to bridge competing interests across a whole industry can't be designed by one party. A protocol that can afford to be narrow should be.
Reading a standard as politics is a practical skill, and it lets a small organisation punch above its weight in a room full of incumbents.
You can participate. Standards bodies are startlingly open compared with their reputation. Mailing lists are public and most working groups will take a well-argued implementation report. An engineer who turns up with "we built this and here is where your text is ambiguous" carries weight no amount of market share confers. A two-person company can get a sentence changed in a document that will govern a billion devices.
Interoperability is what makes competition possible at all. Every market where you can swap a supplier without rewriting your systems exists because somebody fought this fight: changing electricity provider, buying a phone that works on any network, sending mail between two companies' servers. The next decade's version is fought over the interfaces into cloud services, and winning it means a business can move its workload without rebuilding it. That is decided in committee rooms, not markets.
What becomes cheap is entering. A published, testable baseline means a new implementation can be built by a few people and trusted on arrival, which is how you get competitors to the three or four firms that currently own a layer. Where that baseline is missing, the incumbent's behaviour is the standard, and the cost of entry is reverse-engineering it.
For engineering itself, the toil a real baseline removes is compatibility shimming: the per-vendor quirks table, the user-agent sniffing, the "works with provider X only" integration code. Some of the most dispiriting work in the industry, and it exists because a negotiation failed.
A standards body with a membership fee, weighted voting and a work programme set by whoever can afford to send people full-time offers no neutrality whatever. It is a venue where the three largest implementers reach an accommodation and publish it, and the other participants get a vote on the wording. The tell is a specification that is enormous, that nobody has implemented completely and whose only two complete-ish implementations belong to firms that sat on the committee. The standard has stopped lowering the barrier to entry and started defining it, because the cost of conformance is the moat.
The sharper version is a standard that mandates a service. Any specification whose implementation requires calling a particular registry, obtaining a certificate from a recognised authority or attesting to a central validation endpoint has placed a company in the middle of a protocol, permanently. That is how a technical document becomes a toll booth, and it is usually introduced for good reasons: trust, revocation, abuse prevention. So the question to ask of a new standard is not about its design quality. Ask whether a competent engineer could implement it fully, from the document, without anyone's permission. If not, name who grants permission; that is the chokepoint, and there is always one.
Privacy gets decided in these rooms too, mostly by default. Identifier formats, telemetry fields, what a conforming implementation must report and to whom: standards decisions with enormous downstream consequence, settled by people optimising for operational convenience, with nobody in the room representing the person the identifier belongs to.
Here at AxisOps we build on standards we can implement from the document, and we treat a required call to somebody's endpoint as a design smell rather than a feature. Where the open implementation exists and is keeping pace, use it and say so. Where it is losing, go and read the mailing list, because the decision that matters was taken there by the people who turned up.
RISC-V is testing the alternative¶
RISC-V's modularity is this same tension in current dress. An open ISA assembled from optional extensions has enormous flexibility and a real fragmentation risk, and platform profiles exist to impose the "no" that a single vendor would simply have issued over lunch.
Whether an open standards body can enforce a baseline as effectively as ARM's commercial authority is a more interesting question about RISC-V than any individual extension. My bet is that it can, but only if the large implementers find fragmentation more expensive than differentiation, and that will be decided by a handful of profile votes rather than by anything technical. Marked as a view.