open-standards/wai/live-conformance/carousel

live-conformance/carousel — when each object passes, and when it is held

The corpus of extensions/carousel.md §10, in one file, vectors.json.

Provenance. Generated here by wai_carousel_vectors gen (wai-rs, feature carousel), from Ed25519 keys on fixed 32-byte seeds, constant times, and envelopes of exact lengths whose payloads are opaque test bytes written by the generator; no media and no input from outside this repository.

keys names every key by its role, as 64 lowercase hexadecimal digits: the publisher's (publisher, did:web:publisher.example#d1), a second key of its origin (publisher_d2), a sink's (sink, signing under its did:key), and the roots of the test key logs (log_root, other_log_root).

verdicts (§6) are each one group of four objects, of 3,200, 896, 288 and 200 octets, as a verifier holds it:

• group: the group receipt (jwp-receipts §2.4.1) and objects, each object receipt with its envelope in hexadecimal where the verifier holds the bytes, or null;
• claims: the transmission and schedule claims, each in its canonical wire form, each signer's in the order of its chain;
• loss_ppm and overhead: the loss bound and overhead (§2); statement: null, or a statement offered (§6.4): {"kind": "object", "bearer_id", "index", "by_ms"} or {"kind": "group", "bearer_id", "by_ms"};
• outcome: refuse and its reason; or verdict with each object's verdict, each claim's (declared, stands, extended, set-aside reason=…, or reject step=… reason=…), a line for each entry of each schedule that stands — its bearer_id, leaf_index, pass, available_ms, bytes_sent and failure_one_in — and the statement's result.

claims are each one schedule claim and its outcome through jwp-receipts §3.1 steps 1–4: accept, or reject step=… reason=…. Among them every bound of §5.1, §5.2, §5.4, §5.5 and §4.2 rule 3.3 that a schedule can reach, met and passed.

plans (§7) are each an entry of a schedule, the instant at_ms a receiver is at, its loss_ppm and overhead, and held, the encoding symbols it holds of each source block. outcome: plan, with the passes it listens to (each pass, start_ms and end_ms), complete_ms and listen_ms; or refuse and its reason.

inband (§8.2) are each what a receiver acquired on an instance: its bearer_id, the group receipt, the claims in chain order, and the key logs, each a revision's text keyed by the origin it was acquired for. outcome: refuse and its reason, for a group that fails; or inband with each claim's label, set (suffices, or the reason it does not) and inband_ms, the interval of the schedule that stands where the set suffices, null otherwise.

Everything is synthetic. Keys attest nothing; bearer instances use the example URN namespace (urn:example:) and origins a reserved example domain. Each case states the outcome it was written to have, declared in the generator, never copied from a verifier.

wai_carousel_vectors verify and tests/carousel.rs check that the file regenerates byte for byte and that wai-rs reaches every stated outcome; the test also decodes each RaptorQ object a case holds available with an independent implementation of RFC 6330, and each Raptor object with one of RFC 5053, from what a receiver within the case's loss bound holds. ../carousel_verify.py is the second implementation, written from the extension's text, which also mutates copies of the corpus and drops each of its own checks in turn and requires each to be caught. ../../claim-conformance/claim_verify.py carousel vectors.json reads every claim through jwp-receipts §3.1 steps 1–4.