Problem
rcp/acf.hpp's wire codec places byte_bus_id in a full 8-bit byte with no bit-sharing, per include/rcp/avtp.hpp:177 (using ByteBusId = uint8_t;) and the encode/decode functions in include/rcp/acf.hpp (encode_acf_message_info ~line 136, decode_acf_message_info ~line 156), which write/read it as a whole header byte (out10[4]/in10[4]). The audit that raised this flagged that OPEN Alliance TC18 defines byte_bus_id as an 11-bit packed field (extraction §2.4) — if that citation is accurate, this repo's codec caps addressable endpoints at 256 instead of 2047 and cannot be bit-for-bit wire-compatible with a real TC18 peer on this field. (I don't have access to the actual TC18 spec text to independently verify the 11-bit figure — flagging the citation as-is; worth confirming against the source spec before scoping any fix.)
Separately, and more clearly actionable: this scoping choice is disclosed, but only at the header-comment level, not in the README's summary table. avtp.hpp, acf.hpp, and 10 other headers (e2e.hpp, regmap.hpp, lifecycle.hpp, mock.hpp, deadline.hpp, powerstate.hpp, record.hpp, sim.hpp, udp.hpp, watchdog.hpp) each carry a comment stating that "full bit-for-bit wire conformance against other TC18 implementations is not claimed." README.md:80-81 describes <rcp/avtp.hpp> and <rcp/acf.hpp> only as "TC18 wire codec, framing half" / "TC18 wire codec, message half" with no such caveat, and no other part of the README surfaces it either. A reader of just the README's API summary table would reasonably assume full TC18 wire compatibility.
ROADMAP.md's Phase 13 entry (and the v2.6.0 milestone note, ~line 550) independently acknowledges "full wire-level conformance against other TC18 implementations is still not claimed," so this is a known, long-standing, apparently-intentional scoping decision — not a forgotten TODO. The gap here is that the README's public-facing API table doesn't carry the same caveat that the code and roadmap already state.
Why it matters
Anyone selecting rcp/avtp.hpp/rcp/acf.hpp off the README's table alone, without reading ROADMAP.md or the header source, could reasonably assume drop-in wire compatibility with third-party TC18 stacks and only discover otherwise (e.g. via the byte_bus_id width, if the 11-bit citation is accurate) at integration time.
Suggested fix
- Add the existing "full bit-for-bit wire conformance ... is not claimed" caveat (or a short pointer to ROADMAP.md's Phase 13 notes) to the README table rows for
<rcp/avtp.hpp> and <rcp/acf.hpp>, matching what's already disclosed in-header.
- Separately, verify the TC18 spec's actual
byte_bus_id width against the extraction cited (§2.4); if it is indeed 11 bits and full wire conformance becomes an intended future goal, track widening ByteBusId as its own follow-up rather than folding it into this docs fix.
Problem
rcp/acf.hpp's wire codec placesbyte_bus_idin a full 8-bit byte with no bit-sharing, perinclude/rcp/avtp.hpp:177(using ByteBusId = uint8_t;) and the encode/decode functions ininclude/rcp/acf.hpp(encode_acf_message_info~line 136,decode_acf_message_info~line 156), which write/read it as a whole header byte (out10[4]/in10[4]). The audit that raised this flagged that OPEN Alliance TC18 definesbyte_bus_idas an 11-bit packed field (extraction §2.4) — if that citation is accurate, this repo's codec caps addressable endpoints at 256 instead of 2047 and cannot be bit-for-bit wire-compatible with a real TC18 peer on this field. (I don't have access to the actual TC18 spec text to independently verify the 11-bit figure — flagging the citation as-is; worth confirming against the source spec before scoping any fix.)Separately, and more clearly actionable: this scoping choice is disclosed, but only at the header-comment level, not in the README's summary table.
avtp.hpp,acf.hpp, and 10 other headers (e2e.hpp,regmap.hpp,lifecycle.hpp,mock.hpp,deadline.hpp,powerstate.hpp,record.hpp,sim.hpp,udp.hpp,watchdog.hpp) each carry a comment stating that "full bit-for-bit wire conformance against other TC18 implementations is not claimed."README.md:80-81describes<rcp/avtp.hpp>and<rcp/acf.hpp>only as "TC18 wire codec, framing half" / "TC18 wire codec, message half" with no such caveat, and no other part of the README surfaces it either. A reader of just the README's API summary table would reasonably assume full TC18 wire compatibility.ROADMAP.md's Phase 13 entry (and the v2.6.0 milestone note, ~line 550) independently acknowledges "full wire-level conformance against other TC18 implementations is still not claimed," so this is a known, long-standing, apparently-intentional scoping decision — not a forgotten TODO. The gap here is that the README's public-facing API table doesn't carry the same caveat that the code and roadmap already state.
Why it matters
Anyone selecting
rcp/avtp.hpp/rcp/acf.hppoff the README's table alone, without reading ROADMAP.md or the header source, could reasonably assume drop-in wire compatibility with third-party TC18 stacks and only discover otherwise (e.g. via thebyte_bus_idwidth, if the 11-bit citation is accurate) at integration time.Suggested fix
<rcp/avtp.hpp>and<rcp/acf.hpp>, matching what's already disclosed in-header.byte_bus_idwidth against the extraction cited (§2.4); if it is indeed 11 bits and full wire conformance becomes an intended future goal, track wideningByteBusIdas its own follow-up rather than folding it into this docs fix.