b912d6faa8
Two seams the tree could not express, both surfaced by the landscape survey.
CAPABILITY CONSTRAINTS. WAI dispatch treats support as binary — a sink either
claims a capability or does not. Real sinks support a codec TO A LEVEL: up to a
resolution, a frame rate, a bit depth, a profile. "This capability, but only to
4K60 10-bit, this profile" is the normal case and was unexpressible, so partial
support failed at DECODE time rather than SELECTION time, and rendition selection
had nothing to evaluate and deferred to a deployer policy the spec never states.
Ingests the constraint-set grammar and register pattern from AMWA's ratified
Receiver/Sender Capabilities work (BCP-004-01 / -02, v1.0.0) — ORed sets of
enum/min/max constraints over register-named parameters. Grammar and pattern
only: not the transport, not the discovery model, and explicitly NOT the
pre-flight negotiation framing, because capability-plus-budget binding before
execution is already owned by JCP and two mechanisms for one job is worse than
none.
The honest limit is stated in §3 rather than hidden: the ratified registers are
broadcast-essence-shaped and cover only WAI's conventional media families. There
are no entries for neural, quantum, world or haptic, and WAI must author those
itself — until it does, those capabilities remain unconstrained, which is the
true state rather than a pretended one.
UNIDIRECTIONAL DELIVERY. Three assumptions quietly presume the sink can talk
back: jwp-receipts assumes relay-chain linkage, targeting presumes the source
learns something about the sink, and pre-emption has no signer class because
nothing in WAI has needed to assert authority over a sink before. Terrestrial
broadcast, satellite and multicast object carriage break all three, and none is
repaired by defining a bearer.
* Sink-evaluated predicates (§2): the object carries a condition the SINK
evaluates against local state the source never learns, under a
predicate-equivalence contract in the shape of state-feeds §3. The
specifiable property is determinism and auditability, NOT enforcement —
every sink receives every byte and can lie about its own state, and this
text says so. The real claim is narrow and worth having: the source learns
nothing, which is the dual of source-side targeting.
* Authority and pre-emption (§3): pre-emption is the highest-authority
instruction a media object can carry — it displaces what a person chose to
watch — and today an object either lacks the field or has one anyone may
set. Requires a sink-held trust anchor provisioned out of band; a trust
anchor delivered over the bearer it authorises is not one. A valid signature
establishes who signed, never that they were entitled to.
* Detached receipts (§4): the deliverable is an honest profile, not a proof.
Such receipts attest WHAT WAS TRANSMITTED, not what was received or
rendered, and MUST declare the bearer unidirectional. No receipt can prove
rendering over a bearer with no return path; what this prevents is the
quieter error of a receipt saying "delivered" because a transmitter
transmitted, on a link that cannot tell it whether anyone was listening.
Generalised from deployed national early-warning systems, which are where a sink
evaluating a condition the source never learns has had to work at scale.
Ingest queue items 10 and 11 (#80 §4.2, §4.3).
Co-Authored-By: Claude Opus 5 <[email protected]>
4.3 KiB
WAI Extension: Capability Constraints
Status: Draft. Makes capability dispatch (WAI SPEC.md §4) a precondition check rather than a binary claim, by ingesting the constraint-set grammar and register pattern the broadcast-IP world already ratified. No transport, no registry service, no negotiation protocol — it evaluates values WAI already carries. Keywords MUST, MUST NOT, SHOULD, MAY are RFC 2119/8174.
1. The problem: support is not binary
WAI dispatch treats a capability as present or absent: a sink either claims
cap or does not. Real sinks are not like that. A decoder supports a codec to
a level — up to a resolution, a frame rate, a bit depth, a profile. "This
capability, but only to 4K60 10-bit, this profile" is the normal case and is
currently unexpressible.
The consequence is that partial support fails at decode time rather than at selection time. A sink advertises the capability, receives an object it cannot actually handle, and fails after committing to the bytes. Worse, WAI's rendition selection has nothing to evaluate, so it defers to a deployer policy the specification never states.
2. Constraint sets
A constraint set is an ORed set of constraints over named parameters, each
constraint being an enumeration, a minimum, a maximum, or a combination. A sink
satisfies a capability when it advertises cap and the object's declared
parameters satisfy at least one of the registered constraint sets for cap.
This grammar is deliberately not invented here. It is the shape AMWA's Receiver and Sender Capabilities specifications (BCP-004-01 and BCP-004-02, both v1.0.0) use, with parameters drawn from a public register rather than a bespoke schema per implementation. WAI ingests the grammar and the register pattern, not the transport or the discovery model those specifications sit in.
- A capability registration MAY publish one or more constraint sets. A capability with none is unconstrained, which is the current behaviour and remains valid.
- A sink MUST evaluate constraint sets before dispatch, not during it. The point is to move the failure earlier; a check performed at decode has bought nothing.
- A sink MUST NOT advertise a capability whose constraint sets it cannot evaluate. Advertising a capability while ignoring its constraints is the binary behaviour this extension exists to replace.
- Where an object's declared parameters satisfy no set, the sink MUST treat the capability as unsupported for that object — not as a decode error, and not as a reason to attempt it anyway.
3. Parameters and the register
Parameters are named in a register, so two implementations constrain the same property under the same name. WAI adopts the pattern; it does not adopt the existing register wholesale, for a reason worth stating plainly:
The ratified registers are broadcast-essence-shaped. They cover media type, frame rate, colour sampling, bit depth, codec profile — which serves WAI's conventional media capabilities and nothing else. There are no entries for the neural, quantum, world or haptic families. Those register entries WAI must author itself, and until it does, those capabilities remain unconstrained under §2, which is the honest state rather than a pretended one.
- A parameter name MUST resolve in a register. An implementation-local name is not a constraint anyone else can evaluate.
- WAI-authored parameters MUST be namespaced so they cannot collide with entries authored elsewhere.
4. What this is not
- It is not a negotiation protocol. There is no pre-flight exchange, no controller, and no registry service. Capability-plus-budget binding before execution is already owned by JCP, and duplicating it here would put two mechanisms in the tree for one job.
- It is not a transport concern. Constraint evaluation reads values the object already declares.
- It is not an energy mechanism. A constraint says what a sink can decode, never what it should spend.
5. Framing
The grammar is thin — close to a JSON-Schema subset — and that is fine. The value is not expressiveness; it is that a ratified, register-backed way of saying "supported, to here" already exists, and WAI's dispatch is strictly worse for having only "supported".