mirror of
https://github.com/logos-messaging/specs.git
synced 2026-01-02 14:13:06 +00:00
Remove stale section
This commit is contained in:
parent
b44c3c7dbe
commit
9c2e71d9eb
@ -210,19 +210,6 @@ When a client encounters an unknown frame type, it can definitively conclude thi
|
||||
This explicit tagging mechanism allows the protocol to evolve without breaking existing implementations.
|
||||
Future versions may define additional frame types for protocol-level functionality while legacy clients continue processing `content` frames normally.
|
||||
|
||||
## Frame Handling
|
||||
|
||||
This protocol uses explicit tagging of content, to remove ambiguity when parsing/handling frames.
|
||||
This creates a clear distinction between frames generated by the protocol, and content which was passed in.
|
||||
Even if new frames are added in the future, Clients can be certain whether the payload is intended for itself or applications.
|
||||
This is achieved through an invariant - All non-content frames are intended to be consumed by the client.
|
||||
When a new unknown frame arrives it can be certain that a version compatibility issue has occurred.
|
||||
|
||||
- All application level content MUST use the `content` frameType.
|
||||
- Clients SHALL only pass `content` tagged frames to Applications
|
||||
- Clients MAY drop unrecognized frames
|
||||
|
||||
|
||||
# Wire Format Specification / Syntax
|
||||
|
||||
## Payload Parse Tree
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user