# RFC 0179: Root `preferredVersion` — the v1.x additive half of protocol-major negotiation > Source: https://openwop.dev/rfcs/0179-root-preferred-version.html · OpenWOP, the open-source protocol for multi-agent workflow orchestration. CC BY 4.0. | Field | Value | | ----------------- | --------------------------------------------------------------- | | **RFC** | 0179 | | **Title** | Root `preferredVersion` (optional in v1.x): the `.` a host serves to a header-less request, which MUST be a member of `protocolVersions[]` and equal `protocolVersion` while the host serves one major — the field RFC 0172 §A.1 requires at v2 and said would be "filed separately" so hosts can advertise it before the cut; the 2.0.0 suite's `--target-major` default reads it | | **Status** | `Accepted` | | **Author(s)** | David Tufts (@davidscotttufts) | | **Created** | 2026-09-03 | | **Updated** | 2026-09-03 (`Draft → Active` in the filing PR. **Comment window waived** (additive, 7-day) under `GOVERNANCE.md` §"Sole-steward operation" and logged in `MAINTAINERS.md`.) · 2026-09-03 (filed; v2 charter Phase 3, P3-A — the /architect pass on the Phase 3 plan found the suite defaulting on a field no v1 host could advertise) · 2026-09-18 (`Active → Accepted`). **Evidence tier: tier-1 — steward-verified**, corroborated by a live tier-2 fetch. The advertisement half is checked against the live `/.well-known/openwop` as `GOVERNANCE.md` §"Deployed, not merged" requires, on both production hosts, at 2026-09-18T06:08Z. The scenario half rests on `openwop-host-v2-reference` build `commit:87cb8a007d05`, suite 2.4.2, `witnessSha256 9217e347b85f…`, signed `v2-reference-3`, all three profiles certified. **Stated plainly:** that host is tier-1 by `GOVERNANCE.md` §"Acceptance evidence tiers" (a reference host in `openwop-examples`), but it is run from the pinned example and its bundle's `discovery.url` is `http://127.0.0.1:3838` — it is not a host that serves traffic, and this acceptance does not call it deployed. and on `myndhyve` build `commit:46917218d19f`, suite **2.1.7** (five of the 79 scenario files applicable at major 2 were not yet in that suite and have no row), both claimed profiles certified. | | **Affects** | `schemas/capabilities.schema.json` (root `preferredVersion`, optional, RFC 0165 §A grammar), `spec/v1/capabilities.md` §"Document-root layout" (one row), suite `1.162.0 → 1.163.0` (packed content) | | **Compatibility** | `additive` (COMPATIBILITY.md §2.1): one optional root field; no existing field, MUST, or error changes | | **Supersedes** | — | | **Superseded by** | — | ## Summary RFC 0172 §A.1 makes `preferredVersion` a required v2 root field and its §A.3 makes it the header-less default for major negotiation; RFC 0176 §C.1 keys the well-known representation on it; RFC 0168 §D.3 defaults the suite's `--target-major` from it. RFC 0172 §Compatibility said the v1.x additive half "is filed separately" and nothing filed it. This RFC is that half. ## Motivation `schemas/capabilities.schema.json` carries `preferredVersion` only under `a2a` and `mcp` (`:2898`, `:3390`); no v1 host can advertise the root field; a dual-advertising host through the overlap would have `protocolVersions: ["1.11", "2.0"]` and no way to say which it serves without a header. ## Proposal **§A.1** `preferredVersion` (string, RFC 0165 §A grammar `^(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)$`) is an OPTIONAL root field in v1.x. When present it MUST be a member of `protocolVersions[]` (when that is present) and, on a host serving a single major, MUST equal `protocolVersion`. **§A.2** A v1 consumer ignores it. A v2 consumer (suite 2.0.0) reads it as the header-less default; absent, the consumer's default is `max(protocolVersions[])`, else `protocolVersion`. **§A.3** The A2A precedent (`a2a-integration.md:349`, the `preferredVersion` card served without an `A2A-Version` header) is the model. ## Compatibility `additive`. The v1 suite adds no assertion; the schema accepts documents with or without the field. ## Conformance Suite 1.163.0: schema acceptance only (`spec-corpus-validity` compiles the field). Suite 2.0.0: `dual-stack-negotiation` (RFC 0172) reads it. ### Falsifiability — one row per normative requirement | Requirement | Observable | Who can cause the condition | Verdict | | --- | --- | --- | --- | | §A.1 member of `protocolVersions[]`; equals `protocolVersion` on a single-major host | `openwop.requirement.0172.preferred-version-default` — its `.member` leg asserts both clauses by name, `executed-pass` on BOTH certified bundles | the suite, unaided | witnessable — unaided | ## Alternatives considered 1. Default `--target-major` from `max(protocolVersions[])` only. Kept as the fallback; a host that serves two majors and prefers the older one cannot say so without the field. ## Unresolved questions None. ## Acceptance criteria - [x] `Draft → Active`: schema field; capabilities.md row; suite 1.163.0. (This PR.) - [x] `Active → Accepted`: openwop-app advertises it (Phase 4 leg) and the 2.0.0 `dual-stack-negotiation` scenario reads it. — evidence: **both halves, measured 2026-09-18T06:08Z.** `GET https://app.openwop.dev/.well-known/openwop` with `OpenWOP-Version: 2.0` serves `"preferredVersion": "1.1"` inside `"protocolVersions": ["1.1", "2.0"]`; MyndHyve corroborates with `"preferredVersion": "1.0"` in `["1.0", "2.0"]`. `openwop.requirement.0172.dual-stack-negotiation` is `executed-pass` (4 legs) and `…preferred-version-default` `executed-pass` (3 legs) on BOTH certified bundles. Recorded honestly: openwop-app's own bundle also carries those rows, but it is not certified (3 blocked rows, RFC 0168 §E.1), so it supplies no §B.1 witness — the witnesses are the reference and MyndHyve bundles, and the advertisement half is the live fetch above. ## References - RFC 0165 §A; RFC 0172 §A.1/§A.3/§Compatibility; RFC 0176 §C.1; RFC 0168 §D.3; `spec/v1/a2a-integration.md:349`