gateway-media-framing Specification

Purpose

Define the versioned datagram framing, bounded reassembly, and explicit negotiation required to carry complete encoded media units.

Requirements

Requirement: Versioned complete encoded-frame datagrams

The Protocol SHALL register datagram-v2 with a 23-byte network-order header containing magic, version, channel, flags, sequence, timestamp, unsigned 16-bit fragment index, unsigned 16-bit fragment count, and unsigned 16-bit payload length. Media datagrams MUST remain at most 1,200 bytes with at most 1,177 payload bytes, and one sequence MUST represent exactly one complete encoded unit of at most 1,048,576 bytes and 891 fragments.

Scenario: Bounded large encoded frame

WHEN an encoded media frame is larger than the datagram-v1 18,864-byte limit but no larger than 1,048,576 bytes
THEN datagram-v2 carries it under one sequence in at most 891 independently bounded fragments

Scenario: Oversized encoded frame

WHEN a sender attempts more than 1,048,576 complete bytes or 891 fragments
THEN framing rejects the unit before sending or allocating proportional state

Requirement: Bounded complete-frame reassembly

Datagram-v2 reassembly SHALL retain at most four incomplete media units and only the bytes actually received, permit bounded fragment reorder and exact duplicate fragments, reject conflicting duplicates or inconsistent metadata, expire incomplete state after 250 milliseconds, and emit a payload only after every fragment is present exactly once.

Scenario: Reordered frame completes

WHEN every valid fragment for one unit arrives out of order within the reassembly bounds
THEN the receiver emits exactly one byte-identical complete encoded frame with its original boundary

Scenario: Malformed or stale reassembly

WHEN fragments conflict, metadata changes, an index or count is invalid, state exceeds four incomplete units, or a unit exceeds its timeout
THEN the receiver rejects or evicts that incomplete unit without proportional allocation or payload emission

Requirement: Explicit framing negotiation

CapabilityProfile.framing SHALL accept only registered datagram-v1 or datagram-v2 values. A peer MUST use datagram-v2 only after exact capability intersection and MUST NOT reinterpret datagram-v1 bytes as datagram-v2.

Scenario: Independent datagram-v2 peers overlap

WHEN both peers advertise the registered datagram-v2 framing profile
THEN generated Go, Rust, and Swift validation and fixed conformance accept the profile

Scenario: Unknown or downgraded framing

WHEN a peer advertises an unknown framing value or the peers advertise different versions
THEN capability validation or intersection rejects the session before media forwarding

2.8 KiB Raw Blame History