closed cleanly after receiving a frame of unknown type. RFC 9000 §12.4 requires a connection error of type FRAME_ENCODING_ERROR: QUIC reserves no ignorable frame types, and an unknown frame carries no length, so nothing after it in the packet can be parsed.
The client did something the clause forbids, or failed to do what it requires.
What was measured
- Client
- xquic — Alibaba xquic + BoringSSL, 2060a44
- Test
- Unknown frame type in a 1-RTT packet —
q-reserved-frame - Clause
- RFC 9000 §12.4 (MUST)
- Class
- correctness — Rejected something invalid, with the code the RFC names.
- Required behaviour
- Close the connection with FRAME_ENCODING_ERROR. Unlike HTTP/3, QUIC reserves no ignorable frame types — §12.4 makes an unknown frame a connection error, so ignoring it is the failure here.
- Measured
- 2026-09-18
Reproduce it
The suite is the judge, so the reproduction is to point the same client at the same test and let the server report what it saw.
SESSION=$(curl -sX POST https://conformance.pqcrypta.com/session | jq -r .id)
# then drive xquic at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-reserved-frame"]'What this suite is · The full grid · All clients · All tests · Findings