The run did not exercise this test: no Stateless Reset was triggered in the 12s after the endpoint forgot the connection, so there was nothing for the client to recognise: 0 datagram(s) arrived in that time.
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
- xquic — Alibaba xquic + BoringSSL, 2060a44
- Test
- Stateless reset —
q-stateless-reset - Clause
- RFC 9000 §10.3 (MUST)
- Class
- correctness — Rejected something invalid, with the code the RFC names.
- Required behaviour
- Recognise the token in the last 16 bytes of the datagram, enter the draining period, and send no further packets on the connection. The packet cannot be authenticated, so there is nothing to reply with and nothing to report to the peer — continuing to send is the failure §10.3.1 names.
- Measured
- 2026-10-27
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-stateless-reset"]'