Protocol Version Negotiation¶
Interoperability protocol — instantiates Versioned Evolution
Lets two independently-versioned parties discover their overlapping supported versions and agree on one to speak — at connection time — so systems on different versions can still interoperate without upgrading in lockstep.
When two systems that evolve on their own schedules need to talk, neither can assume the other is on the same version. Protocol Version Negotiation resolves that at the moment of interaction: before exchanging any real messages, each party advertises the versions it supports, and the two agree on a single mutually-supported version to use for the exchange. Its defining move is that the compatibility decision is made at runtime, between the actual parties, on the basis of what each one really supports — not fixed in advance by an authoring convention or read out of a stored record. This is what lets a heterogeneous population of clients and servers, old and new, keep interoperating while each upgrades independently, instead of forcing a flag-day where everyone must move at once.
Example¶
A client and a server open a secure connection using TLS, a protocol that exists in several versions still in use. The client's opening message advertises the versions it can speak — say TLS 1.2 and 1.3. The server, which supports 1.1 through 1.3, applies the usual selection rule: pick the highest version both sides support. The intersection is {1.2, 1.3}, the highest is 1.3, and the session proceeds on 1.3. Had the client been an old device offering only 1.1, the intersection with a modern server that has dropped 1.1 would be empty — and the negotiation would fail the connection outright rather than fall through to a version one side can't honour.
Two things make this work, and neither is the version number itself: the parties advertise sets, not a single assumed version, and they fail closed when the sets don't overlap. The handshake also has to be protected, because an attacker who can strip the client's "I support 1.3" out of the advertisement can force both ends onto a weaker common version — a downgrade attack[n1] — so the agreed version is confirmed under integrity protection before real traffic flows.
How it works¶
- Advertise, don't assume. Each party announces the set (or range) of versions it supports, rather than presuming a shared one.
- Intersect and select. Compute the versions both sides support and apply a selection rule — usually the highest common version — to pick the one to use.
- Fail closed on no overlap. If the intersection is empty, refuse the interaction rather than proceed on a mismatched assumption.
- Bind the choice for the session. Lock the agreed version so both ends interpret every subsequent message the same way, and protect the negotiation itself so the choice can't be tampered into a downgrade.
Tuning parameters¶
- Selection policy — highest-common-version versus a conservative or preferred-list pick. Highest unlocks the newest features but is more fragile; conservative maximises reach across old peers.
- Advertised breadth — how many old versions each party still offers. Offering more interoperates with more peers but enlarges the legacy and attack surface.
- Negotiation scope — renegotiate per message, once per session, or cache a peer's capabilities. Per-session is cheap; finer scope is more adaptive but chattier.
- Fallback behaviour — hard-fail on no overlap versus degrade to a baseline "lingua franca" version. Degrading maximises connectivity but can quietly mask a real incompatibility.
- Downgrade protection — whether the handshake is integrity-protected against a forced downgrade. Stronger protection is safer but adds handshake complexity and cost.
When it helps, and when it misleads¶
Its strength is that it localises the compatibility decision to the one place both parties' real capabilities are known — the live connection — so a population of independently-upgrading actors can keep talking without a coordinated flag-day. It is what makes rolling upgrades and mixed-version fleets survivable.
Its failure modes live in the negotiation itself. The handshake is an attack and failure surface: an unauthenticated advertisement can be spoofed, and a downgrade attack can force both ends onto the weakest common version, so the negotiation must be integrity-protected rather than trusted.[n1] It also tends toward lowest-common-denominator lock-in — one laggard peer that never upgrades keeps the whole population negotiating down to an ancient version, which is why negotiation is not a substitute for a deprecation policy that eventually retires an old version floor. And a mis-declared support set produces the worst case: two parties "agree" on a version one of them cannot actually honour. The discipline is to authenticate and integrity-protect the handshake, fail closed rather than degrade silently, and pair negotiation with a deprecation policy so the negotiable floor keeps rising.
How it implements the components¶
Protocol Version Negotiation fills the cross-version interaction slice — the components that decide, at runtime, which version two parties use — not the ones that store, explain, or transform versions:
compatibility_rule— it enacts the compatibility rule live: the selection logic over both sides' supported sets is what determines whether, and on which version, two versions can interact.current_version_pointer— each party's advertisement is its declaration of which versions it currently supports and prefers in this context, resolved to the one in force for the session.version_acceptance_criterion— the selection rule is the criterion for what counts as an acceptable mutually-supported version (highest common, or none at all).
It does not record what a version contains (version_boundary, provenance_record — Dataset Version Registry), narrate what changed (change_log — Release Notes or Changelog), or move a dependent from an old version to a new one (migration_path — Schema Migration). This protocol chooses the shared version; siblings record, explain, and migrate between versions.
Related¶
- Instantiates: Versioned Evolution — it is the runtime layer that lets differently-versioned parties keep interoperating across the lineage.
- Consumes: Semantic Versioning (or any identifier scheme) supplies the comparable, ordered version labels the negotiation selects among.
- Sibling mechanisms: Semantic Versioning signals compatibility in the number; Schema Migration moves parties across a boundary this can't bridge. Dataset Version Registry · Version Control System · Release Notes or Changelog
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Protocol Version Negotiation operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it lets two independently-versioned parties discover their overlapping supported versions and agree on one to speak — at connection time — so systems on different versions can still interoperate without upgrading in lockstep.
Independent corroboration: The frozen evidence defines Protocol Version Negotiation as 'Lets two independently-versioned parties discover their overlapping supported versions and agree on one to speak — at connection time — so systems on different versions can still interoperate without upgrading in lockstep', so its operative form is Control, Automation & Runtime.
Nearest alternative: Protocol, Workflow & Routine — Protocol Version Negotiation includes features of a repeatable ordered procedure or handoff sequence that coordinates action, but its defining operation is a live operational control that automatically routes, enforces, adapts, or responds during execution.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Connection-time agreement on a mutually supported protocol version arose in network protocol and distributed-software compatibility engineering.
Review outcome: Independent reviewer agreement; high confidence.
Notes¶
Negotiation decides which version two parties speak; it does not translate between versions. When the supported sets don't overlap at all, negotiation's honest answer is to fail — and the job of bridging the gap passes to an adapter or translation layer, or to a migration that moves one party onto a shared version. Reaching for negotiation where translation is needed just produces a connection that agrees to fail.
[n1] A downgrade attack forces two parties to negotiate a weaker or older protocol version than both actually support, by tampering with the capability advertisement during the handshake — which is why version negotiation must be integrity-protected rather than trusted on its face. ↩a ↩b