25 lines
1.2 KiB
Markdown
25 lines
1.2 KiB
Markdown
## Decisions
|
|
|
|
- Use the existing generated JSON binding pipeline and add only object definitions that
|
|
consumers need now.
|
|
- Keep registration/authority messages distinct from `ConnectionManifest`; the latter is
|
|
client-facing and contains no provider route, certificate, identity, or credential.
|
|
- Encode capability domains as bounded registered strings (`transport`, `framing`, `media`,
|
|
`audio`, `source_rate_control`, `client_decode`) so unknown or empty required domains
|
|
cannot silently fall back.
|
|
- Use a fixed 21-byte big-endian datagram header with application flow IDs and a payload
|
|
limit below the path MTU; control channels 1-3 remain compatible with Phase 3A.
|
|
|
|
## Bounds and failure behavior
|
|
|
|
All arrays, strings, payloads, fragments, and timestamps are bounded by the JSON schema or
|
|
frame registry. Generated decoders reject unknown fields, trailing values, invalid versions,
|
|
and missing required fields. Provider address, RTSP, credential, and private-key names are
|
|
not added to client-facing definitions.
|
|
|
|
## Compatibility
|
|
|
|
The current wire version remains `1`; current, N-1, and N-2 declarations remain unchanged.
|
|
New identifiers are additive. Consumers must reject an unknown major or no-overlap selection
|
|
before provider launch.
|