43 lines
2.3 KiB
Markdown
43 lines
2.3 KiB
Markdown
## Context
|
|
|
|
The Server resolves an immutable stream-policy version, but RC6 provider work carries only its identifier. The Data Plane consequently cannot distinguish the authorized settings from local defaults.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
|
|
- Carry only the effective launch settings required by the provider boundary.
|
|
- Express client decode support as an ordered set of existing registered profiles.
|
|
- Generate the same ordered registered-profile intersection for every consumer.
|
|
- Generate identical validation from the canonical schema for all bindings.
|
|
- Preserve the policy-version identifier for audit correlation.
|
|
|
|
**Non-Goals:**
|
|
|
|
- Publish or mutate RC6.
|
|
- Add a provider-specific token grammar or generic capability framework.
|
|
- Expose provider work or policy internals to Verse clients.
|
|
|
|
## Decisions
|
|
|
|
- Use one required nested `ProviderStreamPolicy` value in `ProviderSessionWork`; this keeps the policy settings atomic and avoids repeating validation.
|
|
- Carry the Server-selected target bitrate rather than all policy bounds because Apollo ANNOUNCE consumes one configured bitrate.
|
|
- Permit canonical `H264`, `HEVC`, and `AV1` values in the contract. A provider implementation must reject values it cannot honor rather than silently downgrade them.
|
|
- Carry `audio_enabled` even though the current Apollo path cannot truthfully disable audio; the Data Plane must fail closed for that combination.
|
|
- Change `client_decode` from one opaque string to a non-empty ordered unique array of registered profile identifiers. Preference belongs to the first peer's order.
|
|
- Generate `IntersectCapabilityProfiles` from the canonical schema so Protocol, Server, and Data Plane do not maintain separate interpretations.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- [New required field breaks RC6 consumers] → Publish only under a separately authorized new immutable version and pin both consumers after empty-cache resolution.
|
|
- [Provider capabilities differ] → Validate the effective policy against the selected provider before readiness.
|
|
- [Peers advertise no common registered profile] → Reject admission instead of inventing a combined token or silently downgrading.
|
|
|
|
## Migration Plan
|
|
|
|
Regenerate and verify bindings locally, update both consumers through a temporary workspace only, then stop at the publication boundary. RC6 remains unchanged.
|
|
|
|
## Open Questions
|
|
|
|
None.
|