feat(protocol): negotiate registered gateway profiles
This commit is contained in:
sechmachine
@@ -7,13 +7,15 @@ The Server resolves an immutable stream-policy version, but RC6 provider work ca
|
||||
**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 provider-specific capability negotiation to Protocol.
|
||||
- Add a provider-specific token grammar or generic capability framework.
|
||||
- Expose provider work or policy internals to Verse clients.
|
||||
|
||||
## Decisions
|
||||
@@ -22,11 +24,14 @@ The Server resolves an immutable stream-policy version, but RC6 provider work ca
|
||||
- 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
|
||||
|
||||
|
||||
@@ -5,6 +5,7 @@ Provider work identifies an immutable stream-policy version but omits the effect
|
||||
## What Changes
|
||||
|
||||
- Add the effective resolution, frame rate, codec, selected bitrate, and audio policy to authenticated provider work.
|
||||
- Represent decode support as an ordered set of registered profiles and generate one canonical intersection operation for consumers.
|
||||
- Require generated Go, Rust, and Swift bindings to validate the same bounded stream-policy contract.
|
||||
- Keep the new contract unpublished until a new immutable Protocol version is separately authorized.
|
||||
|
||||
@@ -12,7 +13,7 @@ Provider work identifies an immutable stream-policy version but omits the effect
|
||||
|
||||
### New Capabilities
|
||||
|
||||
- `provider-stream-policy`: Authenticated provider work carries the exact effective stream policy consumed by the provider launch.
|
||||
- `provider-stream-policy`: Authenticated provider work carries the exact effective stream policy consumed by the provider launch, and registered peers negotiate that policy through the shared ordered profile intersection.
|
||||
|
||||
### Modified Capabilities
|
||||
|
||||
|
||||
@@ -13,3 +13,21 @@ Generated Go, Rust, and Swift bindings MUST reject missing, unknown, out-of-rang
|
||||
#### Scenario: Invalid policy is rejected consistently
|
||||
- **WHEN** provider work contains an unknown codec or a value outside the canonical bounds
|
||||
- **THEN** every generated binding rejects the work before it can reach provider setup
|
||||
|
||||
### Requirement: Decode capabilities use registered ordered profiles
|
||||
`CapabilityProfile.client_decode` SHALL be a non-empty ordered unique set containing only registered `h264-opus` and `hevc-opus` profile identifiers. It MUST NOT encode multiple capabilities in an opaque private token.
|
||||
|
||||
#### Scenario: Independent peer advertises one registered profile
|
||||
- **WHEN** an independent peer advertises one registered decode profile
|
||||
- **THEN** canonical validation accepts that profile without requiring a combined private token
|
||||
|
||||
### Requirement: Consumers share one ordered registered-profile intersection
|
||||
Generated Protocol behavior SHALL select common registered profiles in the first peer's preference order. Provider consumers SHALL separately reject the resulting intersection when it cannot honor the immutable stream policy.
|
||||
|
||||
#### Scenario: Policy-compatible profile overlaps
|
||||
- **WHEN** the gateway advertises HEVC then H.264 and the client advertises only H.264
|
||||
- **THEN** the shared intersection selects `h264-opus`
|
||||
|
||||
#### Scenario: No policy-compatible profile overlaps
|
||||
- **WHEN** peers have no registered common profile
|
||||
- **THEN** the shared intersection rejects admission without inventing a private combined token
|
||||
|
||||
@@ -3,6 +3,8 @@
|
||||
- [x] 1.1 Add bounded effective stream policy to ProviderSessionWork
|
||||
- [x] 1.2 Add Go, Rust, and Swift conformance coverage
|
||||
- [x] 1.3 Regenerate bindings and prove deterministic output
|
||||
- [x] 1.4 Replace the opaque decode token with an ordered unique set of registered profiles
|
||||
- [x] 1.5 Generate and cross-check canonical ordered registered-profile intersection behavior
|
||||
|
||||
## 2. Consumer Boundary
|
||||
|
||||
|
||||
Reference in New Issue
Block a user