869fd65efc
Carousel §4.1, §5.5: an entry's fec may be raptor (FEC Encoding ID 1), with RFC 5053's F, T, Z, N and Al, held to its fields and to its block sizes, 4 to 8,192 source symbols, with ESIs in 16 bits. 3GPP TS 26.346 §7.2.2 requires a receiver of MBMS download to support the code. Carousel §5.3: RFC 5053 states no bound on a decoder's failure. An independent implementation failed on 14 to 31 blocks in 100 at K + 2, so a Raptor block is held at K and a margin set by measurement, 8, 16 or 28 at overhead 0, 1 or 2, and failure_one_in is null. tests/carousel.rs decodes each Raptor object a case holds available with that implementation, a new development dependency, holds a fixed sample of it to the measurement, and keeps the measurement as an ignored test. no-code stays the default, and carousel §11 keeps the IETF's disclosures on RFC 5053 for implementers. Co-Authored-By: Claude Opus 5.5 <[email protected]>
56 lines
3.7 KiB
Markdown
56 lines
3.7 KiB
Markdown
# live-conformance/carousel — when each object passes, and when it is held
|
||
|
||
The corpus of [`extensions/carousel.md`](../../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.
|