NETWORK WORKING GROUP Network Working Group C.P. Ross Internet-Draft Independent Intended status: Experimental 02 March 2026 Expires: 02 September 2026 Mercurius Window System (MWS) draft-ross-mercurius-00 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This document is an individual submission to the IETF. Distribution of this document is unlimited. The latest version of this draft can be found at: https://mercurius.tebibyte.org/draft-ross-mercurius-00.txt Author’s Address Christopher Ross Independent Email: chris@tebibyte.org Project Website: https://mercurius.tebibyte.org Abstract The Mercurius Window System (MWS) is a network‑native, server‑side rendering system that enables graphical sessions to be accessed remotely with explicit semantics for windows, input, and session state. MWS allows a user to interact with a workstation from untrusted or resource‑constrained client devices without exposing application data, GPU workloads, or compositor state to those devices. The protocol defines a zero‑trust client model, a structured session and window architecture, and a transport profile based on SCTP multi‑streaming. This document specifies the MWS architecture, message formats, transport requirements, and security model. Executive Summary (Non‑Normative) The Mercurius Window System (MWS) is a secure, high‑performance window system for environments where applications run on one machine but users work from another. Whether the host is a personal workstation, a shared server, a large deployment, or a private cloud, MWS provides responsive access from any location without assuming that “local” networks or client devices are trustworthy. MWS is designed for modern mobility patterns: consultants, remote workers, and digital nomads who move between client sites, hotels, airports, and home offices. These users often rely on lightweight laptops or tablets that may be lost, stolen, or compromised. MWS ensures that possession of a client device is never sufficient to access the workstation. Authentication requires explicit user presence, and no sensitive data, credentials, or GPU workloads reside on the client. MWS preserves the network transparency that made X11 valuable, whilst replacing its implicit trust and CPU‑bound rendering with a modern, zero‑trust, GPU‑accelerated architecture. The result is a window system that feels local even when the GPU is in another room, another building, or another country, supporting workflows ranging from office productivity to high‑refresh‑rate interactive applications on modern networks. Table of Contents 1. Introduction 1.1. Scope and Applicability 1.2. Design Rationale 1.3. Cloud and Distributed Computing Context 1.4. High‑Performance Rendering and Gaming 1.5. Terminal Requirements and Wireless Considerations 1.6. Session Mobility and Detachable Operation 2. Conventions Used in This Document 3. System Architecture 3.1. Architectural Principles 3.2. Major Components 3.3. Workstation‑Centric Model 3.4. Rendering and Surface Model 3.5. Session Model 3.6. Zero‑Trust Client Model 3.7. Network Considerations 3.8. Transport Requirements 4. Detailed Architecture 4.1. Sessions 4.2. Seats 4.3. Windows 4.4. Compositor Model 4.5. Rendering Model 4.6. Stream Allocation 4.6.1. Session Identity and Message Routing 4.7. Session Lifecycle 4.8. Session and Seat Model 4.9. Local Transport Profile (Non‑Normative) 4.10. Security Model 5. Protocol Specification 5.1. Message Framing 5.2. Control Messages (Stream 0) 5.2.1. Initial Handshake (001–099) 5.2.1.1 Session Identifier Semantics 5.2.2. Session Management (100–199) 5.2.2.1 Resume Semantics 5.2.3. Window Lifecycle (200–299) 5.2.3.1. Window Identifier Scope 5.3. Rendering Commands (300–399) — Stream 1 5.4. Input Events (400–499) — Stream 2 5.4.1. Pointer Motion Events 5.4.2 Input Scoping and Session Isolation 5.5. Video Fallback (500–599) — Stream 3 5.6. Protocol State Machine 5.6.1. Initial Connection 5.6.2. Session Resume 5.7. WSI Extension (Surface Creation) 5.7.1. Surface Binding and Session Validation 5.7.2. Required Enums 5.8. Error Handling (600–699) 5.8.1. Session and Resource Validation Errors 6. Reference Implementation 6.1. Server Components (meta‑mws‑server) 6.2. Client Components (meta‑mws‑client) 6.3. Demonstration Clients 6.3.1. Screensaver Demonstration 6.3.2. Indie Game Demonstration 6.4. Dependencies 6.5. Bootstrap Example 7. Implementation Requirements and Validation 7.1. Test Matrix 7.1.1. Core Validation Tests 7.1.2. Reference Implementation Commands (Non‑Normative) 7.2. GPU Isolation Requirements 7.3. Bandwidth and Transport Isolation Requirements 8. Performance Considerations 9. Security Considerations 9.1. DANE Deployment (Non‑Normative) 10. IANA Considerations 11. Acknowledgements 12. References 12.1. Normative References 12.2. Informative References Appendix A. MWS Opcode Registry A.1. Handshake and Authentication (000–099) A.2. Session Management (100–199) A.3. Window Lifecycle (200–299) A.4. Rendering Commands (300–399) A.5. Input Events (400–499) A.6. Video Fallback (500–599) A.7. Error Reporting (600–699) A.8. Capability and Introspection (700–799) A.9. Reserved for Future Extensions (800–899) A.10. Experimental and Vendor‑Specific (900–999) Appendix B. Authentication Mechanism Registry B.1. Standard Mechanisms B.2. Extensible Mechanisms B.3. Private and Experimental Mechanisms B.4. Registration Policy Appendix C. SCTP Stream Usage Summary C.1. Stream 0 — Control Plane C.2. Stream 1 — Rendering Commands C.3. Stream 2 — Input Events C.4. Stream 3 — Video Fallback C.5. Additional Streams Appendix D. Protocol State Machine Diagrams D.1. Initial Connection State Machine D.2. Session Resume State Machine D.3. Error Handling State Machine D.4. Stream Interaction Summary 13. Copyright 1. Introduction The Mercurius Window System (MWS), named for Mercurius, the Roman messenger god of swift communication, is a secure window system for both local and remote use. A user may work directly at the console of a workstation as on a conventional Unix-like desktop, with full access to its GPU, input devices, and local display. The same session may also be accessed from lightweight, mobile, or untrusted client devices elsewhere, without replicating the workstation’s software environment or exposing its data or GPU resources. Compute, storage, and rendering remain on the workstation; clients act solely as authenticated display and input endpoints. This model supports both traditional workstation usage and modern mobility patterns. A user may begin work at a powerful machine in the office and later continue the same session from a laptop, thin client, or secondary desktop in another location, without maintaining multiple environments or synchronising state. Remote access is an extension of the local workstation rather than a separate mode of operation. MWS is not a local display protocol, nor a pixel‑streaming system. It defines a structured, message‑oriented protocol for presence, input, and rendering state on a workstation. Rendering is server‑resident and GPU‑accelerated, and the protocol transmits structured commands rather than framebuffers. The transport is agnostic but optimised for SCTP’s multi‑stream, message‑oriented semantics. This architecture continues the lineage of early Unix window systems such as X11, which supported network‑transparent interaction with applications running on central servers, while applying modern zero‑trust security, authenticated multi‑stream transport, and GPU isolation. Earlier systems such as NeWS explored server‑side rendering but lacked the transport and security mechanisms required for contemporary workloads. Wayland, by contrast, is intentionally scoped to trusted local compositing and does not address remote GPUs, untrusted clients, or relocatable sessions. MWS occupies a distinct design space: secure, zero‑trust remote presence for server‑resident graphical environments, without compromising first‑class local console use. 1.1. Scope and Applicability This document specifies the Mercurius Wire Protocol (MWP), the transport‑level protocol used by MWS to establish, authenticate, and maintain a user’s graphical presence on a workstation. MWP defines message framing, capability negotiation, session attachment, and input/output semantics. MWS is intended for environments where: • applications execute on a central workstation or server • users may work locally at the console or remotely from other devices • clients may be untrusted, mobile, or ephemeral • users may relocate sessions across devices • GPU‑accelerated workloads must remain server‑resident • network transparency is a first‑class requirement • loss or theft of a device must not compromise workstation security. MWS does not replace local display protocols such as Wayland, nor does it extend them. It provides a complementary mechanism for secure local and remote presence in multi‑user and distributed environments where local display protocols do not apply. 1.2. Design Rationale Early Unix window systems, including X11, were explicitly designed for network transparency: applications executed on powerful central servers while users interacted from remote terminals. This model proved valuable in multi‑user and distributed environments, but X11’s permissive trust model, unrestricted client capabilities, and CPU‑bound rendering are incompatible with modern zero‑trust requirements and GPU‑accelerated workloads. Wayland addresses these issues by assuming a single trusted local compositor, a local GPU, and a single‑user environment. This model provides excellent performance on personal workstations but does not support remote GPUs, relocatable sessions, multi‑user deployments, or untrusted clients. These use cases lie outside Wayland’s design goals. MWS intentionally revives and modernises the network‑transparent workstation model. It retains the architectural advantages of centralised execution and remote interaction while adopting a zero‑trust security model based on mutual TLS [RFC8446], authenticated SCTP [RFC9260] streams, and per‑client GPU isolation. Rendering is server‑resident and GPU‑accelerated; clients transmit structured rendering commands rather than framebuffers. All compositor policy, input routing, and window management occur on the server, ensuring multi‑user correctness and preventing privilege escalation. Crucially, possession of a client device is never sufficient to access the workstation. Client certificates must be protected by the platform, session resume requires fresh authentication, and no sensitive data or credentials are stored on the client. This ensures that a lost or stolen laptop cannot be used to compromise the workstation. The result is a window system that provides deterministic semantics, strong isolation, and relocatable sessions, enabling users to inhabit remote workstations with the performance and responsiveness of a local environment, whilst preserving first‑class local console operation. 1.3. Cloud and Distributed Computing Context Many organisations operate private cloud or workstation‑cluster environments where users access centralised compute and GPU resources from thin clients or mobile devices. Public cloud deployments exhibit similar characteristics: applications execute on remote servers while clients roam across untrusted networks. MWS aligns with this model by centralising execution and distributing only the user interface. This avoids the inefficiencies of distributed compute systems whilst preserving the benefits of remote access, session mobility, and strong isolation between users. Because clients are untrusted, MWS ensures that compromise or loss of a client device does not grant access to the workstation. 1.4. High‑Performance Rendering and Gaming MWS is primarily intended for workstation and private‑cloud deployments in which terminals connect over well‑provisioned LANs and VPNs, typically with DANE [RFC6698] securing mutually authenticated transport. In these environments, modern GPUs provide hardware accelerated AV1 encoding with extremely low latency, enabling high‑resolution and high‑refresh‑rate streaming for everyday workstation workloads. Nevertheless, the same architecture could accommodate high performance remote rendering workloads, including interactive 3D applications and games. Support for such workloads is a stretch goal rather than a primary target, but these use cases inform the design of the transport, security, and rendering model to ensure that MWS remains viable for demanding graphical applications. 1.5. Terminal Requirements and Wireless Considerations MWS clients are treated as untrusted endpoints. Practical deployments assume a minimum level of capability. A typical terminal is expected to provide a modern CPU, a hardware‑accelerated GPU capable of AV1 decoding, and at least gigabit‑class network connectivity. Higher resolutions or refresh rates benefit from greater bandwidth, but MWS remains usable at reduced quality on lower‑capacity links. Emerging wireless standards such as Wi‑Fi 8 (IEEE 802.11bn) are expected to deliver multi‑gigabit throughput and sub‑millisecond air‑interface latency, enabling MWS terminals to operate over wireless links without compromising interactive performance. 1.6. Session Mobility and Detachable Operation Because sessions in MWS are server‑resident and independent of client connections, the system naturally supports detachable operation. A user may disconnect from one terminal and later resume the same session from another device, with all windows, GPU state, and compositor context preserved. This model is conceptually similar to terminal multiplexers such as screen or tmux, but applied to a full GPU‑accelerated graphical environment. Session mobility is a core design goal of MWS and informs its authentication, transport, and rendering architecture. 2. Conventions Used in This Document The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals. Terminology relating to Vulkan follows the definitions and naming conventions of the Vulkan 1.4 specification [VK14]. Terminology relating to SCTP follows RFC 9260. Unless otherwise stated: • “workstation” refers to the system on which applications execute, and where all rendering, compositing, and session management occur. • “server” refers to the MWS server daemon (mwsd) running on the workstation. In this document, “workstation” and “server” refer to the same system at different levels of abstraction. • “client device” refers to the physical device used by a user to access the workstation. Examples include laptops, tablets, phones, thin clients, and embedded devices. • “client” refers to the MWS client daemon running on the client device. The client is the protocol endpoint that communicates with the server. • “terminal” refers to the logical role a client assumes once connected: a seat‑providing endpoint that delivers input and receives rendered output. • “session” refers to a persistent graphical environment maintained on the workstation independently of client connections. • “seat” refers to a set of input devices and output mappings associated with a session and bound to a terminal. • “surface” refers to a drawable region managed by the compositor and rendered by the workstation’s GPU. • “command stream” refers to the structured, Mercurius protocol messages exchanged on SCTP stream 0 (control stream). • “video surface” refers to a high‑motion region encoded using a hardware‑accelerated codec such as AV1. • The names Alice, Bob, Eve, and Mallory are used in their standard roles from security literature. Alice and Bob denote honest users, Eve denotes a passive eavesdropper, and Mallory denotes an active attacker. These names are used solely for threat‑model examples and do not correspond to real users or implementation artefacts. All multi‑byte integers are transmitted in network byte order unless explicitly specified otherwise. 3. System Architecture This section provides a high‑level overview of the Mercurius Window System (MWS). It describes the conceptual model, major components, and architectural principles that inform the detailed design in Section 4 and the protocol specification in Section 5. MWS is designed around a workstation‑centric model in which all rendering, compositing, session management, and window‑management policy reside on a central server. Client devices act solely as authenticated display and input endpoints. This model preserves the semantics of a local workstation while enabling secure remote presence across modern networks. MWS assumes client devices with at least gigabit‑class connectivity, including modern Wi‑Fi networks that routinely exceed 1 Gb/s. The protocol is optimised for 10 GbE LANs, where uncompressed or lightly compressed surfaces and high‑motion content can be delivered with minimal latency. Devices with substantially lower bandwidth may operate at reduced quality but are not a primary design target. 3.1. Architectural Principles The design of MWS is guided by the following principles: • Applications execute on a central workstation or server. • Local and remote interaction share identical session semantics. • Client devices may be untrusted, mobile, or ephemeral. • Users may relocate sessions across devices without restarting applications. • GPU‑accelerated workloads remain server‑resident. • Network transparency is a first‑class requirement. • Loss or theft of a client device must not compromise workstation security. These principles reflect the goal of treating the workstation as a long‑lived environment with continuity of storage, configuration, and identity. Alternative transports such as QUIC were considered. However, SCTP’s native multi‑streaming, message‑oriented delivery, and support for partial reliability align directly with the requirements of MWS. QUIC’s multiplexed byte‑stream model, together with the absence of partially reliable streams, would require additional framing and scheduling logic to emulate SCTP semantics. For these reasons, SCTP is the primary transport for MWS. The protocol’s guarantees depend on transport properties that SCTP provides natively, including independent ordered streams, preservation of message boundaries, optional partial reliability, avoidance of cross‑stream head‑of‑line blocking, and stable associations. These properties are required to ensure deterministic compositor behaviour, responsive input under load, support for high‑motion video surfaces, relocatable sessions, and multi‑seat concurrency. TCP does not provide these properties without substantial additional protocol machinery. A TCP‑based transport would therefore be unable to meet the latency, isolation, and concurrency requirements of MWS as defined in this document, and is out of scope for this specification. 3.2. Major Components MWS consists of the following major components: • The compositor, which manages windows, focus, input routing, and presentation. • The renderer, which executes GPU‑accelerated drawing and performs surface composition on the workstation. • The session manager, which maintains user sessions independently of client connections and supports detachable operation. • The transport layer, which provides a secure, multi‑stream, message‑oriented channel between workstation and client. • The client device, which decodes surfaces, presents them to the user, and forwards input events to the workstation. These components interact to provide a deterministic, structured, zero‑trust window system suitable for both local console use and remote presence. 3.3. Workstation‑Centric Model The workstation is the authoritative environment. It owns all GPU resources, input devices, and compositor state. Applications run exclusively on the workstation, and all rendering is performed on the workstation’s GPU. A user may interact with the workstation in two ways: • Local console mode, using the workstation’s own keyboard, pointer, and display. • Remote presence mode, using an authenticated client device elsewhere on the network. Local and remote interaction share the same compositor, window tree, and session state. Remote presence is an extension of the local workstation, not a separate mode of operation. Sessions persist across transient disconnections, but long‑term persistence requires explicit detachment. 3.4. Rendering and Surface Model MWS supports two classes of graphical output: • structured rendering commands, representing deterministic drawing operations for low‑motion or vector‑oriented surfaces • video surfaces, representing high‑motion content encoded using hardware‑accelerated codecs such as AV1 The compositor selects the appropriate representation based on surface characteristics and available bandwidth. This allows MWS to operate efficiently on both 1 GbE and 10 GbE networks, as well as on modern Wi‑Fi links. 3.5. Session Model Sessions are server‑resident and persist independently of client connections, but long‑term persistence requires explicit detachment. MWS tolerates transient network interruptions; if a client reconnects within the configured grace period, the session continues without interruption. However, if a client disappears without detaching, the session is preserved only for the duration of this grace period. Once the period expires, the session is closed, and applications terminate in the same manner as a workstation session without an active seat. A user may explicitly detach a session to preserve it beyond the reconnection grace period and may later resume it from any authorised device. A single transport association may provide multiple seats for a session when permitted by policy. The precise rules governing how many transport associations may attach to a session, and under what conditions, are defined in Section 4.7. This model enables mobility across devices while preserving the semantics of a traditional workstation and avoiding long‑lived orphaned sessions. 3.6. Zero‑Trust Client Model All client devices are treated as untrusted endpoints, even on local LANs. Trust is established exclusively through cryptographic identity and explicit authorisation rather than network location. A client device is not an identity and is not authorised to access a session by virtue of its presence on the network; only the user is authorised. Historically, X11 enabled a powerful and flexible model in which users could inhabit remote workstations as naturally as local ones. Even on dedicated X Terminals, users authenticated as themselves and could not access another user’s data. The flaw was not the login model but the assumption that any client on the network was inherently trustworthy. Wayland addressed this by eliminating remote clients entirely. Mercurius instead removes the assumption of trust: client devices may be anywhere, but trust is derived solely from what the user can cryptographically prove. Device identity is established during the DTLS/mTLS handshake. When DANE is deployed, the client’s certificate is validated against DNSSEC‑protected TLSA records, ensuring that only devices explicitly provisioned by the domain administrator may initiate a connection. Device authentication alone is insufficient to access a session. User authentication is performed at the application layer using the mechanism‑agnostic model defined in Section 5.2.1. The server advertises supported mechanisms (e.g., “DANE”, “PAM”, “PASSWORD”, “FIDO2”), and the client selects one. This allows deployments to integrate password‑based, hardware‑token, federated, or certificate‑ based user authentication without modifying the protocol. A client device is assumed to be mobile and at risk of loss or theft. To limit the impact of device compromise, a client stores no confidential data, long‑term session state, or reusable credentials. Authentication requires both possession of the device’s private key (validated via mTLS and optionally DANE) and successful user authentication via one of the advertised mechanisms. Mallory stealing Bob’s laptop gives him no more access to the workstation than if he had purchased a brand‑new laptop; the device alone is insufficient to access or resume a session. If a client disconnects unexpectedly, the session persists only for the duration of the reconnection grace period unless the user has explicitly detached. After this period, the session is closed and applications terminate. In contrast to traditional window systems such as X11, client devices in MWS are not part of the trusted computing base; they are merely display and input conduits for a workstation‑resident session. 3.7. Network Considerations MWS is designed to operate over untrusted IP networks, including public networks and variable‑quality wireless links. The protocol does not assume that terminals are located on the same LAN as the workstation, nor that any network segment provides meaningful security. A terminal on a local LAN and a terminal on a remote network are treated identically by the workstation. MWS is designed for modern networks: • 10 GbE provides optimal performance and headroom for multiple high‑resolution seats on a single workstation. • Wi‑Fi 6/6E/7 provides multi‑gigabit throughput with variable jitter and is fully supported for single‑seat clients. • 1 GbE provides a usable baseline for typical desktop workloads and a small number of seats on a workstation. • Sub‑gigabit links are outside the primary design envelope and are not expected to provide an acceptable experience for high‑resolution, high‑refresh workloads. The transport layer adapts to available bandwidth through dynamic surface encoding, selective use of video surfaces, adaptive refresh rates, and prioritised input and control streams. The detailed architecture is specified in Section 4, and the wire protocol is defined in Section 5. 3.8. Transport Requirements MWS requires a transport that provides structured, message‑oriented delivery with support for multiple independently ordered channels. The transport MUST preserve message boundaries, MUST support concurrent streams with independent ordering, and SHOULD provide mechanisms for partial reliability to avoid retransmission of stale high‑volume data such as video surfaces. The transport MUST avoid cross‑stream head‑of‑line blocking. Input events, control messages, rendering commands, and video surfaces are logically independent flows, and the correctness of compositor behaviour depends on their timely and ordered delivery within their respective channels. A transport that enforces global ordering across all data would introduce latency coupling between these flows and would not meet the responsiveness requirements of MWS. The transport MUST support stable associations that survive transient network changes, including client mobility across networks. Session attachment, reconnection semantics, and multi‑seat operation rely on the ability to maintain a consistent transport‑level association identity. SCTP satisfies these requirements through its native multi‑streaming model, message‑oriented delivery, optional partial reliability, and support for multi‑homing. These properties align directly with the architectural principles defined in Section 3.1 and are required for deterministic compositor behaviour, responsive input under load, support for high‑motion video surfaces, relocatable sessions, and multi‑seat concurrency. TCP does not provide these properties without substantial additional protocol machinery. TCP offers only a single in‑order byte stream, lacks message boundaries, enforces global head‑of‑line blocking, and provides no support for partial reliability or multi‑streaming. A TCP‑based transport would therefore be unable to meet the latency, isolation, and concurrency requirements of MWS as defined in this document, and is out of scope for this specification. 4. Detailed Architecture The Mercurius Window System (MWS) is structured around a central server (mwsd) that owns all GPU resources, input devices, and compositor state, and a set of untrusted client devices that connect over a secure, message‑oriented transport. Once connected, a client device acts as a terminal providing a seat. This section describes the architectural model of sessions, seats, windows, rendering, and compositor behaviour. The wire protocol and message formats are defined in Section 5. 4.1. Sessions A session represents the complete graphical environment associated with a single authenticated user, including windows, workspaces, GPU resources, and compositor state. Sessions are server‑resident and MAY persist independently of client connections when explicitly detached. User identity is established during the secure transport handshake. The client certificate subject is mapped to a local user account via PAM. All windows, seats, and compositor state created over that association belong to the resulting session. 4.2. Seats A seat represents a set of input devices and an output binding for a session. A session MAY have multiple seats simultaneously. Each seat corresponds to a particular terminal, whether that terminal is the local console or a remote client device acting in the terminal role. Input events are tagged with a seat_id, and the compositor routes them according to seat‑specific focus and pointer state. Output mappings (e.g., which windows appear on which displays) may also be seat‑specific. 4.3. Windows Windows are server‑managed objects representing top‑level application surfaces. Each window belongs to exactly one session and is associated with one or more rendering surfaces (structured swapchains or video surfaces) depending on compositor policy. Window identifiers are scoped to a session. A terminal MUST NOT reference or interact with windows belonging to any other session. The server MUST enforce this isolation and MUST reject or ignore any protocol message that attempts to target a window outside the authenticated session. 4.4. Compositor Model The compositor maintains the global window tree, stacking order, focus, workspaces, and output mappings for each session. It is responsible for: • applying window‑management policy • routing input events based on seat and focus • managing swapchains and presentation timing • selecting between structured rendering and video fallback • revoking or reconfiguring windows according to policy The compositor SHOULD expose a user‑visible mechanism to forcibly terminate an unresponsive window. This mechanism is implementation defined (e.g., a “kill window” gesture similar to Ctrl‑Alt‑Esc in KDE). The compositor MAY revoke swapchains, reconfigure windows, or migrate them between outputs according to local policy, resource constraints, or security requirements. When a swapchain is revoked, the server notifies the terminal and MAY substitute a placeholder or video surface. 4.5. Rendering Model Rendering in MWS is server‑side. Applications submit rendering commands to the server, which validates and executes them on the GPU. Client devices do not access GPU resources directly. The compositor selects the appropriate representation for each surface: • structured rendering for low‑motion or interactive content • video surfaces for high‑motion or bandwidth‑sensitive content Because rendering is server‑resident, a stalled or misbehaving terminal cannot block the compositor. The server MAY revoke a window’s rendering resources, substitute a placeholder surface, or terminate the client if rendering deadlines are repeatedly missed. 4.6. Stream Allocation MWS uses SCTP multi‑streaming to separate control traffic from rendering traffic and to prevent head‑of‑line blocking between independent windows. Stream allocation is defined as follows: • Stream 0 is reserved for control messages and MUST NOT carry rendering data. • Each window is associated with exactly one rendering stream. All structured rendering commands and video‑surface updates for that window are sent on its assigned stream. • Multi‑monitor configurations do not affect stream allocation. A window that spans multiple outputs continues to use a single rendering stream. • The compositor MAY allocate additional streams for specialised rendering contexts (e.g., off‑screen surfaces or auxiliary swapchains), but these MUST be explicitly negotiated during window creation and are scoped to the window that requested them. • Streams are not reused across windows unless the compositor has explicitly revoked the prior window and returned the stream to the allocator. This model ensures that rendering for one window cannot block or delay rendering for another, while avoiding unnecessary proliferation of streams in multi‑monitor environments. 4.6.1. Session Identity and Message Routing Each SCTP association corresponds to exactly one client session. The server MUST treat the SCTP association identifier (assoc_id) as the authoritative session identity. No client‑supplied field may select, reference, or influence the session to which a message is delivered. A session is created only after successful completion of the handshake defined in Section 5. Until the handshake completes, the server MUST ignore all messages received on streams other than 0. For any message received on a non‑zero stream, the server MUST: • identify the session associated with the SCTP association • verify that the session is active • dispatch the message to the subsystem corresponding to the stream • reject or ignore the message if it is malformed or references resources outside the session Messages referencing windows, seats, or other resources not owned by the session MUST be rejected with MWS_ERROR(type=600, fatal=0). Messages referencing a session other than the one implied by the SCTP association MUST be ignored. If a message is received for an association that has no active handshake or no active session, or whose session has been closed, the server MUST silently discard the message. 4.7. Session Lifecycle A session is a long‑lived server‑side construct that persists independently of any particular network connection. A session becomes ACTIVE when a client completes the handshake defined in Section 5 and remains ACTIVE until it is explicitly terminated or reclaimed by policy. A new client device connection MUST create a new session in the ACTIVE state unless the user explicitly requests to resume an existing session. The server MUST NOT automatically reattach a client device to a prior session solely on the basis of matching user identity. A client MAY explicitly detach from an ACTIVE session. Detach transitions the session from ACTIVE to DETACHED. In the DETACHED state, the session continues to run without any attached transport association; its windows, compositor state, and GPU resources remain server‑resident. DETACHED sessions MAY be resumed by any authenticated client device belonging to the same user, subject to server policy. Loss of the SCTP association (e.g., network failure, timeout, client crash) while a session is ACTIVE does not immediately terminate the session. Instead, the server MUST transition the session to a GRACE state and start a reconnection grace timer. In the GRACE state, the session remains active but has no attached client. If a client reconnects and successfully resumes the session before the grace timer expires, the server MUST transition the session back to ACTIVE and the session continues without loss of state. If the reconnection grace period expires without a successful resume, the server MUST treat the session as ABANDONED unless the user has explicitly detached it. ABANDONED sessions MUST be terminated and all associated resources reclaimed. Implementations MUST provide a configurable reconnection grace interval and SHOULD allow values sufficient to tolerate brief network outages on typical Wi‑Fi and WAN links. Servers SHOULD return a specific error status when a resume request targets an expired session. Long‑term persistence is an explicit, opt‑in behaviour: a session continues to exist beyond the reconnection grace period only if the user has explicitly detached it or otherwise marked it for later resumption. Implementations MUST NOT retain ABANDONED or stale sessions indefinitely. The server SHOULD reclaim resources associated with inactive sessions according to local policy (e.g., idle timeout, logout event, or administrative limits). Only one transport association (client daemon instance) MUST be attached to a given session at a time in the base protocol. That association MAY provide one or more seats for the session, subject to server policy. An implementation MAY provide a mechanism that allows additional associations to attach to the same session (for example, for technical support), but such behaviour is outside the scope of this specification and MUST NOT alter the semantics defined for the single‑association model above. 4.8. Session and Seat Model Sessions MAY persist independently of client connections. When a client device disconnects, the associated session and its windows MAY remain active in either the GRACE or DETACHED state. The compositor MAY blank or lock the session’s outputs according to local policy while no seat is attached. When a user resumes a session (from GRACE or DETACHED), the server: 1. Binds a new seat_id to the resumed session. 2. Sends the current window list, geometry, and focus state. 3. Associates the new seat’s outputs with the session. MWS supports both independent sessions and multi‑seat attachment within a single session. A user may maintain multiple concurrent sessions (e.g., one on the local console and another accessed remotely), or may attach multiple seats to the same session via a single transport association, subject to the single‑association rule in Section 4.7. MWS also supports explicit session detachment. A user may detach a running session, leaving its windows, compositor state, and GPU resources active on the server without any attached seats. The user may then initiate a new session on the same client device (e.g., to perform unrelated work) and later resume the detached session exactly where it was left. This behaviour is directly analogous to detaching and reattaching a GNU Screen or tmux session, but applied to a full graphical desktop environment spanning one or more seats. 4.9. Local Transport Profile (Non‑Normative) Although MWS treats all client devices as untrusted endpoints and applies the same protocol semantics regardless of network location, implementations MAY apply transport‑layer optimisations when the client device and server reside on the same physical host. These optimisations MUST NOT alter protocol semantics, message ordering, authentication requirements, or session isolation, and MUST remain transparent to the terminal. Permitted implementation‑level optimisations include: • loopback‑specific SCTP acceleration • reduced cryptographic overhead • shared‑memory fast paths • GPU‑direct resource sharing where supported These optimisations MUST NOT: • grant additional privileges to local client devices • bypass certificate validation or PAM authentication • modify the behaviour of control, input, or rendering streams • introduce protocol features unavailable to remote client devices MWS remains a transport‑agnostic, network‑transparent window system. Local optimisations exist solely to ensure that client devices running on the same host as the server achieve performance comparable to traditional local‑only systems without compromising the zero‑trust security model. 4.10. Security Model All client devices are treated as untrusted. Trust is established exclusively through cryptographic identity and explicit authorisation rather than network location. The server enforces strict isolation between users, sessions, seats, and windows. In particular: • each session is bound to a single SCTP association, and the association identifier serves as the authoritative session identity • window identifiers are scoped to a session and cannot be referenced by other sessions • input events are scoped to a seat and session, and cannot target windows outside that session • clients cannot observe, enumerate, or reference resources belonging to other sessions • all client‑originated messages are validated before being processed Transport security is provided by DTLS with mutual authentication. When DANE is deployed, the client’s certificate is validated against DNSSEC‑protected TLSA records, ensuring that only devices explicitly provisioned by the domain administrator may initiate a connection. Device authentication alone does not grant access to a user session. MWS does not mandate a specific encryption mechanism beyond requiring confidentiality, integrity, and mutual authentication of endpoints. Deployments SHOULD use a transport that provides forward secrecy, such as DTLS 1.3, WireGuard, or IPsec with PFS‑enabled cipher suites. The choice of transport‑layer security does not affect protocol semantics, and MWS remains agnostic to whether encryption is provided by DTLS or by an external secure tunnel. User authentication is performed at the application layer using the mechanism‑agnostic model defined in Section 5.2.1. The server advertises supported mechanisms (e.g., “DANE”, “PAM”, “PASSWORD”, “FIDO2”), and the client selects one. This separation of device and user identity ensures that compromise of a device does not grant access to a user’s session without the corresponding user credential. The server validates all client‑originated messages, including window creation, input events, and rendering commands. A client may not reference windows, sessions, or resources outside its authenticated session. Attempts to do so are rejected with MWS_ERROR(type=600, fatal=0). Malformed or semantically invalid messages are ignored, and the session continues unless the error is marked fatal. The client is not part of the trusted computing base. It stores no confidential data, long‑term session state, or reusable credentials. If a client disconnects unexpectedly, the session persists only for the duration of the reconnection grace period unless the user has explicitly detached. After this period, the session is closed and applications terminate. Loss of the transport association for any reason (network failure, timeout, endpoint crash) is treated as a fatal transport error. The session MAY persist according to the rules in Section 4.7 and MAY be resumed from another client device subject to policy. 5. Protocol Specification 5.1. Message Framing All MWS messages consist of a fixed-size header followed by an optional payload. Messages are carried within a single SCTP user message and MUST NOT be fragmented across multiple SCTP user messages. The header format is: struct MwsHeader { uint32_t magic; // MWS_MAGIC_VALUE uint16_t type; // MWS_* opcode uint16_t reserved; // MUST be zero uint32_t length; // payload length in bytes }; The payload immediately follows the header. Implementations MUST validate the magic value, type, and length before processing the payload. Messages with invalid headers MUST be rejected with MWS_ERROR(type=600). 5.2. Control Messages (Stream 0) Control messages manage authentication, session establishment, window lifecycle, and compositor state. All control messages MUST be sent on SCTP Stream 0. The control channel is strictly ordered and defines the protocol state machine for session creation, resumption, and teardown. Rendering, input, and video fallback streams operate independently and are not blocked by control‑plane latency. 5.2.1. Initial Handshake (001–099) The initial handshake establishes protocol version, user identity, and session parameters. Mutual TLS (mTLS), optionally validated using DANE (Section 9.1), authenticates the client device at the transport layer. The application‑layer handshake authenticates the user and establishes a session. User authentication is mechanism‑agnostic. The server advertises one or more supported authentication mechanisms, and the client selects one. This allows deployments to integrate PAM, WebAuthn, FIDO2, Kerberos, OAuth2, or future mechanisms without modifying the protocol. The handshake proceeds as follows on SCTP Stream 0: 1. MWS_QUERY (type=001) — Client → Server Initiates protocol negotiation and requests session parameters. 2. MWS_AUTH_CHALLENGE (type=002) — Server → Client Advertises the available authentication mechanisms. The payload contains a list of mechanism identifiers (e.g., "PAM", "PASSWORD", "FIDO2", "WEBAUTHN"). The server MAY advertise multiple mechanisms. The payload of MWS_AUTH_CHALLENGE has the following format: uint8_t mechanism_count; repeated mechanism_count times: uint8_t name_len; char name[name_len]; Mechanism names are UTF‑8 strings and are not NUL‑terminated. name_len specifies the length in bytes of each name and MUST be greater than zero. The payload MUST be exactly long enough to contain all advertised entries; extra bytes are a protocol error. mechanism_count MAY be zero. In this case the server is indicating that no authentication mechanisms are available, and the client MUST treat the challenge as a fatal configuration error and abort the handshake. Mechanism names are case‑sensitive identifiers drawn from the “MWS Authentication Mechanisms” registry (Section 9.2). 3. MWS_AUTH_RESPONSE (type=003) — Client → Server Selects an authentication mechanism and provides credentials or mechanism‑specific data. The payload contains: • selected mechanism identifier • mechanism‑specific credential payload The server MUST reject responses that specify a mechanism not offered in MWS_AUTH_CHALLENGE. The generic payload format of MWS_AUTH_RESPONSE is: uint8_t mech_name_len; char mechanism[mech_name_len]; uint16_t credential_len; uint8_t credential[credential_len]; mechanism is a UTF‑8 identifier that MUST exactly match one of the mechanism names advertised in the preceding MWS_AUTH_CHALLENGE. mech_name_len specifies the length in bytes of the mechanism identifier and MUST be greater than zero. credential is an opaque mechanism‑specific blob whose internal structure is defined by the selected mechanism. Implementations MUST NOT inspect or reinterpret credential except as specified by the mechanism definition. If mechanism does not correspond to an advertised entry, or if credential_len does not match the actual payload length, the server MUST treat this as a protocol error and respond with MWS_ERROR(type=600, fatal=1). 4. MWS_SURFACE_CAPS (type=004) — Server → Client Returns surface and WSI capability information, including supported Vulkan extensions, swapchain formats, and presentation modes. 5. MWS_SESSION_INFO (type=005) — Server → Client Returns session parameters, including: • session identifier • initial compositor state • seat and input configuration • resume token (if applicable) After successful completion of this sequence, the client is fully authenticated and may create windows or resume an existing session on Streams 1‑15. All multi‑byte integer fields in MWS messages are encoded in network byte order (big‑endian). Implementations MUST convert values to and from host byte order when constructing or parsing messages. Structures shown in this document illustrate field layout only and do not imply host endianness. 5.2.1.1 Session Identifier Semantics The session identifier returned in MWS_SESSION_INFO is assigned solely by the server. Clients MUST treat this value as opaque and MUST NOT attempt to select, predict, or construct session identifiers. All client-originated messages that include a session_id field are advisory; the server MUST validate the session_id against the session associated with the SCTP association on which the message was received. A client MUST NOT assume that a session identifier remains valid across reconnects unless the server has explicitly offered the session for resumption. Session identifiers from terminated or reclaimed sessions MUST NOT be reused by the server. Resume tokens included in MWS_SESSION_INFO are hints that allow clients to correlate local state with resumable sessions. Resume tokens are not client-authoritative and MUST be validated by the server during MWS_SESSION_RESUME_REQUEST processing. 5.2.2. Session Management (100–199) Session resume allows a client to reattach to an existing session previously detached by the user. MWS_SESSION_RESUME_OFFER (type=100) — Server → Client Indicates that a resumable session exists for the authenticated user. MWS_SESSION_RESUME_REQUEST (type=101) — Client → Server Requests resumption of the indicated session. MWS_SESSION_RESUME_COMPLETE (type=102) — Server → Client Confirms that the session has been resumed and provides updated compositor state. 5.2.2.1 Resume Semantics A session becomes resumable when the user has explicitly detached it or when the SCTP association has been lost and the session has entered the reconnection grace period defined in Section 4.7. The server MUST NOT offer resumption for sessions that have been terminated or reclaimed by policy. After successful user authentication, the server MUST send MWS_SESSION_RESUME_OFFER (type=100) if and only if one or more resumable sessions exist for the authenticated user. The offer includes a list of resumable session identifiers and MAY include metadata such as creation time, last activity time, or compositor state summary. If no resumable sessions exist, the server MUST NOT send a resume offer. To resume a session, the client sends MWS_SESSION_RESUME_REQUEST (type=101) specifying the session identifier. The server MUST validate that the requested session: • belongs to the authenticated user • is currently resumable • is not attached to another client device, unless local policy permits forced detachment If validation succeeds, the server MUST attach the client to the session, cancel any active reconnection grace timer, and send MWS_SESSION_RESUME_COMPLETE (type=102) containing the updated compositor state. MWS_SESSION_RESUME_COMPLETE MUST include a complete reconstruction of session state sufficient for the client to synchronise its local representation, including the window list, geometry, stacking order, focus state, and seat/output mappings. If validation fails, the server MUST reject the request with MWS_ERROR(type=600, fatal=0) and MUST NOT reveal the existence or attributes of sessions belonging to other users. Resume tokens provided in MWS_SESSION_INFO are advisory hints that allow clients to identify resumable sessions across reconnects. Resume tokens are not client-authoritative; the server MUST validate all resume requests against its internal session table. Only one client device MAY be attached to a session at a time. If a second device attempts to resume an active session, the server MUST either reject the request or forcibly detach the existing client, according to local policy. 5.2.3. Window Lifecycle (200–299) Window creation, destruction, mapping, and configuration are managed through the following messages: MWS_CREATE_WINDOW (type=200) — Client → Server Requests creation of a new top‑level window. The window is created within the session associated with the SCTP association on which the request was received. MWS_WINDOW_CREATED (type=201) — Server → Client Confirms window creation and returns window_id and initial geometry. MWS_DESTROY_WINDOW (type=202) — Client → Server Requests destruction of a window owned by the session. MWS_WINDOW_DESTROYED (type=203) — Server → Client Confirms destruction of a window. MWS_MAP_WINDOW (type=204) — Client → Server Requests that a window become visible. MWS_UNMAP_WINDOW (type=205) — Client → Server Requests that a window become hidden. MWS_CONFIGURE_WINDOW (type=206) — Server → Client Notifies the client of geometry or state changes. MWS_FOCUS_WINDOW (type=207) — Server → Client Notifies the client that a window has gained or lost focus. MWS_SWAPCHAIN_REVOKED (type=208) — Server → Client Indicates that a window’s swapchain has been revoked due to policy, timeout, or resource constraints. 5.2.3.1. Window Identifier Scope Window identifiers are scoped to the session that created them. A client MUST NOT reference, manipulate, or query windows belonging to any other session. The server MUST validate that all window-related messages refer to windows owned by the session associated with the SCTP association on which the message was received. If a client attempts to reference a window outside its session, the server MUST reject the message with MWS_ERROR(type=600, fatal=0). The server MUST NOT reveal the existence, geometry, focus state, or any other attributes of windows belonging to other sessions. Window identifiers are never reused across sessions, and the server MUST ensure that identifiers from one session cannot collide with or be interpreted as identifiers from another. Implementations MAY use per-session identifier namespaces, randomised identifiers, or any other mechanism that guarantees isolation. These rules ensure that windows are private to the session that owns them and that clients cannot observe or interfere with the graphical state of other users. 5.3. Rendering Commands (300–399) — Stream 1 Rendering commands are delivered on SCTP Stream 1. Commands are validated and executed by the server. MWS_VK_SUBMIT (type=300) — Client → Server Submits a VkCommandBuffer for execution. MWS_VK_SYNC (type=301) — Client → Server Requests synchronisation of GPU state. MWS_VK_DESTROY (type=302) — Client → Server Requests destruction of Vulkan resources associated with a window or pipeline. 5.4. Input Events (400–499) — Stream 2 Input events are delivered on SCTP Stream 2. All input events MUST be tagged with a seat_id and window_id. MWS_INPUT_EVENT (type=400) — Client → Server Delivers an XI2‑compatible input event. MWS_INPUT_ACK (type=401) — Server → Client Acknowledges receipt of an input event. 5.4.1. Pointer Motion Events Pointer motion is reported using both absolute and relative coordinates. All motion events, including mouse_move and mouse_drag, MUST include the following fields: • x, y: absolute pointer position in surface‑local pixel units (uint32) • delta_x, delta_y: relative motion since the previous pointer event, in signed pixel units (int16) Terminals MUST send both absolute and relative values. The compositor uses absolute coordinates for hit‑testing and focus routing, and MAY use relative deltas for high‑precision motion, gesture recognition, or sub‑pixel accumulation. A delta of zero indicates no relative motion. mouse_move Generated when the pointer moves with no buttons held. mouse_drag Generated when the pointer moves while one or more buttons are held. Encoded identically to mouse_move, with the addition of a bitmask of currently‑held buttons. 5.4.2 Input Scoping and Session Isolation Input events are scoped to the session and seat from which they originate. A client MUST NOT send input events targeting windows belonging to any other session. The server MUST validate that the seat_id and window_id in every MWS_INPUT_EVENT refer to resources owned by the session associated with the SCTP association on which the message was received. If a client attempts to deliver input to a window outside its session, the server MUST reject the message with MWS_ERROR(type=600, fatal=0). The server MUST NOT reveal the existence, geometry, focus state, or any other attributes of windows belonging to other sessions. Each session owns exactly one logical seat unless additional seats have been explicitly negotiated. seat_id values are therefore scoped to the session and MUST NOT collide with or reference seats belonging to other sessions. These rules ensure that input events cannot be redirected, spoofed, or injected across session boundaries, and that clients cannot observe or influence the input state of other users. 5.5. Video Fallback (500–599) — Stream 3 Video fallback is used when server‑side rendering produces a pixel stream rather than a Vulkan command stream. Stream 3 uses PR‑SCTP to allow frame drops under congestion. MWS_AV1_FRAME (type=500) — Server → Client Delivers an AV1‑encoded video frame. MWS_PLACEHOLDER_FRAME (type=501) — Server → Client Delivers a placeholder frame when rendering is unavailable. 5.6. Protocol State Machine 5.6.1. Initial Connection client server streams ====== ====== ======= (DTLS/SCTP handshake) [TLS] MWS_QUERY -------------------------------------> Stream 0 MWS_AUTH_CHALLENGE <--- MWS_AUTH_RESPONSE -----------------------------> Stream 0 MWS_SURFACE_CAPS <----- MWS_SESSION_INFO <----- MWS_CREATE_WINDOW -----------------------------> Stream 0 MWS_WINDOW_CREATED <--- MWS_MAP_WINDOW --------------------------------> Stream 0 MWS_VK_SUBMIT ---------------------------------> Stream 1 MWS_AV1_FRAME <-------- Stream 3 MWS_INPUT_EVENT -------------------------------> Stream 2 MWS_INPUT_ACK <-------- [optional MWS_CONFIGURE_WINDOW] [optional MWS_FOCUS_WINDOW] [optional MWS_SWAPCHAIN_REVOKED] [optional MWS_WINDOW_DESTROYED] 5.6.2. Session Resume client server ====== ====== (DTLS/SCTP handshake) MWS_QUERY -------------------> <------------------ MWS_SESSION_RESUME_OFFER MWS_SESSION_RESUME_REQUEST --> <------------------ MWS_SESSION_RESUME_COMPLETE 5.7. WSI Extension (Surface Creation) MWS defines a Vulkan WSI extension for creating surfaces associated with MWS windows. All WSI requests are validated by the server. typedef struct VkMWSSurfaceCreateInfoMWS { VkStructureType sType; const void* pNext; VkDevice device; uint32_t session_id; uint32_t sctp_stream_id; uint32_t window_id; VkExtent2D initial_extent; } VkMWSSurfaceCreateInfoMWS; VkResult mwsCreateMWSSurfaceMWS( VkInstance instance, const VkMWSSurfaceCreateInfoMWS* pCreateInfo, const VkAllocationCallbacks* pAllocator, VkSurfaceKHR* pSurface ); Surface creation proceeds as follows: 1. The client calls vkCreateInstance(), receiving MWS_SURFACE_CAPS. 2. The client calls mwsCreateMWSSurfaceMWS() with session and window parameters. 3. The server validates the request and creates a VkSurfaceKHR bound to the specified window_id. 4. The client calls vkCreateSwapchainKHR() on the returned surface. 5.7.1. Surface Binding and Session Validation The fields session_id, sctp_stream_id, and window_id in VkMWSSurfaceCreateInfoMWS are not client-authoritative. They are treated as requests that the server MUST validate against the session associated with the SCTP association on which the WSI request was received. The server MUST enforce the following rules: • session_id MUST match the authenticated session associated with the SCTP association. A client MUST NOT request creation of a surface for any other session. • window_id MUST refer to a window owned by the same session. The server MUST reject any request that attempts to bind a surface to a window belonging to another session. • sctp_stream_id MUST match the rendering stream allocated to the specified window. The server MUST reject requests that specify an incorrect or unauthorised stream. If any of these validations fail, the server MUST reject the request with MWS_ERROR(type=600, fatal=0). The server MUST NOT reveal the existence, geometry, or state of windows belonging to other sessions. These rules ensure that surface creation cannot be used to infer or access the graphical resources of other users, and that Vulkan surfaces remain correctly bound to the window and rendering stream allocated by the compositor. 5.7.2. Required Enums #define VK_STRUCTURE_TYPE_MWS_SURFACE_CREATE_INFO_MWS 1000053000 5.8. Error Handling (600–699) Errors are reported using the MWS_ERROR message. Errors are asynchronous and MAY be sent by either endpoint on any stream. Control-plane errors SHOULD be sent on Stream 0. Errors relating to rendering, input, or video fallback MAY be sent on the stream on which the offending message was received. Receipt of an error does not terminate the SCTP association unless the error is marked fatal. MWS_ERROR (type=600) Reports a protocol, semantic, or transport-related error. Fields: uint32_t error_code; uint32_t offending_type; // MWS_* opcode that caused error uint32_t window_id; // 0 if not applicable uint32_t fatal; // 0 = recoverable, 1 = fatal char description[]; // UTF-8 diagnostic string Error classes: • Protocol errors: – unknown or unsupported opcode – malformed header or payload – invalid magic value – message sent on the wrong SCTP stream – invalid length field – framing violations Protocol errors are fatal unless explicitly stated otherwise or the endpoint can reliably discard the offending message without desynchronising protocol state. • Semantic errors: – referencing a window outside the authenticated session – referencing a destroyed or revoked resource – message not valid in the current protocol state – invalid seat_id or session_id Semantic errors are recoverable unless otherwise stated. • Policy errors: – compositor policy violation – swapchain revoked due to timeout or resource pressure Policy errors are recoverable unless the compositor explicitly marks them fatal. • Timeout errors: – expected reply not received within implementation-defined limits – client or server unresponsive Timeout errors MAY be fatal depending on implementation policy. • Transport errors: – SCTP association loss – excessive retransmissions – PR-SCTP frame discard (non-fatal) Transport errors reflect underlying SCTP conditions. Association loss is always fatal. • Endpoint failures: – server crash or restart – client crash or termination Endpoint failures are fatal conditions and do not generate MWS_ERROR messages. Recoverable errors (fatal=0) indicate that the offending message has been ignored and the session MAY continue. Fatal errors (fatal=1) indicate that the SCTP association MUST be closed immediately after transmitting the error, unless the error prevents the message from being parsed. Loss of the SCTP association for any reason (network failure, timeout, endpoint crash) is treated as a fatal error. The session MAY persist according to the rules in Section 4.7. All error_code and window_id fields follow the network-byte-order rules defined in Section 5.1. 5.8.1. Session and Resource Validation Errors The server MUST validate that all window_id, seat_id, and session_id fields in client-originated messages refer to resources owned by the authenticated session associated with the SCTP association on which the message was received. The following conditions constitute session and resource validation errors (a subclass of semantic errors) and MUST be reported using MWS_ERROR(type=600, fatal=0): • referencing a window belonging to another session • referencing a seat belonging to another session • attempting to bind a Vulkan surface to a window outside the authenticated session • specifying an sctp_stream_id that does not match the rendering stream allocated to the window • attempting to resume or manipulate a session not associated with the current SCTP association • providing a session_id that does not match the authenticated session When reporting such errors, the server MUST NOT reveal the existence, geometry, focus state, or any other attributes of resources belonging to other sessions. The window_id field in the error message MUST be set to zero if revealing the true identifier would disclose cross-session state. These rules ensure that clients cannot infer the presence of other users, windows, or seats, and that all resource identifiers remain strictly scoped to the authenticated session. 6. Reference Implementation A reference implementation of the Mercurius Window System (MWS) is provided to validate the protocol, exercise compositor and rendering paths, and demonstrate interoperability between server and client components. The implementation is intentionally minimal: it confirms architectural correctness rather than providing a production‑ready desktop environment. The reference implementation reflects a common deployment model in which a single powerful workstation is accessed from multiple untrusted, mobile, or ephemeral terminal devices across a high‑bandwidth local network. MWS is designed for this pattern: the workstation is the authoritative environment, and terminal devices act solely as access points. The reference implementation validates this model and provides a foundation for further development. 6.1. Server Components (meta‑mws‑server) The meta‑mws‑server package installs all components required to run an MWS server on a workstation. It is expected to be installed on the machine that owns GPU resources, sessions, and compositor state. mwsd The primary MWS server daemon. Implements SCTP transport, DTLS mutual authentication, DANE validation of server and client certificates, PAM integration, Vulkan rendering, compositor policy, and validation layers. Owns all session, seat, and window state and enforces the security and isolation rules described in Sections 3–5. mlogo A minimal Phase 1 test client that runs on the server and connects to the local mwsd instance. Used to validate transport, handshake, session establishment, and basic rendering on the workstation itself. Displays a static Mercurius logo in a window managed by the compositor and exits. This client is analogous to the historical xlogo utility used to verify X11 transport and rendering. 6.2. Client Components (meta‑mws‑client) The meta‑mws‑client package installs all components required to run MWS terminals on untrusted or mobile devices. It is expected to be installed on laptops, thin clients, or other endpoints that attach to an MWS workstation over the network. mwsc The primary client executable. Implements the client‑side transport stack, handshake logic, window management, and event routing. Uses the shared protocol definitions described in Section 5. libmws.a Static client library providing SCTP/DTLS transport bindings, DANE‑validated mTLS authentication, AV1 decode (via dav1d) for Stream 3 fallback, and Vulkan loader integration. Intended for use by test clients and early adopters. The library is built as a single static archive to simplify deployment and avoid external runtime dependencies on terminal devices. mws_protocol.h Public protocol header defining all message types, opcodes, structure layouts, and constants corresponding to the formats described in Section 5. This header is generated directly from the protocol specification and opcode registry (Appendix A) and is intended to remain stable across minor revisions. 6.3. Demonstration Clients In addition to mlogo, the reference implementation includes (or anticipates) progressively more complex demonstration clients. These clients are not part of the core protocol but are essential for validating compositor behaviour, swapchain management, input latency, and long‑running rendering workloads. Installation of these clients MAY be provided by either meta‑mws‑server or meta‑mws‑client depending on deployment preferences. 6.3.1. Screensaver Demonstration A port or adaptation of a classic Unix screensaver (e.g. from the XScreenSaver collection) is provided as a mid‑complexity test client. This client exercises continuous animation, swapchain reuse, timing stability, and fallback video paths. It validates that MWS can sustain long‑running rendering without resource leaks or timing drift and that video fallback on Stream 3 behaves correctly under varying bandwidth conditions. 6.3.2. Indie Game Demonstration A small Vulkan‑ or OpenGL‑based indie game is used as a high‑complexity test client. This client exercises real‑world interactive rendering workloads, including continuous animation, high‑frequency input events, window focus changes, and typical GPU command patterns found in games. It validates that MWS can host practical latency‑sensitive graphical applications while maintaining low input latency, stable frame pacing, and correct swapchain behaviour. This demonstrates that MWS supports realistic workloads beyond synthetic benchmarks. 6.4. Dependencies The reference implementation targets a contemporary Linux environment. The following libraries are required by the provided server and client components: libsctp1 SCTP stack (Linux 6.8 or later recommended). vulkan‑tools Vulkan loader and validation layers. libdav1d AV1 decoder used for Stream 3 fallback. libpam0g PAM authentication backend. libtevent Asynchronous event loop library. 6.5. Bootstrap Example This example illustrates a minimal two‑host deployment in which a workstation (xavier) runs the MWS server and application processes, and a remote terminal (flash) provides the users display and input. All connections use the default SCTP transport. For this example there are two hosts: • xavier: a workstation acting as the server • flash: a thin client 1. Start the MWS server on xavier: xavier$ mwsd --port 49152 This starts the MWS server daemon mwsd on xavier, listening for DTLS/SCTP associations on port 49152 and exposing the compositor and session manager to remote terminals. 2. Start the terminal on flash and attach to xavier: flash$ mwsc --server xavier --port 49152 This starts the MWS terminal client on flash. It connects to xavier:49152 over DTLS/SCTP, performs mutual certificate authentication (optionally validated via DANE), completes user authentication, and establishes a session and seat bound to the display and input devices on flash. 3. Run the test application on xavier: xavier$ mlogo The mlogo client connects to the local mwsd instance on xavier, joins the existing session associated with the seat on flash, creates a window, and maps it. The Mercurius logo appears on the display attached to flash while the application process executes on xavier. This bootstrap validates the end‑to‑end path between a workstation and a remote terminal: DTLS/SCTP transport establishment, DANE‑validated certificate authentication, user authentication, session and seat creation, window creation and mapping, swapchain initialisation, and basic GPU rendering. 7. Implementation Requirements and Validation This section defines normative requirements for any conformant MWS implementation. These requirements ensure correct behaviour under load, predictable session semantics, and robust isolation between clients. The reference implementation demonstrates these properties but does not attempt to optimise for all hardware configurations. 7.1. Test Matrix An implementation of MWS MUST demonstrate correct behaviour across four major dimensions: • Session semantics — creation, resume, detachment, identifier stability, and state continuity. • Window lifecycle — creation, mapping, resizing, destruction, and identifier scoping. • Rendering correctness — surface creation, command ordering, GPU isolation, and frame delivery. • Transport behaviour — SCTP stream allocation, ordering guarantees, error handling, and reconnection. The following matrix defines the minimum set of tests required to validate interoperability between an MWS client and server. These tests are not exhaustive; they represent the baseline necessary to confirm that the architectural components described in this document behave as specified. 7.1.1. Core Validation Tests +------------------------+----------------------------+------------------+ | Test Case | Description | Success Criteria | +------------------------+----------------------------+------------------+ | Bootstrap + Render | Establish a session and | Initial frame | | | render a minimal surface | displayed in a | | | using the reference | reasonable time | | | client. | on reference | | | | hardware; | | | | session | | | | terminates or | | | | detaches cleanly.| +------------------------+----------------------------+------------------+ | Window Lifecycle | Create, map, unmap, and | Correct | | | destroy a window while | CREATE→MAP→ | | | observing compositor | UNMAP→DESTROY | | | events. | sequence; no | | | | orphaned | | | | resources. | +------------------------+----------------------------+------------------+ | Session Persistence | Start a session, detach or | Session resumes | | | allow the client to | with compositor | | | disconnect, then resume | state | | | using the same session | reconstructed as | | | identifier. | defined in | | | | Sections 4.7 and | | | | 5.2.2; client | | | | can redraw | | | | without protocol | | | | violations. | +------------------------+----------------------------+------------------+ | GPU Isolation | Run multiple clients | No cross‑session | | | concurrently, each | resource leakage;| | | creating independent | surfaces and | | | surfaces. | windows remain | | | | isolated. | +------------------------+----------------------------+------------------+ | Transport Stream | Exercise streams 0–3 with | No reordering | | Allocation | mixed control, rendering, | within a stream; | | | input, and video fallback | correct routing | | | traffic. | based on session | | | | and window IDs. | +------------------------+----------------------------+------------------+ | Input Event Semantics | Deliver pointer and | Events delivered | | | keyboard events to | only to the | | | multiple windows across | focused window; | | | seats. | correct seat and | | | | session scoping. | +------------------------+----------------------------+------------------+ | Error Handling | Trigger invalid IDs, | Server returns | | | malformed messages, and | appropriate | | | protocol violations. | error codes | | | | (600–699) as | | | | defined in | | | | Section 5.8; | | | | session integrity| | | | maintained. | +------------------------+----------------------------+------------------+ 7.1.2. Reference Implementation Commands (Non‑Normative) The reference implementation provides convenience tools for exercising the above tests. The following examples illustrate the intended usage pattern; conforming implementations MAY use any equivalent mechanism. For this example there are two hosts: • xavier: a workstation acting as the server • flash: a thin client • Bootstrap + Render: xavier$ mwsd --port 49152 flash$ mwsc --server xavier --port 49152 xavier$ mlogo Expected result: a logo window appears on the display attached to flash; mlogo exits with status 0. • Window Lifecycle: xavier$ mlogo --once Expected result: the server log shows a CREATE→MAP→DESTROY sequence for the test window; no orphaned compositor or GPU resources remain. • Session Persistence: flash$ mwsc --server xavier --port 49152 xavier$ mlogo [disconnect terminal or detach session, then resume] Expected result: the session resumes with windows and compositor state reconstructed as defined in Sections 4.7 and 5.2.2; the client can re‑establish rendering without violating protocol or WSI rules. • GPU Isolation: xavier$ mlogo & xavier$ mlogo & Expected result: independent windows are created in separate sessions without visible interference; destroying one client does not affect the others. These examples are illustrative only. They do not form part of the normative protocol and do not constrain implementation‑specific tooling. 7.2. GPU Isolation Requirements Implementations MUST ensure that GPU workloads from one session cannot compromise the integrity or confidentiality of another session’s resources. • The server SHOULD avoid allowing GPU workloads from one session to starve or block those of another. Implementations MAY use separate Vulkan queues, queue subsets, or fair scheduling mechanisms to achieve this. • The server MUST validate VkCommandBuffer submissions sufficiently to prevent malformed or out‑of‑bounds accesses that would violate isolation guarantees. Invalid or malformed command buffers MUST be rejected without execution. • The server MUST enforce per‑session limits on GPU resource usage, including device memory, descriptor sets, and command buffer size. When limits are exceeded, the server MAY throttle, reject further submissions, or terminate the session. • The server SHOULD implement watchdog mechanisms to detect and recover from GPU hangs attributable to a particular session. Recovery MAY include resetting client queues, revoking swapchains, or terminating the offending session while preserving other sessions. 7.3. Bandwidth and Transport Isolation Requirements Implementations MUST ensure that control and input remain responsive under load and that one client cannot monopolise transport resources to the detriment of others. • Stream 0 (control) and Stream 2 (input) MUST use reliable, ordered delivery and MUST be prioritised over bulk data on other streams. • Stream 1 (rendering commands) MUST use reliable, ordered delivery. The server MAY impose rate limits on VK_SUBMIT or equivalent rendering messages to prevent excessive queueing. • Stream 3 (AV1 fallback video) MAY use partially reliable delivery (PR‑SCTP). The server MAY drop frames under congestion to maintain interactivity. • The server SHOULD implement per‑session or per‑client bandwidth limits to prevent link saturation. Limits MAY be enforced at the SCTP layer, via traffic shaping, or using equivalent mechanisms. • The server MUST be able to unilaterally terminate a misbehaving client without impacting other sessions. Termination SHOULD be signalled with MWS_ERROR(type=600, fatal=1) followed by closure of the SCTP association, as defined in Section 5.8. Termination MUST release all GPU, transport, and compositor resources associated with that client, and MUST NOT affect other active sessions. 8. Performance Considerations MWS is designed for environments where the workstation and client devices are connected by modern high‑bandwidth, low‑latency networks. Contemporary 10 GbE and fibre‑backed LANs routinely deliver round‑trip latencies on the order of 200–500 µs; in such environments the network contributes only a small fraction of the end‑to‑end input‑to‑display path. A typical RTT in this range implies one‑way transport latency well below 0.5 ms, meaning that interactive responsiveness is dominated by GPU encode and decode rather than by the network. Modern GPUs provide hardware‑accelerated AV1 encoding with sub‑millisecond latency for common workstation resolutions. Because MWS performs all rendering and compositing on the server, and because clients do not execute application code or GPU workloads, the client‑side overhead is minimal. This eliminates the multiple GPU round‑trips, buffer copies, and synchronisation barriers found in traditional remote‑desktop systems, where the client must composite, scale, or colour‑convert frames before display. By reducing the client to a lightweight presentation endpoint with minimal CPU and GPU involvement, MWS ensures that interactive latency is dominated by server‑side encode time rather than by client‑side processing. As a result, a remote graphical session over a modern LAN is effectively indistinguishable from local use for typical workstation workloads. The following non‑normative figures illustrate achievable encode‑and‑transport performance on a 10 GbE LAN using an RTX 5070‑class GPU. These values represent server‑side encode latency plus network transit time under ideal conditions; they do not include client‑side display latency. +===============+==========+==========================+======+ | Resolution | Bitrate | Encode+Transport Latency | CPU | +===============+==========+==========================+======+ | 4K60 HDR | 200 Mbps | <0.5 ms | <1% | +---------------+----------+--------------------------+------+ | 4K120 Gaming | 500 Mbps | <1.0 ms | <2% | +---------------+----------+--------------------------+------+ | 8K60 HDR | 1.2 Gbps | <1.5 ms | <3% | +===============+==========+==========================+======+ These figures demonstrate that MWS can support high‑resolution, high‑refresh‑rate graphical workloads over a modern LAN without compromising interactive performance. For typical desktop and workstation applications, the resulting experience is comparable to local use. 9. Security Considerations MWS is designed according to zero‑trust principles: no client device, network segment, or intermediary is implicitly trusted. All trust is derived from cryptographic identity and explicit authorisation rather than network location. The protocol assumes that client devices may be compromised, mobile, or operating on hostile networks, and that attackers may observe, inject, or replay traffic unless prevented by cryptographic protections. Transport security is provided by a secure datagram transport with mutual authentication (for example, DTLS over SCTP). When DANE is deployed, the client and server certificates are validated against DNSSEC‑protected TLSA records, ensuring that only devices explicitly provisioned by the domain administrator may initiate a connection. Deployments without DNSSEC or without control over their DNS zone SHOULD use traditional PKI validation instead. User authentication is performed at the application layer using the mechanism‑agnostic model defined in Section 5.2.1. The server advertises supported mechanisms (e.g., "DANE", "PAM", "PASSWORD", "FIDO2") as UTF‑8 identifiers in MWS_AUTH_CHALLENGE, and the client selects one. This separation of device and user identity ensures that compromise of a device does not grant access to a user's session without the corresponding user credential. Each user is given an isolated session and compositor context. Clients cannot observe or interfere with other users' windows, input events, or rendering state. Window identifiers are scoped to a session, and all client‑originated messages are validated by the server. Attempts to reference resources outside the authenticated session are rejected with MWS_ERROR(type=600) as described in Section 5.8. Rendering commands (300–399), input events (400–499), and video frames (500–599) are isolated on separate SCTP streams to limit the impact of congestion or packet loss. Partially reliable delivery MAY be used for video fallback to avoid resource exhaustion and to prevent attackers from inducing excessive retransmissions without affecting control or input flows. The client is not part of the trusted computing base. It stores no confidential data, long‑term session state, or reusable credentials. If a client disconnects unexpectedly, the session persists only for the duration of the reconnection grace period unless the user has explicitly detached. After this period, the session is terminated and all associated resources are destroyed, as defined in Section 4.7. Loss of the transport association for any reason (network failure, timeout, endpoint crash) is treated as a fatal transport error. The session MAY persist according to the rules in Section 4.7 and MAY be resumed from another client device subject to policy. 9.1. DANE Deployment (Non‑Normative) Deployments that operate their own DNS infrastructure MAY use DNSSEC and TLSA records (DANE) to authenticate client and server certificates during the DTLS/SCTP handshake. When DNSSEC validation is available, DANE provides a robust mechanism for binding workstation and device identity to DNS without relying on public certificate authorities. When the "DANE" authentication mechanism is selected, the client proves possession of a private key whose certificate is published via a DNSSEC‑protected TLSA record. No credential payload is required in MWS_AUTH_RESPONSE (type=003); all authentication material is derived from the mutual‑TLS handshake and DNSSEC validation. This allows deployments to authenticate devices without storing reusable secrets on the client. DANE is OPTIONAL and does not alter the protocol semantics. When enabled, it reduces operational complexity in closed trust domains by eliminating external trust dependencies, simplifying certificate lifecycle management, and mitigating man‑in‑the‑middle attacks even in the event of public CA compromise. Deployments without DNSSEC or without administrative control over their DNS zone SHOULD use traditional PKI validation instead. 10. IANA Considerations This document requests two IANA actions: 1. Allocation of an SCTP port number for the Mercurius Window System (MWS). The suggested port is 49152. 2. Registration of the application‑layer protocol identifier (ALPN) "mws". No other registries are required. In particular, MWS message types, opcodes, and SCTP stream assignments are managed entirely within the protocol and do not require IANA allocation. 11. Acknowledgements Christopher Ross (chris@tebibyte.org) provided the initial design and reference implementation. The reference implementation described in Section 6 is available from the Mercurius project website at . The corresponding source code repository may be cloned via . SSH access is also available for contributors. These resources are provided for convenience and are non‑normative; the protocol defined in this document does not depend upon any specific implementation. 12. References 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. [RFC4895] Tuexen, M., Stewart, R., and P. Lei, "Authenticated Chunks for Stream Control Transmission Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August 2007. [RFC9260] Stewart, R., Tuexen, M., and X. Dutreilh, "Stream Control Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260, June 2022. [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018. 12.2. Informative References [VK14] Khronos Group, "Vulkan 1.4 Specification", 2024. [NIST800-207] National Institute of Standards and Technology, "Zero Trust Architecture", NIST Special Publication 800-207, August 2020. [RFC9261] Tuexen, M. and R. Stewart, "Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets", RFC 9261, DOI 10.17487/RFC9261, June 2022. 12.2. Informative References [VK14] Khronos Group, "Vulkan 1.4 Specification", 2024. [NIST800‑207] National Institute of Standards and Technology, "Zero Trust Architecture", NIST SP 800‑207, 2020. Appendix A. MWS Opcode Registry This appendix defines the complete registry of MWS opcodes. All opcodes are 16‑bit unsigned integers. Opcodes are grouped into 100‑entry ranges according to functional category. Implementations MUST treat unknown opcodes as protocol errors and respond with MWS_ERROR(type=600) as described in Section 5.8. A.1. Handshake and Authentication (000–099) NOTE: Type 000 is reserved and MUST be treated as a NULL/invalid value. Implementations encountering type=000 MUST respond with MWS_ERROR. 001 MWS_QUERY 002 MWS_AUTH_CHALLENGE 003 MWS_AUTH_RESPONSE 004 MWS_SURFACE_CAPS 005 MWS_SESSION_INFO 050–099 Reserved for future handshake extensions A.2. Session Management (100–199) 100 MWS_SESSION_RESUME_OFFER 101 MWS_SESSION_RESUME_REQUEST 102 MWS_SESSION_RESUME_COMPLETE 150–199 Reserved for future session‑management extensions A.3. Window Lifecycle (200–299) 200 MWS_CREATE_WINDOW 201 MWS_WINDOW_CREATED 202 MWS_DESTROY_WINDOW 203 MWS_WINDOW_DESTROYED 204 MWS_MAP_WINDOW 205 MWS_UNMAP_WINDOW 206 MWS_CONFIGURE_WINDOW 207 MWS_FOCUS_WINDOW 208 MWS_SWAPCHAIN_REVOKED 250–299 Reserved for future window‑lifecycle extensions A.4. Rendering Commands (300–399) 300 MWS_VK_SUBMIT 301 MWS_VK_SYNC 302 MWS_VK_DESTROY 350–399 Reserved for future rendering extensions (e.g., bitmap upload, GPU‑side composition, etc.) A.5. Input Events (400–499) 400 MWS_INPUT_EVENT 401 MWS_INPUT_ACK 450–499 Reserved for future input extensions (e.g., haptics, multi‑seat extensions) A.6. Video Fallback (500–599) 500 MWS_AV1_FRAME 501 MWS_PLACEHOLDER_FRAME 550–599 Reserved for future video‑fallback extensions A.7. Error Reporting (600–699) 600 MWS_ERROR 650–699 Reserved for future error‑reporting extensions A.8. Capability and Introspection (700–799) 700–799 Reserved for capability discovery, introspection, and future protocol‑negotiation mechanisms. A.9. Reserved for Future Extensions (800–899) 800–899 Reserved for future protocol extensions. A.10. Experimental and Vendor‑Specific (900–999) 900–999 Experimental, vendor‑specific, or implementation‑defined opcodes. These MUST NOT be used in interoperable deployments and MUST NOT be relied upon in Internet‑scale deployments. Appendix B. Authentication Mechanism Registry MWS supports a mechanism‑agnostic authentication model. During the initial handshake, the server advertises one or more authentication mechanisms using MWS_AUTH_CHALLENGE (type=002). The client selects a mechanism and responds with MWS_AUTH_RESPONSE (type=003), providing mechanism‑specific credentials or authentication data. This appendix defines the registry of authentication mechanism identifiers. Mechanism identifiers are UTF‑8 strings and are compared using case‑sensitive bytewise comparison. Identifiers MUST NOT exceed 64 bytes in length. Implementations MUST ignore unknown mechanism identifiers and MUST NOT attempt to interpret their payloads. Servers MUST NOT advertise mechanisms they do not fully support. B.1. Standard Mechanisms The following mechanism identifiers are defined by this specification: "PAM" The server authenticates the user using the system’s Pluggable Authentication Modules (PAM) stack. The credential payload contains a NUL‑terminated username followed by a NUL‑terminated password. "PASSWORD" A simple username/password mechanism. The credential payload contains a NUL‑terminated username followed by a NUL‑terminated password. This mechanism is intended for deployments that do not use PAM but still require password‑based authentication. "DANE" Authentication using DNSSEC‑validated TLSA records. The client proves possession of a private key whose certificate is bound to a DNS name via a TLSA record. When this mechanism is selected, the credential payload is empty; all authentication material is derived from the mTLS handshake and DNSSEC validation. This mechanism is intended for closed trust domains that operate their own DNSSEC infrastructure. B.2. Extensible Mechanisms The following identifiers are reserved for future specifications or external standards. Their payload formats are not defined by this document. "FIDO2" Authentication using a FIDO2 authenticator. "WEBAUTHN" Authentication using a WebAuthn ceremony. "KERBEROS" Authentication using a Kerberos AP‑REQ exchange. "OAUTH2" Authentication using an OAuth 2.0 device or authorization‑code flow. Servers MAY advertise any subset of these mechanisms. Clients MAY implement any subset. B.3. Private and Experimental Mechanisms Mechanism identifiers beginning with the prefix "X‑" are reserved for private, experimental, or vendor‑specific use. These identifiers MUST NOT appear in interoperable deployments or Internet‑facing services. Examples: "X‑FINGERPRINT" "X‑HARDWARE‑TOKEN" "X‑SSO‑PROTOTYPE" B.4. Registration Policy New mechanism identifiers MAY be defined by future MWS extensions or external standards. To avoid collisions, new identifiers SHOULD be registered with IANA if this specification is published on the IETF Standards Track. Until such time, implementers SHOULD use the "X‑" prefix for experimental mechanisms and MUST NOT assume global uniqueness. Appendix C. SCTP Stream Usage Summary MWS uses multiple SCTP streams to isolate control, rendering, input, and video traffic. This appendix summarises the required stream assignments. All streams use DTLS for confidentiality and integrity. Stream assignments are fixed and MUST NOT be repurposed for other message classes. Implementations MAY open additional streams for experimental or vendor‑specific extensions, provided they do not conflict with the assignments below. C.1. Stream 0 — Control Plane Stream 0 carries all ordered control‑plane traffic, including: • handshake messages (001–099) • session‑management messages (100–199) • window‑lifecycle messages (200–299) • error messages (600–699) Messages on Stream 0 MUST be delivered reliably and in order. C.2. Stream 1 — Rendering Commands Stream 1 carries rendering commands (300–399), including Vulkan command submission and GPU‑resource management. Messages on Stream 1 MUST be delivered reliably and in order. C.3. Stream 2 — Input Events Stream 2 carries input events (400–499), including keyboard, pointer, and tablet events. Messages on Stream 2 SHOULD be delivered reliably but MAY be processed out of order by the server if permitted by the input subsystem. C.4. Stream 3 — Video Fallback Stream 3 carries video‑fallback traffic (500–599), including AV1 frames and placeholder frames. Stream 3 MUST use PR‑SCTP (Partial Reliability SCTP) to allow frame discard under congestion. Implementations SHOULD use timed reliability or limited retransmission to avoid head‑of‑line blocking. C.5. Additional Streams Streams beyond Stream 3 are reserved for future extensions. Such extensions MUST specify: • reliability requirements (reliable, PR‑SCTP, unordered) • congestion‑control expectations • interaction with the control plane Experimental or vendor‑specific extensions SHOULD use streams ≥16 to avoid collision with future standardised assignments. Appendix D. Protocol State Machine Diagrams This appendix provides normative state‑machine diagrams for the MWS protocol. These diagrams illustrate the ordered interactions between client and server during initial connection, session resumption, and normal operation. All control‑plane transitions occur on SCTP Stream 0. Rendering, input, and video traffic occur on their respective streams as defined in Appendix C. D.1. Initial Connection State Machine +------------------+ | START | +------------------+ | | (DTLS/SCTP handshake) v +------------------+ | TRANSPORT_UP | +------------------+ | | MWS_QUERY (001) v +------------------+ | WAIT_AUTH | +------------------+ | | MWS_AUTH_CHALLENGE (002) v +------------------+ | AUTH_NEGOTIATE | +------------------+ | | MWS_AUTH_RESPONSE (003) v +------------------+ | AUTH_VERIFY | +------------------+ | | success → MWS_SURFACE_CAPS (004) | failure → MWS_ERROR (600, fatal=1) v +------------------+ | SEND_CAPS | +------------------+ | | MWS_SESSION_INFO (005) v +------------------+ | SESSION_READY | +------------------+ | | MWS_CREATE_WINDOW (200) v +------------------+ | WINDOW_CREATE | +------------------+ | | MWS_WINDOW_CREATED (201) v +------------------+ | ACTIVE_SESSION | +------------------+ | | normal operation: | • rendering (300–399) | • input (400–499) | • video fallback (500–599) v +------------------+ | RUNNING | +------------------+ D.2. Session Resume State Machine +------------------+ | START | +------------------+ | | (DTLS/SCTP handshake) v +------------------+ | TRANSPORT_UP | +------------------+ | | MWS_QUERY (001) v +------------------+ | WAIT_RESUME | +------------------+ | | MWS_SESSION_RESUME_OFFER (100) v +------------------+ | RESUME_OFFERED | +------------------+ | | MWS_SESSION_RESUME_REQUEST (101) v +------------------+ | RESUME_VERIFY | +------------------+ | | success → MWS_SESSION_RESUME_COMPLETE (102) | failure → MWS_ERROR (600, fatal=1) v +------------------+ | ACTIVE_SESSION | +------------------+ | | normal operation resumes v +------------------+ | RUNNING | +------------------+ D.3. Error Handling State Machine Errors may occur at any point in the protocol. The following diagram illustrates the error‑handling model: +------------------+ | ANY_STATE | +------------------+ | | recoverable error | MWS_ERROR (600, fatal=0) v +------------------+ | CONTINUE | +------------------+ | | fatal error | MWS_ERROR (600, fatal=1) v +------------------+ | TERMINATE | +------------------+ |o | SCTP association closed v +------------------+ | END | +------------------+ D.4. Stream Interaction Summary The following diagram illustrates the concurrency model across SCTP streams: Stream 0 (control): ordered, reliable • handshake (001–099) • session management (100–199) • window lifecycle (200–299) • errors (600–699) Stream 1 (rendering): ordered, reliable • Vulkan commands (300–399) Stream 2 (input): reliable; MAY be processed out of order • input events (400–499) Stream 3 (video): PR‑SCTP, typically unordered • AV1 frames (500–599) These streams operate independently. Loss or delay on one stream MUST NOT block progress on any other stream. 13. Copyright Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.