You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[cpp-RCP-05] Declared RELAY spec version (1.11) and section citations are stale against governing spec v2.0 #74
Location: include/relay/relay.hpp:27 (kRelaySpecVersion); section citations scattered across include/rcp/acf.hpp, include/rcp/avtp.hpp, include/rcp/e2e.hpp, and include/rcp/rcp.hpp (e.g. ~lines 101-111, 250-259).
Finding: kRelaySpecVersion is currently pinned to "1.11". The RELAY spec that governs this ecosystem is now at v2.0, which made a significant structural change: it retired the Registry/Zone model these headers were originally built around and renamed the RCP-facing interface to Controller. Several headers still cite section numbers from the pre-2.0 numbering scheme that no longer correspond to anything in the v2.0 document — e.g. references to a "module-name registry" section and to a "§18.2"-style Context/StatusChannel section that don't exist under that numbering in v2.0. A prior issue (#33, closed) already tracked and fixed a smaller one-point gap (1.10 → 1.11); this is a materially larger gap since it spans a breaking spec revision, not just a point release.
Recommendation: Bump kRelaySpecVersion to the current v2.0 value, and do a full pass re-verifying every in-repo §-citation against the actual v2.0 section numbering, correcting or removing anything (like the retired module-name-registry references) that no longer has a v2.0 counterpart.
Verification: Independently re-read include/relay/relay.hpp:27 and the citing headers against current HEAD (commit 4b9449a, 2026-07-29). Confirmed kRelaySpecVersion = "1.11" and confirmed the stale section citations are still present in the header comments. I relied on this project's own tracked understanding of the RELAY spec's v2.0 status (Registry/Zone retirement, Controller rename) rather than re-deriving it from the RELAY repo directly in this pass.
Filed from the 2026-07-29 ecosystem audit register; independently re-verified against current HEAD before filing.
Correction — the specific section-citation examples in this issue are wrong; only the version-string staleness holds.
After filing this, I got direct access to the current RELAY spec text (v2.0, spec/relay-spec.md) and checked the specific section citations this issue called out as "referencing sections that don't exist." They're actually all still valid in v2.0:
§13.7.2 ("Standard module-name registry") exists in v2.0 and its table explicitly lists avtp and acf as the required module names for RCP's AVTPDU-framing and ACF-message-format concerns — exactly what acf.hpp/avtp.hpp/e2e.hpp cite it for.
§18.2 ("C++" language bindings) exists in v2.0 and explicitly names rcp::Context/rcp::StatusChannel as the expected cpp-RCP aliases for relay::Context/relay::Channel<Status> — exactly what rcp.hpp's Context/StatusChannel sections cite it for.
§17, §19.4, and §20.3 (Conformance Requirements, Machine-readable version, Conformance tiers) also all exist in v2.0.
So the "cited sections do not exist" framing in this issue is incorrect for the specific examples given — please disregard that part.
What does still hold, and is the real defect here: kRelaySpecVersion in include/relay/relay.hpp is pinned to "1.11" while the governing spec's spec/version.json reports "version": "2.0". That's a genuine, and fairly large, staleness gap (v2.0 is a breaking revision — it retired the RCP Registry/Zone model per §8.5, which cpp-RCP's own rcp.hpp still partially reflects as a separate, already-filed issue). The fix suggested in the original body (bump kRelaySpecVersion to the current value) is still the right one — I'd just drop the "and re-verify every §-citation, several of which are stale" framing, since spot-checking the citations this issue actually named shows they're fine.
Apologies for not checking this against the real spec text before filing — I initially relied on general project context about the v2.0 Registry/Zone retirement rather than checking the specific section numbers, and should have verified those directly.
Fixed by #93 (merged), which was not auto-linked because the PR description's bold markdown around the issue numbers broke GitHub's closing-keyword parser.
Activity
SoundMatt commentedon Jul 30, 2026
Correction — the specific section-citation examples in this issue are wrong; only the version-string staleness holds.
After filing this, I got direct access to the current RELAY spec text (v2.0,
spec/relay-spec.md) and checked the specific section citations this issue called out as "referencing sections that don't exist." They're actually all still valid in v2.0:avtpandacfas the required module names for RCP's AVTPDU-framing and ACF-message-format concerns — exactly whatacf.hpp/avtp.hpp/e2e.hppcite it for.rcp::Context/rcp::StatusChannelas the expected cpp-RCP aliases forrelay::Context/relay::Channel<Status>— exactly whatrcp.hpp'sContext/StatusChannelsections cite it for.So the "cited sections do not exist" framing in this issue is incorrect for the specific examples given — please disregard that part.
What does still hold, and is the real defect here:
kRelaySpecVersionininclude/relay/relay.hppis pinned to"1.11"while the governing spec'sspec/version.jsonreports"version": "2.0". That's a genuine, and fairly large, staleness gap (v2.0 is a breaking revision — it retired the RCPRegistry/Zonemodel per §8.5, which cpp-RCP's ownrcp.hppstill partially reflects as a separate, already-filed issue). The fix suggested in the original body (bumpkRelaySpecVersionto the current value) is still the right one — I'd just drop the "and re-verify every §-citation, several of which are stale" framing, since spot-checking the citations this issue actually named shows they're fine.Apologies for not checking this against the real spec text before filing — I initially relied on general project context about the v2.0 Registry/Zone retirement rather than checking the specific section numbers, and should have verified those directly.
SoundMatt commentedon Jul 30, 2026
Fixed by #93 (merged), which was not auto-linked because the PR description's bold markdown around the issue numbers broke GitHub's closing-keyword parser.