The change of wai/prior-carriage-spec (98192fe63..26834bb4c, 6 commits), on the fix branch: its changelog entries as files of wai/changes/, its wai-conformance.yml edits as step files, corpus files and test tags, and every other file as the branch has it. - e5db9b313 wai: where a parameter set is fetched — set roots, location hints, and <base> defined - 29fe43ea2 wai: a parameter set as an RFC 9842 compression dictionary, with a vector a stock client checks - faaeb6c73 wai: when a parameter set is worth holding — amortisation charged per sink, bootstrap and generations - 9a820db4a wai: a parameter set's usage statement, sealed sets released by key, leakage, and the privacy of held sets - 89a9f9924 wai: the chunk-tree prior form, wai.prior.tree — a set verified piece by piece from any peers - 26834bb4c wai: one playlist line of set roots, inner forms as the layouts list them, and a listing's usage statement read or the set refused Co-Authored-By: Claude Opus 5.5 <[email protected]>
6.9 KiB
live-conformance/prior-carriage — where a parameter set is fetched, how it is delivered, when it is worth holding, who may read it, and how it verifies by range
The corpus of extensions/prior-carriage.md §15 to §19
and extensions/http-delivery.md §8.7, §8.8 and §12.5:
vectors.json and the files under files/.
Provenance. The parameter sets are files other corpora commit, named by their paths from
this directory and pinned by their SHA-256: the trained WSR1 priors generic and title in
the safetensors form of ../prior-forms/ (title was fine-tuned from
generic, seeded is a seeded prior of the same shape), and the listing demo of
../../pin-conformance/ with the three stand-in files it names. The
hosts are .example names (RFC 2606); nothing here was fetched from a server.
vectors.json holds:
-
sets: each set the cases read, with its path, SHA-256 and length. -
roots: strings, and whether each is a set root (§8.7: an absolutehttpsURI with a host, no userinfo, query or fragment, whose path ends in/, at most 2048 bytes). -
hints: awai_priorsentry (moq-streaming-format §4.2) or a WAI multivariant playlist, and the hint read from it: the roots kept, in order, and the positions passed over asset_location_malformed(in a playlist, among the elements of the hint line'sVALUEsplit at every space). Some playlists also carry lines a reader ignores: a second line of the hint'sDATA-ID, one withLANGUAGE, and one whose attribute list does not read. -
fetches: a pin, thewai_priorsentry that states its hint, the roots of the sink's own configuration, the origin, the sink's bound on one response's bytes, and the responses the servers give, keyed by URL (a URL with no response is a server that does not answer); and the outcome: the roots in the order the sink asks them, each URL asked with what came of it (heldor a reason of §8.7 or §8.8), the result,heldor the reason SPEC §3.1 refuses the pin with (orset_usage_malformed, prior-carriage §18.1), andusage, the usage statement a held listing binds as its filewai-usage.json(its licence, terms, the two booleans and the digest of its ai-usage statement),nullwhere it binds none. A body is a set's bytes (set), those bytes with one byte's lowest bit flipped (flip), a file offiles/(file, withfliportruncate, the first bytes kept), or bytes given in hexadecimal (hex). A response is keyed by its URL and theAvailable-Dictionaryvalue of the request it answers (nullfor a request that names no dictionary); a fetch'sdictionaryis the set the sink holds and names (§8.8). -
fields:Available-Dictionaryvalues and the digest each names (nullwhere it does not read as one), and theUse-As-Dictionaryvalue for a root's path. -
stock: the check a stock client makes of §8.8:files/title-from-generic.dczafter its 40-byte header, decoded by the Zstandard tool againstgeneric, hastitle's SHA-256:tail -c +41 files/title-from-generic.dcz | zstd -d -D ../prior-forms/files/generic.safetensors | sha256sum -
plans: §17's worked plans, each a plan (a span, a cap, the generations in epoch order with their sets' bytes and any coding against an earlier one, the titles with their pinned and classical bytes, and one or more sinks with what each holds and its fetches per title) and the outcome worked by hand: per sink, each generation's saving, cost (held,deltaorset) and net, the generations kept, fetched and evicted, each title's rendition, and the bytes received beside the bytes with no set; orplan_malformed. The sizes are worked numbers, not measurements. -
usage: §18.1's usage statements as JSON text, and what reading each gives (its licence, terms, the two booleans and the digest of its ai-usage statement) orset_usage_malformed. -
sealed: §18.2's sealed sets (files/title.wsk1,files/generic.wsk1, or a header written in hexadecimal), the keys the sink holds by their identifiers, and what opening gives (the inner form, the plaintext's digest and the usage statement) or the reason. The corpus's key (16 bytes of0x6b, identifier 16 bytes of0x4b, counter block 16 bytes of0x69) is published here and protects nothing. -
held_sets: http-delivery §12.5'sheld_setsfrom a store of sets held per site, the site it is sent to, the pins the site's content carries, and whether it is turned on; anddictionary_naming, whether a sink may name a held set inAvailable-Dictionaryfor a site. -
tree_heads: §19's heads (files/generic.wtr1in pieces of one chunk,files/generic-g1.wtr1in pieces of two,files/title-sealed.wtr1overfiles/title.wsk1, or a head written in hexadecimal) and what reading each gives (the inner form, the set's length, the piece exponent, the number of pieces, the set's SHA-256 and its BLAKE3 hash) or the reason. -
tree_fetches: a head, sources (each named, with the bytes it serves, whether it answers, and any content coding), and the outcome of fetching every piece by range: each piece asked of which source with what came of it, pieceifirst from sourcei mod mand then from the sources after it; thenheldand the set's SHA-256, or the reason.
files/title-from-generic.dcz is title coded against generic by the Zstandard library at
level 19, its content size and checksum stated, under the dcz header naming generic.
files/title-window-16m.dcz holds title in one raw block of a frame that states a 16 MB
window and no content size, under the same header: a frame RFC 9842 has no client decode
against a dictionary of generic's size.
A verifier conforms when it reaches every case's outcome, field for field.
Verifiers.
wai_prior_carriage_vectors verify live-conformance/prior-carriage(wai-rs, featureprior_carriage): every file regenerates byte for byte, no other file is here, and the module reaches every outcome.wai_prior_carriage_vectors genwrites the corpus.python3 -I live-conformance/prior_carriage_verify.py live-conformance/prior-carriage, written from the texts and sharing no code with wai-rs. It decodes Zstandard with_rfc8878_zstd.py, written from RFC 8878 beside it, hashes with the shared../../claim-conformance/_blake3.py, written from the BLAKE3 specification, opens sealed sets with_fips197_aes.py, written from FIPS 197 and NIST SP 800-38A, reads ai-usage statements with the ai-usage corpus's second implementation (ai_usage_verify.py), and, where the Zstandard tool is on the PATH, runs thestockcheck with that tool too. It also mutates copies of the corpus, one defect each, and requires every copy to fail, and drops each of its own checks in turn and requires the corpus to catch the weakened verifier.