The run did not exercise this test: the client abandoned the handshake (timed out) without a CONNECTION_CLOSE this endpoint could read. It certainly saw the parameter — that travels in the handshake — but §7.4 asks for a rejection carrying TRANSPORT_PARAMETER_ERROR, and none was observed. A close that was sent and lost cannot be told apart from one that was never sent.
The suite could not establish what this client does here. That is a shortcoming of the run rather than anything about the client, and every one of these is on our list to remove.
What was measured
- Client
- quinn — quinn + h3 (our fork), noq fork
- Test
- Transport parameter carrying a value the specification forbids —
q-invalid-transport-param - Clause
- RFC 9000 §7.4, §18.2 (MUST)
- Class
- correctness — Rejected something invalid, with the code the RFC names.
- Required behaviour
- Close the connection with TRANSPORT_PARAMETER_ERROR. §18.2 makes an ack_delay_exponent above 20 invalid, and §7.4 is a MUST: "An endpoint MUST treat receipt of a transport parameter with an invalid value as a connection error of type TRANSPORT_PARAMETER_ERROR." Distinct from a *duplicate* parameter, which the same clause makes only a SHOULD — this port sends one parameter, once, with a value outside its permitted range. The parameter travels in the handshake, so every client that connects here reads it. Only a client that answers with a CONNECTION_CLOSE this endpoint can read is scored: one that simply abandons the handshake is recorded as inconclusive, because a close that was sent and lost looks exactly like one that was never sent.
- 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 quinn at the test URL and read the verdict:
curl -s https://conformance.pqcrypta.com/report/$SESSION.json | jq '.results["q-invalid-transport-param"]'