Network Working Group Christopher Ross Internet-Draft Independent Intended status: Experimental 09 August 2026 Expires: 09 February 2027 Mercurius Window System (MWS) draft-ross-mercurius-05 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. This Internet-Draft will expire on 09 February 2027. The latest version of this draft can be found at: https://mercurius.tebibyte.org/draft-ross-mercurius.txt Copyright Notice 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Abstract The Mercurius Window System (MWS) is a zero-trust network-native, server-side rendering system that enables graphical sessions to be accessed remotely with explicit semantics for Session, Window, and rendering state. MWS allows a user to interact with a workstation from untrusted or resource-constrained portal devices (thin clients or laptops acting as Mercurius terminals) while keeping authoritative application, GPU, and compositor state on the workstation. The protocol defines a zero-trust portal model, a structured Session and Window architecture, and a multi-stream SCTP transport profile. It defines distinct protocol planes for control, rendering, input, video, and audio. Some payload encodings remain subject to refinement in later revisions of this Internet-Draft. Executive Summary (Non-Normative) The Mercurius Window System (MWS) is a zero-trust, network-native Window system. Applications execute on a persistent workstation, where their data, processes, Session state, and GPU workloads remain authoritative. A user interacts with that workstation through a local or remote Portal over a well-provisioned network. A Portal provides a place from which the user inhabits the workstation; it is not the workstation and is not an authority over it. Portals may be shared, resource-constrained, physically exposed, lost, stolen, or compromised. Possession of a Portal does not authorise access. Each connection requires successful user authentication, and the server confines the resulting authority to the authenticated Session and its resources. MWS preserves the useful network transparency of X11 while replacing implicit trust with authenticated, Session-scoped authority and server-side policy enforcement. It treats Windows, rendering, and Session lifecycle as explicit protocol concepts rather than reducing the workstation to a remotely copied framebuffer. The result is a workstation-centric architecture in which local and remote presence are forms of the same graphical Session. 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. Portal 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 Portal 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. Audio Model 4.7. Stream Allocation 4.7.1. Session Identity and Message Routing 4.8. Session Lifecycle 4.9. Session and Seat Model 4.10. Local Transport Profile (Non-Normative) 4.11. Security Model 5. Protocol Specification 5.1. Message Framing 5.1.1. Transport Fragmentation 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 Messages (300-399) 5.4. Input Plane (400-499) -- Stream 2 5.4.1. Pointer Motion Events 5.5. Video Fallback (500-599) -- Stream 3 5.6. Audio Plane (600-699) -- Stream 4 5.7. Protocol State Machine 5.7.1. Initial Connection 5.7.2. Session Resume 5.8. WSI Extension (Surface Creation) 5.8.1. Surface Binding and Session Validation 5.8.2. Vulkan Extension Registration 5.9. Error Handling (700-799) 5.9.1. Session and Resource Validation Errors 6. Reference Implementation 6.1. Workstation Components 6.2. Portal Components 6.3. Demonstration Applications 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 Messages (300-399) A.5. Input Events (400-499) A.6. Video Plane (500-599) A.7. Audio Plane (600-699) A.8. Error Reporting (700-799) A.9. Transport Services (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 Messages C.3. Stream 2 -- Input Events C.4. Stream 3 -- Video Plane C.5. Stream 4 -- Audio Plane C.6. 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 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, audio devices, and local display. The same session may also be accessed from lightweight, mobile, or untrusted portal devices elsewhere, without replicating the workstation's software environment or exposing its data or GPU resources. Compute, storage, rendering, and audio processing remain on the workstation; Portals provide authenticated display, input, and audio endpoints. MWS is intended to let a workstation remain itself while being reached from elsewhere. The workstation is treated as a long-lived environment that accumulates tools, history, and identity; remote devices are simply places from which the user inhabits that environment. A user may begin work at a powerful machine in the office and later continue the same session from a laptop, thin portal, 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 merely a remote framebuffer protocol. It defines structured, message-oriented semantics for presence, Sessions, Windows, input, audio, and rendering state on a workstation. Even when carrying presented pixel buffers, it preserves the identity, ownership, geometry, lifecycle, and routing of each Window. The Transport is optimised for SCTP's multi-stream, message-oriented semantics [RFC9260], with separate streams assigned or reserved for control, rendering, input, video, and audio. 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 [NIST800-207], authenticated multi-stream transport [RFC9260][RFC4895], 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 portals, 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 Window System (MWS) protocol, the transport-level protocol used by MWS to establish, authenticate, and maintain a user's graphical presence on a workstation. The MWS protocol defines Message framing, authentication, Session attachment, Window lifecycle, and rendering presentation over a secure transport profile based on DTLS 1.3 [RFC9147] over SCTP [RFC9260], using the mapping defined by [I-D.6083BIS]. It specifies the semantics and requirements of the input, video, and audio planes while leaving payload details that are not yet stable to later revisions of this Internet-Draft. 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 * portals may be untrusted, mobile, or ephemeral * users may relocate sessions across devices * GPU-accelerated workloads must remain server-resident * audio capture and playback must remain server-resident or explicitly brokered * 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 portal capabilities, and CPU-bound rendering are incompatible with modern zero-trust requirements and GPU-accelerated workloads [NIST800-207]. 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 portals. 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 DTLS 1.3 [RFC9147], authenticated SCTP [RFC9260][RFC4895] streams, and per-portal GPU isolation. Rendering is server-resident and GPU-accelerated; Portals receive presentation Messages produced by the workstation, and audio is carried as explicit timestamped streams rather than device-local side effects. All compositor policy, input routing, and window management occur on the server, ensuring multi-user correctness and preventing privilege escalation. Crucially, possession of a portal device is never sufficient to access the workstation. Session resume requires fresh user authentication, and no sensitive data or reusable credentials are stored on the portal. 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 portals or mobile devices. Public cloud deployments exhibit similar characteristics: applications execute on remote servers while portals 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 portals are untrusted, MWS ensures that compromise or loss of a portal 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 portals connect over well-provisioned LANs and VPNs, typically with DANE [RFC6698][RFC7671] authenticating DTLS 1.3 [RFC9147] carried over SCTP as defined by [I-D.6083BIS]. 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. All workstation rendering in MWS is performed using the Vulkan [VK14] API. 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. Portal Requirements and Wireless Considerations MWS portals are treated as untrusted endpoints. Practical deployments assume a minimum level of capability. A typical portal 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 portals 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 portal connections, the system naturally supports detachable operation. A user may disconnect from one portal and later resume the same session from another device, with all windows, GPU state, and compositor context preserved. This model is conceptually similar to portal 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. Deployments are expected to configure a reconnection grace period so that brief network outages or short unscheduled breaks such as to move or charge a portal device do not cause the user's session to be lost. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Terminology relating to Vulkan follows the definitions and naming conventions of the Vulkan 1.4 specification [VK14]. Terminology relating to SCTP follows the Stream Control Transmission Protocol specification [RFC9260]. Terminology relating to DTLS 1.3 follows the Datagram Transport Layer Security specification [RFC9147]. 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. * "portal device" refers to the physical device used by a user to access the workstation. Examples include laptops, tablets, phones, thin portals, and embedded devices. * "portal" refers to the MWS portal component (mwsc) running on the portal device and, once connected, to its logical role as a seat-providing endpoint. A portal is the protocol endpoint that communicates with the server and creates a seat for a session. * "session" refers to a persistent graphical environment maintained on the workstation independently of portal connections. * "association" refers to a transport-bound communication channel between a portal and the server. When SCTP is used as the transport, an association corresponds exactly to the SCTP association defined in RFC 9260 and is identified by the SCTP implementation's assoc_id. An association is ephemeral and exists only for the lifetime of the underlying transport connection. * "seat" refers to a set of input devices and output mappings associated with a session and bound to a portal. * "surface" refers to a drawable region managed by the compositor and rendered by the workstation's GPU. The following capitalized names identify MWS protocol Object roles. They describe the responsibilities of Message senders and recipients, not a required class hierarchy or implementation language: * "Object" is an independently responsible protocol participant with identity, state, authority, and a defined Message interface. * "Message" is one complete, addressed MWS message passed from one Object to another. Its sender and recipient describe protocol roles, even when the Message remains within one implementation. * "Client" is a graphical application, or its MWS client library, running on the workstation. A Client is distinct from a Portal. * "Application" is the workstation-side Object that represents a Client within the server. It receives Messages from that Client and acts on its behalf within the Client's authenticated Session. * "Window" is a Session-scoped Object representing one top-level graphical window belonging to an Application. Lowercase "window" retains its ordinary graphical meaning. * "Compositor" is the workstation-side Object responsible for the Window tree, focus, policy, routing, and presentation. Lowercase "compositor" denotes the subsystem or the generic compositing role. * "Presenter" is a workstation-side Object that originates presentation Messages for Windows managed by its Compositor. * "Projector" is the Portal-side Object that receives presentation and Window-state Messages and presents them through the Portal's native display system. * "Session" is the workstation-side Object that owns one authenticated user's graphical environment and the Objects and resources within it. * "Transport" is an endpoint Object that carries complete MWS Messages between a Portal and the server. Transport-reserved Messages are exchanged only between peer Transport Objects. These names are taken from the reference implementation because they make the endpoints and direction of each Message explicit. Conforming implementations MAY organise their internal Objects differently, but MUST preserve the specified Message semantics, authority boundaries, addressing, and routing. * "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. Unless otherwise specified, text fields in MWS messages are encoded as length-prefixed UTF-8 strings ("Pascal strings"). A length-prefixed string consists of an unsigned length field (for example, uint8 or uint16, encoded in network byte order) followed immediately by that many bytes of UTF-8 text. No NUL terminator is transmitted on the wire; the length is authoritative. 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, audio processing, session management, and window-management policy reside on a central server. Portal devices act solely as authenticated display, audio, and input endpoints. This model preserves the semantics of a local workstation while enabling secure remote presence across modern networks. MWS assumes portal 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, high-motion content, and low-latency audio can be delivered with minimal delay. Devices with substantially lower bandwidth may operate at reduced quality but are not a primary design target. The architecture reserves a dedicated stream for a future real-time Audio Plane suitable for workstation-class media workloads. This revision does not define its wire format or make latency guarantees. 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. * Portal devices may be untrusted, mobile, or ephemeral. * Users may relocate sessions across devices without restarting applications. * GPU-accelerated workloads remain server-resident. * Real-time audio is a first-class subsystem with strict latency and ordering requirements. * Network transparency is a first-class requirement. * Loss or theft of a portal 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 SCTP associations. These properties are required to ensure deterministic compositor behaviour, responsive input under load, support for high-motion video surfaces, low-latency audio transport, 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, surfaces, focus, input routing, and presentation. * The renderer, which executes GPU-accelerated drawing and performs surface composition on the workstation. * The audio subsystem, which manages audio device and audio stream objects for playback and capture. * The session manager, which maintains Session objects independently of portal connections and supports detachable operation. * The transport layer, which provides a secure, multi-stream, message-oriented channel between workstation and portal. * The input subsystem, which manages Seat and InputDevice objects and forwards input events to the compositor. * The portal device, which decodes surfaces, presents them to the user, plays audio, 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, audio devices, compositor state, and input-routing policy. Applications run exclusively on the workstation, and all rendering and audio processing are performed on workstation-resident hardware. Portal devices own their physical input hardware. Input events are generated on the portal and forwarded to the workstation, which applies focus, routing, and seat semantics. The workstation never interacts with the portal's physical devices directly; it operates only on the logical input events they produce. GPU resources are exposed to MWS exclusively through the Vulkan API. The workstation enumerates all available GPUs using vkEnumeratePhysicalDevices() and creates one compositor instance per physical device. All rendering, composition, and presentation operations are defined in terms of Vulkan objects and capabilities. Audio resources are exposed to MWS through audio devices, each of which represents a physical or virtual playback or capture endpoint. Audio streams are created dynamically to transport PCM audio between the workstation and portal devices. A user may interact with the workstation in two ways: * Local console mode, using the workstation's own keyboard, pointer, display, and audio hardware. * Remote presence mode, using an authenticated portal device elsewhere on the network. Local and remote interaction share the same compositor, window tree, audio devices, 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: * rendering updates, representing Window content prepared for presentation by the Portal * 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. Surface objects represent drawable regions within the compositor. Window objects reference one or more surfaces, and the compositor determines whether a surface is transmitted as rendering updates or as a video stream. The renderer executes Vulkan command streams on the workstation. The Presenter sends the resulting Portal-ready representation, while video surfaces are encoded using hardware acceleration when available. 3.5. Session Model Sessions are server-resident and persist independently of portal connections, but long-term persistence requires explicit detachment. MWS tolerates transient network interruptions; if a portal reconnects within the configured grace period, the session continues without interruption. If a portal 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. Because all application, window, and session state resides on the workstation, failure, loss, or destruction of a portal device does not by itself risk loss of in-progress work; the session remains intact on the server and may be resumed from another device, subject only to the reconnection grace period. 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 over time, and under what conditions, are defined in Section 4.8. Sessions contain seats, each of which aggregates input devices, audio streams, and presentation state for a particular user interaction context. Multiple seats may be active concurrently, enabling multi-user or multi-portal operation. This model enables mobility across devices while preserving the semantics of a traditional workstation and avoiding long-lived orphaned sessions. 3.6. Zero-Trust Portal Model All portal 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 portal 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 terminal on the network was inherently trustworthy. Wayland addressed this by eliminating remote portals entirely. Mercurius instead removes the assumption of trust: portal devices may be anywhere, but trust is derived solely from what the user can cryptographically prove. Server identity is established during the DTLS 1.3 handshake carried over SCTP for each transport association. Deployments SHOULD use DNS-Based Authentication of Named Entities (DANE) [RFC6698][RFC7671] to bind the server's certificate to DNSSEC-protected TLSA records, allowing portals to verify that they are communicating with the correct workstation without relying on public certificate authorities or assumptions about local network topology. User authentication is performed at the application layer using the mechanism-agnostic model defined in Section 5.2.1. The server advertises supported mechanisms (for example, "PAM", "FIDO2"), and the portal selects one. This allows deployments to integrate password-based, hardware-token, federated, or certificate-based user authentication without modifying the protocol. A portal device is assumed to be mobile and at risk of loss or theft. Application files and authoritative Session state remain on the workstation and are not replicated to the Portal. A Portal may, however, hold reusable authentication material such as an encrypted private key, and an active Portal necessarily observes displayed content and user input. A compromised active Portal can therefore compromise the user operating it. The zero-trust boundary is server-side authority. Possession or compromise of one Portal MUST NOT grant authority over another user's Session, reveal resources outside the attached Session, or make Portal-supplied identifiers authoritative. Deployments that require proof of user presence MUST choose an authentication mechanism that provides it; the base protocol does not infer user presence merely from possession of a device or private key. 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 portals are located on the same LAN as the workstation, nor that any network segment provides meaningful security. A portal on a local LAN and a portal 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 portals. * 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 or low-latency audio. The transport layer adapts to available bandwidth through dynamic surface encoding, selective use of video surfaces, adaptive refresh rates, and prioritised input, audio, 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 and real-time audio frames. The transport MUST avoid cross-stream head-of-line blocking. Input events, control messages, rendering updates, audio streams, 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. A server carrying more than one association MUST apply backpressure per association. Readiness of a shared transport endpoint MUST NOT be interpreted as evidence that any particular association can accept more data. A congested or stalled portal MUST NOT block transport progress for other portals. The transport MUST support stable associations that survive transient network changes, including portal mobility across networks. Session attachment, reconnection semantics, and multi-seat operation rely on the ability to maintain a consistent association identity at the transport-level. 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, low-latency audio transport, relocatable sessions, and multi-seat concurrency. MWS protects SCTP user messages with DTLS 1.3 using the DTLS-over- SCTP mapping defined by [I-D.6083BIS]. That work updates the DTLS 1.0 mapping specified by [RFC6083] for DTLS 1.3. Unlike TLS over SCTP [RFC3436], the DTLS mapping preserves message boundaries, unordered delivery, and PR-SCTP. 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, audio devices, input routing, and compositor state, and a set of untrusted portal devices that connect over a secure, message-oriented transport. Once connected, a portal device acts as a portal 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, audio devices, and compositor state. Sessions are server-resident and MAY persist independently of portal connections when explicitly detached. User identity is established during the application-layer authentication phase of the handshake (Section 5.2.1). The authenticated identity (for example, a local username, a portal certificate subject, or a federated identity token) is mapped to a local user account via the system's authentication framework (such as PAM). 4.2. Seats A seat represents a set of input devices, audio streams, and an output binding for a session. A session MAY have multiple seats simultaneously. Each seat corresponds to a particular portal, whether that portal is the local console or a remote portal device acting in the portal role. Input belongs to a Seat, and the compositor routes it according to seat-specific focus and pointer state. The representation of this association is deferred with the input Message format. Output mappings (for example, which windows appear on which displays) and audio routing 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 portal 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 rendering updates 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 (for example, 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 portal and MAY substitute a placeholder or video surface. Each compositor instance is bound to a single GPU or output pipeline. It owns the device-level rendering resources for that GPU (device context, queues, swapchains, and associated GPU buffers), and no other component may submit rendering work directly to that device. 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. Portal devices do not access GPU resources directly. The compositor selects the appropriate representation for each surface: * rendering updates for low-motion or interactive content * video surfaces for high-motion or bandwidth-sensitive content Because rendering is server-resident, a stalled or misbehaving portal cannot block the compositor. The server MAY revoke a window's rendering resources, substitute a placeholder surface, or terminate the portal if rendering deadlines are repeatedly missed. The MWS specification assumes a modern explicit GPU API for rendering and composition (for example, Vulkan [VK14]) and requires that all rendering and presentation operations be performed through the compositor's device-level abstraction. Portal devices are not required to implement any graphics API. 4.6. Audio Model The audio subsystem manages audio devices and audio streams between the workstation and Portal devices. Audio is a first-class architectural subsystem with strict latency and ordering requirements. Its traffic is logically independent of rendering and control traffic while sharing the secure, multi-stream Transport. An audio device represents a physical or virtual playback or capture endpoint on the workstation, such as speakers, headphones, microphones, instrument inputs, multichannel mixers, loopback devices, and virtual sinks. Devices are enumerated and managed on the server; portal devices do not own or configure audio hardware directly. Logical audio streams are created dynamically to carry PCM samples between the workstation and the portal. Each audio stream is bound to a specific audio device and seat, and is direction- specific (playback or capture). Streams are timestamped at the server, and the portal maintains playout buffers that honour these timestamps while minimising latency and jitter. Playback streams carry audio from applications on the workstation to the portal device for presentation. Capture streams carry audio from portal-attached input devices to the workstation, where it is injected into the appropriate session and applications according to policy. The server MAY apply policy to limit or redirect capture streams (for example, to prevent inadvertent capture in shared environments, or to restrict which multichannel devices are exposed to a given session). The Audio Plane uses Stream 4, separate from control, rendering, input, and video. Its Message lifecycle and current payload requirements are specified in Section 5.6. 4.7. Stream Allocation MWS assigns SCTP streams by Message class: * Stream 0: control * Stream 1: rendering * Stream 2: input * Stream 3: video * Stream 4: audio These assignments are fixed. A Window is identified by Message addressing and is not assigned an SCTP stream. Multiple Windows may therefore use the same rendering or video stream without changing their identity, ownership, or routing. Streams 5-15 are reserved for future standard assignments. Streams 16 and above MAY be used by experimental or vendor-specific extensions as described in Appendix C.6. 4.7.1. Session Identity and Message Routing Each transport association is attached to at most one portal session at any point in time. A session MAY be attached to different transport associations over its lifetime (for example, after detachment and resume), but a given transport association MUST NOT carry traffic for more than one session concurrently. The server MUST treat the transport association (for example, an SCTP association as defined in RFC 9260) as the authoritative source of session context for message routing. No portal-supplied field may select, reference, or override the session to which a message is delivered. A session is created or selected only after successful user authentication and the explicit Session selection defined in Section 5. Until Session establishment 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 currently attached to the transport 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 attached session MUST be rejected with MWS_ERROR_SESSION (type=702, fatal=0). Messages that include a session identifier inconsistent with the session implied by the transport association MUST be ignored. If a message is received on a transport association that has no active handshake, no attached session, or whose session has been closed, the server MUST silently discard the message. 4.8. 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 portal completes Session establishment as defined in Section 5 and remains ACTIVE until it is detached, abandoned, explicitly terminated, or reclaimed by policy. After authentication, a Portal MUST explicitly request either a new Session or resumption of a Session offered by the server. The server MUST NOT create or reattach a Session solely on the basis of matching user identity. A portal MAY explicitly detach from an ACTIVE session. Detach transitions the session from ACTIVE to DETACHED. In the DETACHED state, its client applications are suspended and it has no attached transport association. Its windows, compositor state, audio stream state, and GPU resources remain server-resident. DETACHED sessions MAY be resumed by any authenticated portal device belonging to the same user, subject to server policy. Loss of the transport association (for example, network outage, SCTP association failure, timeout, or portal 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 portal. If a portal 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 (for example, idle timeout, logout event, or administrative limits). Only one transport association (portal 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.9. Session and Seat Model Sessions MAY persist independently of portal connections. When a portal device disconnects (for example, when its transport association is lost), 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. Attaches the authenticated association to the Session. 2. Sends the current Window list, geometry, visibility, and stacking order as defined in Section 5.2.2. 3. Allows later subsystem specifications to negotiate new Seat, focus, output, input, and audio state for the Portal. MWS supports both independent sessions and multi-seat attachment within a single session. A user may maintain multiple concurrent sessions (for example, two independent desktop environments), or may attach multiple seats to the same session via a single transport association, subject to the single-association model defined in Section 4.8. MWS also supports explicit session detachment. A user may detach a running session, suspending its client applications while leaving its windows, compositor state, audio stream state, and GPU resources resident on the server without any attached seats. The user may then initiate a new session on the same portal device (for example, 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.10. Local Transport Profile (Non-Normative) Although MWS treats all portal devices as untrusted endpoints and applies the same protocol semantics regardless of network location, implementations MAY apply transport-layer optimisations when the portal 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 portal. 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 portals * bypass certificate validation or user authentication * modify the behaviour of control, input, audio, or rendering streams * introduce protocol features unavailable to remote portals MWS remains a transport-agnostic, network-transparent window system. Local optimisations exist solely to ensure that portal 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.11. Security Model All portals 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: * at any point in time, a session is attached to at most one transport association in the base protocol, and the server uses the association on which a message is received as the authoritative source of session context; portals cannot select or override the session by supplying identifiers * 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 * portals cannot observe, enumerate, or reference resources belonging to other sessions * all portal-originated messages are validated before being processed Transport security is provided by DTLS 1.3 carried over SCTP using the mapping defined by [I-D.6083BIS]. SCTP-AUTH [RFC4895] protects the selected SCTP control chunks required by that mapping; it does not encrypt MWS Messages. DTLS provides confidentiality and integrity for MWS Messages. Deployments SHOULD use DNS-Based Authentication of Named Entities (DANE) to bind the server's certificate to DNSSEC-protected TLSA records, allowing portals to verify that they are communicating with the correct workstation even in the presence of compromised or mis-issued CA certificates. Device identity is not part of the trust model; access to user sessions is determined solely by user authentication and server policy. The DTLS profile is part of the base protocol. An external secure tunnel MAY provide defence in depth but does not replace DTLS or relax any MWS authentication requirement. Deployments MAY additionally require portal authentication at the transport layer (for example, mutual DTLS), but such device identity is always subordinate to user-level authorisation. User authentication is performed at the application layer using the mechanism-agnostic model defined in Section 5.2.1. The server advertises supported mechanisms (for example, "PAM" and "FIDO2"), and the portal selects one. This separation of device and user identity ensures that device identity alone does not grant access to a user's Session. The server validates all portal-originated messages, including input events and other Portal-originated messages. A portal may not reference windows, sessions, or resources outside its authenticated session. Attempts to do so are rejected with MWS_ERROR_SESSION (type=702, fatal=0). Malformed or semantically invalid messages are ignored, and the session continues unless the error is marked fatal. The server does not trust the Portal as an authority over Session state. The user nevertheless entrusts an active Portal with the content it displays, the input it captures, and any authentication material used there. If a portal 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.8 and MAY be resumed from another portal subject to policy. 5. Protocol Specification 5.1. Message Framing All MWS messages consist of a fixed-size header followed by an optional payload. The header declares the exact payload length; a message is therefore self-delimiting. The header format is: struct MwsHeader { uint32_t magic; uint16_t type; uint16_t reserved; uint32_t length; }; magic MUST contain 0x4d657263, the ASCII octets "Merc". type is the opcode registered in Appendix A. reserved MUST be zero. length is the payload length in octets and does not include the header. The 32-bit length field can represent payload lengths from zero to 4294967295 octets. This is the framing limit, not a requirement that an endpoint accept a payload of every representable size. During Session establishment, each endpoint declares the largest logical payload it has resources to accept. A sender MUST NOT send a logical Message whose declared payload length exceeds the peer's limit. A receiver MUST validate the header against that limit before allocating storage or processing the payload. Exceeding the advertised limit is a resource error, not malformed framing. Implementations MAY choose different receive limits according to available memory and local policy. The payload immediately follows the header. Implementations MUST validate the magic value, type, and declared payload length before processing the completed message. Messages with invalid headers MUST be rejected with MWS_ERROR_PROTOCOL (type=701). 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. Unless otherwise specified, text fields in MWS messages are encoded as length-prefixed UTF-8 strings ("Pascal strings"). A length-prefixed string consists of an unsigned length field (for example, uint8 or uint16, encoded in network byte order) followed immediately by exactly that many bytes of UTF-8 text. No NUL terminator is transmitted on the wire; the length is authoritative, and implementations MUST NOT assume any terminating byte beyond the declared length. When a complete Portal-association MWS Message, including its 12-octet header, fits within the peer's max_user_message_size, it is carried unchanged as one SCTP user message. Section 5.1.1 defines Transport fragmentation for a larger logical Message. MWS opcodes form a common Message vocabulary between Mercurius Objects. Not every MWS Message crosses the Portal association. A "Portal-association" Message crosses that authenticated association. A "client-channel" Message crosses the workstation-local boundary between a client library and its server-side Application. An "in-process" Message passes between server Objects. A Message MUST NOT cross a boundary for which its definition does not permit it. A Message may retain its opcode and payload while moving from one scope to another. For example, a client-channel request received by an Application may continue in-process to its Session. Some events are deliberately delivered in more than one scope so that each recipient sees the Message appropriate to its responsibility. These classifications describe semantic senders and recipients. An Object may hand a Message to its parent for delivery without knowing the Transport, association, Session, or concrete recipient involved. This does not change which Object originated the Message or which Object is entitled to consume it. 5.1.1. Transport Fragmentation Fragmentation is a Transport concern. The Object sending an ordinary MWS Message and the Object receiving it operate only on the complete logical Message. They do not inspect, originate, receive, or handle the Transport Messages defined in this section. If an ordinary complete MWS Message fits within the peer's declared max_user_message_size, the Transport MUST send it unchanged. If it does not fit, the Transport MUST send one MWS_MESSAGE_START. It MUST then send as many MWS_MESSAGE_APPEND Messages as are required to complete the logical Message, or send MWS_MESSAGE_ABANDON. Every outer Message, including its 12-octet outer header, MUST fit within the peer's max_user_message_size. MWS_MESSAGE_START (type=800) -- Transport -> Transport The payload consists of the original 12-octet MWS header, copied unchanged in network byte order, followed by zero or more initial octets of the original payload. The outer payload length MUST be at least 12. The retained original header MUST be valid, MUST declare a payload no larger than the receiver's max_payload_size, and MUST NOT contain type 800, 801, or 802. MWS_MESSAGE_APPEND (type=801) -- Transport -> Transport The payload consists of one or more consecutive octets of the original payload. An empty MWS_MESSAGE_APPEND is a protocol error. MWS_MESSAGE_ABANDON (type=802) -- Transport -> Transport Abandons the active fragmented logical Message on the same association and SCTP stream. Its payload MUST be empty. The receiver MUST maintain at most one active fragmented logical Message for each association and SCTP stream pair. It validates and retains the original raw header from MWS_MESSAGE_START, then appends payload octets from successive MWS_MESSAGE_APPEND Messages on that association and stream. It MUST deliver exactly one reconstructed ordinary Message only after accumulating the payload length declared in the retained original header. While a fragmented Message is active on an association and stream: * MWS_MESSAGE_APPEND is valid only for that active Message. * MWS_MESSAGE_ABANDON discards the active Message and all of its accumulated payload without delivering or acting upon it. * A second MWS_MESSAGE_START on the same association and stream is a protocol error. * An ordinary MWS Message on the same association and stream is a protocol error. * Accumulating more payload octets than the retained original header declares is a protocol error. MWS_MESSAGE_START, MWS_MESSAGE_APPEND, and MWS_MESSAGE_ABANDON MUST use reliable, ordered delivery. A fragmented sequence MUST NOT use partial reliability or unordered delivery. Once a sender has emitted MWS_MESSAGE_START, it MUST complete or abandon that logical Message before sending another Message on the same association and stream. MWS_MESSAGE_ABANDON without an active fragmented Message is a protocol error. After an active Message has been abandoned, the next ordinary Message or MWS_MESSAGE_START on that stream is valid. Loss of an association discards every incomplete fragmented Message for that association. An incomplete Message MUST NOT be delivered or acted upon. A malformed sequence is a fatal protocol error and the receiver MUST terminate the association after sending MWS_ERROR_PROTOCOL when it is possible to do so safely. A receiver MUST apply its declared payload and buffering limits before allocating reassembly storage. Reassembly state and queued fragment data MUST be bounded independently for each association so that one peer cannot consume resources belonging to another. Fragmentation is available only after the two-way MWS_SESSION_INFO exchange. Handshake Messages MUST fit in one SCTP user message. An endpoint's max_user_message_size MUST be at least 24 octets, allowing an outer header and the original header in MWS_MESSAGE_START. 5.2. Control Messages (Stream 0) Control messages manage authentication, session establishment, window lifecycle, and compositor state. All Portal-association 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, audio, and video streams operate independently and are not blocked by control-plane latency. 5.2.1. Initial Handshake (001-099) The initial handshake establishes user identity and Session parameters. DTLS 1.3 [RFC9147] over SCTP using [I-D.6083BIS], optionally validated using DANE (Section 9.1), authenticates the server and protects the transport. The application-layer handshake authenticates the user and establishes a session. The handshake and the resulting Session have different security obligations: 1. The handshake must be cheap and fail fast so that an unauthenticated peer cannot consume disproportionate server resources. 2. The Session must remain secure against a capable, persistent attacker after authentication has succeeded. MWS_QUERY is deliberately an empty Message under the first of these rules. Receiving it MUST NOT cause the server to parse peer-supplied negotiation data or allocate Session resources. Authentication failures, malformed handshake Messages, and unsupported mechanisms MUST be rejected without creating a Session. User authentication is mechanism-agnostic. The server advertises one or more supported authentication mechanisms, and the portal 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) -- Portal -> Server Requests the server's authentication challenge. MWS_QUERY has no payload. A non-zero payload length is a protocol error. 2. MWS_AUTH_CHALLENGE (type=002) -- Server -> Portal Advertises the available authentication mechanisms. The payload contains a list of mechanism identifiers. Payload 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 and MUST be greater than zero. mechanism_count MAY be zero, in which case the portal MUST abort the handshake. 3. MWS_AUTH_RESPONSE (type=003) -- Portal -> Server Selects an authentication mechanism and provides mechanism-specific credentials. Payload format: uint8_t mech_name_len; char mechanism[mech_name_len]; uint16_t credential_len; uint8_t credential[credential_len]; mechanism MUST exactly match one of the names advertised in MWS_AUTH_CHALLENGE. If the mechanism is unknown or the payload length is inconsistent, the server MUST respond with MWS_ERROR_PROTOCOL (type=701, fatal=1). A mechanism that proves possession of a reusable credential MUST bind that proof to the current DTLS association. Such a proof MUST NOT consist only of data supplied by the Portal or of the reusable MWS_AUTH_CHALLENGE payload. The SSHKEY mechanism uses the tls-exporter channel binding defined by [RFC9266], as specified in Appendix B.1. 4. MWS_SESSION_RESUME_OFFER (type=100) -- Server -> Portal Confirms successful authentication and lists the authenticated user's resumable Sessions. The server sends this Message even when the list is empty. Its payload is defined in Section 5.2.2. 5. Session selection -- Portal -> Server The Portal sends exactly one of MWS_SESSION_NEW_REQUEST (type=104) or MWS_SESSION_RESUME_REQUEST (type=101). The server MUST NOT create or attach a Session before receiving this explicit selection. 6. MWS_SESSION_INFO (type=004) -- Server -> Portal Confirms the selected Session identifier and declares the server's receive limits for this Session. Payload format: uint32_t session_id; uint32_t max_payload_size; uint32_t max_user_message_size; All three fields are in network byte order. session_id is assigned by the server and MUST be non-zero. max_payload_size is the largest payload of a complete logical MWS Message the server will accept. It MUST be non-zero and MUST NOT exceed 4294967295. max_user_message_size includes the complete outer MWS header and payload carried in one SCTP user message. It MUST be at least 24 octets, sufficient for an outer Transport header and the retained original header in MWS_MESSAGE_START. 7. MWS_SESSION_INFO (type=004) -- Portal -> Server Echoes the server-assigned Session identifier and declares the logical payload and complete SCTP user-message limits the portal will accept for this Session. The payload has the same format as the server's MWS_SESSION_INFO. An endpoint MUST NOT send a logical payload larger than the peer's declared max_payload_size or a complete outer MWS Message larger than the peer's declared max_user_message_size. The advertised value MUST also conform to the DTLS-over-SCTP profile defined by [I-D.6083BIS]. A max_user_message_size smaller than 24 is a protocol error and terminates Session establishment. In the absence of a negotiated DTLS extension increasing the plaintext record limit, max_user_message_size MUST NOT exceed 2^14 octets. Transport fragmentation therefore permits a logical MWS payload to remain larger than one DTLS record without changing the ordinary Message seen by its sender or recipient. Presentation, audio, input, and other subsystem capabilities are negotiated by their respective protocol messages after this base session exchange. They are not implicit, implementation-defined fields of MWS_SESSION_INFO. For a new Session, establishment completes after the server has received and accepted the Portal's MWS_SESSION_INFO. For a resumed Session, the server then sends MWS_SESSION_RESUME_COMPLETE as defined in Section 5.2.2; establishment completes when that Message is sent. Only then is the Portal attached and the Session ready for MWS_EXEC_REQUEST and ordinary Session traffic. Before then, either endpoint MUST reject non-handshake traffic except for the resume reconstruction Messages defined in Section 5.2.2. 5.2.1.1. Session Identifier Semantics The session identifier returned in MWS_SESSION_INFO is assigned solely by the server. Portals MUST treat this value as opaque and MUST NOT attempt to select, predict, or construct session identifiers. All portal-originated messages that include a session_id field are advisory; the server MUST validate the session_id against the session associated with the transport association (for example, an SCTP association) on which the message was received, as defined in Section 4.7.1. A portal MUST NOT assume that a session identifier remains valid across reconnects unless the server has explicitly offered the session for resumption. An identifier assigned to a live, detached, or grace-period Session MUST NOT be reused. A server that reuses an identifier after its former Session has terminated MUST ensure that no association, resume offer, or retained protocol state can still refer to the former Session. Possession of a session identifier alone never conveys authority. MWS_SESSION_INFO does not carry a resume token. Resumable Sessions are advertised explicitly with MWS_SESSION_RESUME_OFFER after fresh authentication. 5.2.2. Session Management (100-199) Session resume allows a portal to reattach to an existing session previously detached by the user or preserved during the reconnection grace period. MWS_SESSION_RESUME_OFFER (type=100) -- Server -> Portal Completes user authentication and lists the Sessions that the authenticated user may resume. Payload format: uint16_t session_count; repeated session_count times: uint32_t session_id; All fields are in network byte order. session_count MAY be zero. Every listed session_id MUST be non-zero and MUST appear at most once. An offer authorises a resumption request only on the association on which it was sent and only until Session establishment ends. MWS_SESSION_RESUME_REQUEST (type=101) -- Portal -> Server Requests resumption of one Session from the preceding offer. Payload format: uint32_t session_id; session_id is in network byte order and MUST identify a Session in the preceding offer. MWS_SESSION_RESUME_COMPLETE (type=102) -- Server -> Portal Confirms that Session resumption and state reconstruction are complete. This Message has no payload. A non-zero payload length is a protocol error. MWS_SESSION_DETACH (type=103) -- Portal -> Server Requests deliberate detachment of the current Session. This Message has no payload; the Session is identified by the MWS header and the authenticated association on which the Message arrives. A non-zero payload length is a protocol error. On accepting the request, the server MUST suspend the Session's client applications, preserve the Session for later resumption subject to local policy, and detach the Portal. The detached association MUST NOT retain authority to send Session traffic. MWS_SESSION_DETACH does not terminate the Session. MWS_SESSION_NEW_REQUEST (type=104) -- Portal -> Server Requests creation of a new Session for the authenticated user. This Message has no payload. A non-zero payload length is a protocol error. MWS_SESSION_STATE_BEGIN (type=105) -- Compositor -> Projector (Portal association) Begins reconstruction of a resumed Session. The Projector MUST discard any presentation state retained for the Session before accepting the following MWS_WINDOW_STATE Messages. Payload format: uint32_t window_count; window_count is in network byte order and declares the exact number of MWS_WINDOW_STATE Messages that follow. This Message and those Window state Messages MUST be sent consecutively on Stream 0 before MWS_SESSION_RESUME_COMPLETE. window_count MAY be zero. The payload length MUST be exactly four octets. Server-side application launch allows a portal to request that the compositor start a program under the authenticated session. MWS_EXEC_REQUEST (type=110) -- Portal -> Server Requests execution of a program under the current Session. Payload format: uint8_t name_len; char name[name_len]; name is a UTF-8 program name without a terminating NUL. name_len MUST be non-zero, and the payload length MUST equal one plus name_len. Argument passing and environment changes are not defined by this version. The server resolves and launches the named program according to local policy. MWS_EXEC_RESULT (type=111) -- Server -> Portal Reports that the program requested by MWS_EXEC_REQUEST has terminated. Payload format: uint32_t status; status is in network byte order. Zero reports successful termination; a non-zero value reports unsuccessful termination. This version does not expose a process identifier or diagnostic text. A payload length other than four is a protocol error. 5.2.2.1. Resume Semantics A session becomes resumable when the user has explicitly detached it or when the transport association (for example, an SCTP association) has been lost and the session has entered the reconnection grace period defined in Section 4.8. The server MUST NOT offer resumption for sessions that have been terminated or reclaimed by policy. After successful user authentication, the server MUST send exactly one MWS_SESSION_RESUME_OFFER (type=100). An empty offer tells the Portal that no resumable Session is available while preserving the same state-machine ordering in both cases. The Portal MUST answer with exactly one MWS_SESSION_NEW_REQUEST or MWS_SESSION_RESUME_REQUEST. On MWS_SESSION_NEW_REQUEST, the server creates a pending Session and begins the two-way MWS_SESSION_INFO exchange defined in Section 5.2.1. The new Session becomes ACTIVE only when that exchange completes. To resume a session, the portal 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 portal, unless local policy permits forced detachment If validation succeeds, the server reserves the Session for this association and begins the two-way MWS_SESSION_INFO exchange defined in Section 5.2.1. After accepting the Portal's MWS_SESSION_INFO, the server MUST provisionally bind the association to the Session, cancel any active reconnection grace timer, and reconstruct the Projector's presentation state. This provisional binding authorises only the reconstruction sequence. The Compositor sends MWS_SESSION_STATE_BEGIN followed by exactly the declared number of MWS_WINDOW_STATE Messages in bottom-to-top stacking order. The server then sends MWS_SESSION_RESUME_COMPLETE (type=102), attaches the Portal, and transitions the Session to ACTIVE. MWS_SESSION_RESUME_COMPLETE is the ordered boundary after the state sequence and does not duplicate its payloads. Focus, Seat, input device, and output mapping state is outside the reconstruction defined by this version. Later input and output specifications MUST define how that state is renegotiated when a Session resumes on a potentially different Portal. The Projector MUST reject a reconstruction containing the wrong number of Window state Messages, a duplicate or zero window_id, an invalid payload, or any intervening Message on Stream 0. It MUST NOT expose partially reconstructed state. Such a malformed sequence is a fatal protocol error. If validation fails, the server MUST reject the request with MWS_ERROR_SESSION (type=702, fatal=0), MUST NOT alter the requested Session, and MUST NOT reveal the existence or attributes of Sessions belonging to other users. The Portal remains in Session selection state and MAY request a new Session or another Session from the same offer. Only one portal 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 portal, according to local policy. 5.2.3. Window Lifecycle (200-299) Window creation, destruction, mapping, and configuration are managed through the following Messages. A user action at a Portal does not make the Portal the owner of the resulting Window operation. Input is delivered to the workstation; the client Application or window-management policy then originates any required request. MWS_CREATE_WINDOW (type=200) -- Client -> Application (client channel) -- Application -> Session (in-process) Requests creation of a new top-level Window for the Application within its Session. This Message is not sent on the Portal association. Payload format: uint32_t request_id; uint32_t width; uint32_t height; uint8_t title_len; uint8_t title[title_len]; request_id is a non-zero value selected by the client to identify this request; it is not a window_id. width and height are in pixels and MUST be non-zero. title is UTF-8 and is not NUL- terminated. The payload length MUST equal 13 + title_len. MWS_WINDOW_CREATED (type=201) -- Session -> Application (in-process) -- Application -> Client (client channel) -- Session -> Projector (Portal association) Confirms Window creation and supplies its window_id and initial geometry. The response retains the identifying data from the original request so the Application can match concurrent requests; the Projector uses it to create the corresponding presentation surface. Payload format: uint32_t window_id; uint32_t request_id; uint32_t width; uint32_t height; uint8_t title_len; uint8_t title[title_len]; window_id is assigned by the Session and MUST be non-zero. request_id, width, height, title_len, and title MUST be copied unchanged from the corresponding MWS_CREATE_WINDOW. The payload length MUST equal 17 + title_len. MWS_DESTROY_WINDOW (type=202) -- Application -> Session (in-process) -- Client -> Application (client channel) Requests destruction of a Window owned by the Application's Session. This Message is not sent on the Portal association. Payload format: uint32_t window_id; MWS_WINDOW_DESTROYED (type=203) -- Session -> Application (in-process) -- Application -> Client (client channel) -- Server <-> Projector (Portal association) Reports that a Window has been destroyed. When destruction originates at the workstation, the Projector is notified over the Portal association. When the native Portal UI closes the presentation surface, the Projector reports that event and the owning Application and client are notified through their respective scopes. Payload format: uint32_t window_id; MWS_MAP_WINDOW (type=204) -- Application -> Session (in-process) -- Client -> Application (client channel) and Server -> Projector (Portal association) Requests that a Window become visible. After accepting the client request, the server sends the Message to the Projector. Payload format: uint32_t window_id; MWS_UNMAP_WINDOW (type=205) -- Application -> Session (in-process) -- Client -> Application (client channel) and Server -> Projector (Portal association) Requests that a Window become hidden. After accepting the client request, the server sends the Message to the Projector. Payload format: uint32_t window_id; MWS_CONFIGURE_WINDOW (type=206) -- Projector -> Server (Portal association) -- Session -> Application (in-process) -- Application -> Client (client channel) Reports geometry or state changes made by the Portal's native window system. The Session delivers the Message to the owning Application. Payload format: uint32_t window_id; int32_t x; int32_t y; uint32_t width; uint32_t height; width and height are in pixels and MUST be non-zero. The payload length MUST be exactly 20 octets. MWS_FOCUS_WINDOW (type=207) -- Projector -> Server (Portal association) -- Session -> Application and Compositor (in-process) -- Application -> Client (client channel) Reports that a Window has gained focus. The Application is notified on behalf of its external client, while the Compositor updates workstation focus state. Payload format: uint32_t window_id; MWS_SWAPCHAIN_REVOKED (type=208) -- Window -> Application (in-process) -- Application -> Client (client channel) Indicates that a Window's swapchain has been revoked due to policy, timeout, or resource constraints. The client must recreate its presentation resources and redraw the Window. Payload format: uint32_t window_id; MWS_WINDOW_STATE (type=209) -- Compositor -> Projector (Portal association) Reconstructs one Window while resuming a Session. The Compositor sends one MWS_WINDOW_STATE for every live Window, in bottom-to-top stacking order. Payload format: uint32_t window_id; int32_t x; int32_t y; uint32_t width; uint32_t height; uint32_t flags; uint8_t title_len; uint8_t title[title_len]; Bit 0 of flags is MAPPED and reports whether the Window is visible. All other flag bits MUST be zero. width and height MUST be non-zero. title is UTF-8 without a terminating NUL. The payload length MUST equal 25 plus title_len. Every multi-octet field above is in network byte order. Except for MWS_CREATE_WINDOW, every Window lifecycle payload begins with a non-zero window_id. A recipient MUST reject an incorrect payload length, a zero identifier, invalid UTF-8, or a Window outside the permitted Session scope. 5.2.3.1. Window Identifier Scope Window identifiers are scoped to the Session that created them. A Portal MUST NOT reference, manipulate, or query Windows belonging to any other Session. For every wire Window Message received from a Portal association, the server MUST validate that the window_id belongs to the Session associated with that SCTP association. If a portal attempts to reference a window outside its session, the server MUST reject the message with MWS_ERROR_SESSION (type=702, fatal=0). The server MUST NOT reveal the existence, geometry, focus state, or any other attributes of windows belonging to other sessions. A window_id MUST be unique among live Windows in its Session. The same numeric value MAY occur in another Session because the Session context is part of the Message address. The server MUST never resolve a window_id outside the Session selected by the authenticated association, regardless of numeric equality. These rules ensure that windows are private to the session that owns them and that portals cannot observe or interfere with the graphical state of other users. 5.3. Rendering Messages (300-399) Portal-association rendering Messages are delivered on SCTP stream 1. Client-channel rendering Messages enter through the Application and continue in-process to their intended workstation Objects. Each is validated by its recipient against the Window and resources belonging to the addressed Session. MWS_RENDER_PRESENT (type=300) -- Presenter -> Projector (Portal association) Presents a rendering update to the Projector. The Presenter sends portal-ready rendering data for the addressed Window. Payload format: uint32_t window_id; int32_t x; int32_t y; uint32_t width; uint32_t height; uint32_t buffer_size; uint8_t pixels[buffer_size]; window_id, width, and height MUST be non-zero. x and y are the Window position in compositor coordinates. buffer_size MAY be zero, in which case the Message changes no pixel content. A non-zero pixel buffer is tightly packed BGRA8888 in VK_FORMAT_B8G8R8A8_UNORM byte order. Each row contains exactly width * 4 octets and buffer_size MUST equal width * height * 4. The payload length MUST equal 24 + buffer_size. A sender whose source image has a larger row stride MUST repack it before constructing this Message. MWS_RENDER_SYNC (type=301) -- Presenter -> Projector (Portal association) Requests synchronisation of rendering state on the portal. The server uses this command to ensure that the portal has reached a defined rendering point before subsequent presentation or resource changes. Payload format: uint32_t window_id; MWS_RENDER_DESTROY (type=302) -- Presenter -> Projector (Portal association) Requests destruction of rendering resources associated with a window or pipeline on the portal. The portal releases any corresponding portal-side rendering state when it is safe to do so. Payload format: uint32_t window_id; MWS_RENDER_UPLOAD (type=303) -- Client -> Application (client channel) -- Application -> Window (in-process) Provides new rendering content for a window's surface. The Mercurius client library sends a bounded update to the Window's image data or GPU-resident resources. This Message does not cross the Portal association. Payload format: uint32_t window_id; uint32_t width; uint32_t height; uint32_t stride; uint32_t buffer_size; uint8_t pixels[buffer_size]; Pixels are BGRA8888 in VK_FORMAT_B8G8R8A8_UNORM byte order. window_id, width, height, stride, and buffer_size MUST be non-zero. stride MUST be at least width * 4. buffer_size MUST equal stride * height, and the payload length MUST equal 20 + buffer_size. Arithmetic validation MUST detect overflow. MWS_RENDER_DAMAGE (type=304) -- Client -> Application (client channel) -- Application -> Window (in-process) Reserved for reporting changed regions of a Window. Its payload and semantics are not defined by this version. A sender MUST NOT emit this Message until a later specification defines it. MWS_RENDER_FENCE (type=305) -- Client <-> Application (client channel) -- Application <-> Window (in-process) Reserved for synchronising rendering progress. Its payload and semantics are not defined by this version. A sender MUST NOT emit this Message until a later specification defines it. Every multi-octet field above is in network byte order. Every defined rendering payload begins with a non-zero window_id. A recipient MUST reject an incorrect payload length, inconsistent geometry or buffer size, arithmetic overflow, or a Window outside the permitted Session. 5.4. Input Plane (400-499) -- Stream 2 SCTP Stream 2 is reserved for Portal-to-workstation input. Input Messages will eventually describe keyboard, pointer, tablet, touch, and other seat-scoped events without coupling the protocol to a particular Portal window system. MWS_INPUT_EVENT (type=400) -- Portal -> Server Delivers an input event from an authorised Seat. MWS_INPUT_ACK (type=401) -- Server -> Portal Acknowledges an input event when its event class requires an explicit acknowledgement. The exact payload encoding remains under development. The following requirements define the semantics that encoding MUST preserve. A sender MUST NOT emit MWS_INPUT_EVENT or MWS_INPUT_ACK until a later specification defines their payload encodings. Any later definition MUST bind every input event to the authenticated Session and an authorised Seat, and where applicable to a Window owned by that Session. A Portal-provided identifier alone MUST NOT confer authority to inject input. A later Input Plane definition MUST satisfy the following requirements: * It MUST describe input devices, their capabilities, identity, attachment to a Seat, hot-plug, and removal without coupling MWS to a particular Portal operating system or input API. * The workstation MUST remain authoritative for focus, routing, grabs, policy, and the interpretation of which Application and Window may receive an event. * Key transitions, button transitions, and other state-changing events MUST be delivered reliably and in order. They MUST NOT be discarded, coalesced, or reordered across one another. * Superseded pointer or tablet motion MAY be coalesced only when doing so cannot cross or alter the meaning of an intervening state-changing event. Both relative and absolute motion MUST be representable. * Events MUST carry sufficient sequencing and timing information to preserve their intended order and identify stale or invalid device state. Event batching MUST NOT change event semantics. * Physical key events MUST remain distinguishable from text entry and input-method composition. The protocol MUST NOT assume that a keyboard layout or input method is shared by both endpoints. * Device loss or Portal disconnection MUST resolve held keys, buttons, touches, and similar state without leaving input stuck in the workstation Session. * The vocabulary MUST be extensible to touch, tablet pressure and tilt, accessibility devices, and control surfaces without weakening the Session and Seat authority rules. * Where a device requires feedback, such as keyboard indicator or haptic state, the workstation-to-Portal direction MUST be represented explicitly and subject to the same Seat scoping. 5.4.1. Pointer Motion Events Pointer motion includes both an absolute position and relative movement. x and y are unsigned 32-bit surface-local pixel coordinates. delta_x and delta_y are signed 16-bit changes since the preceding pointer event. A zero delta reports no relative movement. A mouse_move event reports motion with no buttons held. A mouse_drag event has the same coordinates and additionally carries a bit mask of buttons currently held. Both forms remain subject to the authority, ordering, and coalescing requirements above. A later definition MUST specify reliability, ordering, acknowledgement, retransmission, and coalescing separately for each event class. It MUST NOT apply one delivery policy indiscriminately to all input traffic merely because that traffic shares Stream 2. 5.5. Video Fallback (500-599) -- Stream 3 Video fallback is intended for a Window whose presentation is more appropriately represented as encoded video than as ordinary rendering updates. Stream 3 is reserved for that traffic so that loss or congestion does not block control or rendering Messages. MWS_AV1_FRAME (type=500) -- Server -> Portal Delivers an AV1-encoded video frame for presentation in a Window. MWS_PLACEHOLDER_FRAME (type=501) -- Server -> Portal Delivers a placeholder when current Window content is unavailable. The exact payload encodings remain under development. They MUST specify Window and frame identity, dimensions, timestamps, AV1 configuration and random-access state, fragmentation, and the effect of loss or expiration on decoder state. It MUST define partial-reliability and ordering semantics that permit obsolete frames to be discarded without corrupting subsequent presentation. A sender MUST NOT emit either Video Plane Message until a later specification defines its payload encoding. 5.6. Audio Plane (600-699) -- Stream 4 The Audio Plane is intended to provide full-duplex, timestamped audio between workstation and Portal. Playback carries audio from the workstation to the Portal; capture carries audio from a Portal-attached device to the workstation. Stream 4 is reserved so that audio does not share control, rendering, input, or video traffic. Each logical audio stream has a 32-bit stream_id assigned by the endpoint that opens it. A Session MAY have zero or more playback and capture streams. An opener proposes the stream parameters; the peer accepts or rejects them before any data is sent. MWS_AUDIO_PLAYBACK_OPEN (type=600) -- Server -> Portal Proposes a playback stream and its parameters. MWS_AUDIO_PLAYBACK_ACCEPT (type=601) -- Portal -> Server Accepts the proposed playback stream. MWS_AUDIO_PLAYBACK_REJECT (type=602) -- Portal -> Server Rejects the proposed playback stream. The server MUST NOT send playback data for the rejected stream_id. MWS_AUDIO_PLAYBACK_DATA (type=603) -- Server -> Portal Carries timestamped audio for an accepted playback stream. MWS_AUDIO_PLAYBACK_CLOSE (type=604) -- Server -> Portal Ends a playback stream and permits its resources to be reclaimed. MWS_AUDIO_CAPTURE_OPEN (type=620) -- Portal -> Server Proposes a capture stream and its parameters. MWS_AUDIO_CAPTURE_ACCEPT (type=621) -- Server -> Portal Accepts the proposed capture stream. MWS_AUDIO_CAPTURE_REJECT (type=622) -- Server -> Portal Rejects the proposed capture stream. The Portal MUST NOT send capture data for the rejected stream_id. MWS_AUDIO_CAPTURE_DATA (type=623) -- Portal -> Server Carries timestamped audio for an accepted capture stream. MWS_AUDIO_CAPTURE_CLOSE (type=624) -- Portal -> Server Ends a capture stream and permits its resources to be reclaimed. The exact payload encodings remain under development. They MUST specify sample rate, channel count and layout, sample representation and byte order, frame boundaries, timestamp timebase, clock-domain and drift handling, buffering, latency, flow control, ordering, loss, and device-removal semantics. It MUST support signed 16-bit PCM, signed 24-bit PCM, and 32-bit IEEE 754 floating-point PCM. Packed and padded 24-bit representations MUST have distinct wire identifiers; no payload may depend on a C type or host representation. A sender MUST NOT emit any Audio Plane Message until a later specification defines its payload encoding. 5.7. Protocol State Machine 5.7.1. Initial Connection portal server streams ====== ====== ======= MWS_QUERY -------------------------------------> Stream 0 MWS_AUTH_CHALLENGE <------- MWS_AUTH_RESPONSE -----------------------------> Stream 0 MWS_SESSION_RESUME_OFFER <-- MWS_SESSION_NEW_REQUEST ------------------------> Stream 0 MWS_SESSION_INFO <--------- (session_id and server receive limits) MWS_SESSION_INFO ------------------------------> Stream 0 (session_id and portal receive limits) [Session ready] 5.7.2. Session Resume portal server ====== ====== (DTLS/SCTP handshake) MWS_QUERY -------------------> <------------------ MWS_AUTH_CHALLENGE MWS_AUTH_RESPONSE -----------> <------------------ MWS_SESSION_RESUME_OFFER MWS_SESSION_RESUME_REQUEST --> <------------------ MWS_SESSION_INFO MWS_SESSION_INFO ------------> <------------------ MWS_SESSION_STATE_BEGIN <------------------ MWS_WINDOW_STATE (repeated) <------------------ MWS_SESSION_RESUME_COMPLETE 5.8. WSI Extension (Surface Creation) MWS defines a Vulkan WSI extension for creating Vulkan presentation surfaces associated with Mercurius windows. The extension is intended to be usable by ordinary Vulkan applications and helper frameworks executing on the workstation without exposing Mercurius transport, session, or compositor implementation details in the application- facing ABI. An MWS surface is created for a window that has previously been created through the Mercurius runtime executing on the workstation. Applications do not directly specify SCTP stream identifiers, associations, sessions, or compositor-side window identifiers. Instead, the runtime exposes an opaque window token that identifies a runtime-managed window within the current workstation process. typedef uint64_t VkMercuriusWindowTokenMWS; typedef struct VkMercuriusSurfaceCreateInfoMWS { VkStructureType sType; const void* pNext; VkMercuriusSurfaceCreateFlagsMWS flags; VkMercuriusWindowTokenMWS windowToken; VkExtent2D initialExtent; } VkMercuriusSurfaceCreateInfoMWS; VkResult vkCreateMercuriusSurfaceMWS( VkInstance instance, const VkMercuriusSurfaceCreateInfoMWS* pCreateInfo, const VkAllocationCallbacks* pAllocator, VkSurfaceKHR* pSurface ); Surface creation proceeds as follows: 1. An application executing on the workstation initialises the Mercurius runtime and creates an MWS window through the client library. 2. The application creates a Vulkan instance with VK_KHR_surface and VK_MWS_surface enabled, then obtains a Mercurius window token for the target window from the runtime. 3. The application calls vkCreateMercuriusSurfaceMWS() with the window token and the requested initial extent. 4. The Mercurius runtime resolves the token to the corresponding runtime-managed window and forwards the surface creation request to mwsd. 5. The server validates the request against the Session and Application associated with the local client channel, then creates and binds a VkSurfaceKHR for the corresponding Mercurius Window. 6. The application performs ordinary Vulkan WSI operations, including vkGetPhysicalDeviceSurfaceCapabilitiesKHR(), vkGetPhysicalDeviceSurfaceFormatsKHR(), and vkCreateSwapchainKHR() on the returned surface. Window tokens are valid only within the creating process and MUST NOT be serialised, persisted, or shared between processes. Their format is implementation-defined. Applications MUST treat it as an uninterpreted value and MUST NOT derive Mercurius protocol identifiers, session identifiers, stream identifiers, or transport information from it. The initialExtent field expresses the application's preferred initial swapchain dimensions for the window. The server MAY clamp, adjust, or reject this request according to compositor policy and Vulkan surface capabilities. 5.8.1. Surface Binding and Session Validation The windowToken field in VkMercuriusSurfaceCreateInfoMWS is not authoritative. It is treated only as a request to bind a Vulkan presentation surface to a window already known to the Mercurius runtime executing on the workstation. The Mercurius runtime MUST maintain sufficient local state to associate each exported windowToken with the corresponding Mercurius window, rendering stream, and runtime-managed presentation state. This state is internal to the runtime and is not part of the public WSI ABI. When mwsd receives a WSI surface creation request, it MUST validate the request against the Application and Session associated with the local client channel and against the compositor-side state associated with the resolved Window. In particular: * The token MUST resolve to a Window owned by the Session to which the requesting Application belongs. * The resolved window MUST still exist and be eligible for presentation. * The runtime-managed presentation state associated with the resolved Window MUST correspond to presentation resources owned by the requesting Application's Session. * The server MUST reject any request that attempts to bind a Vulkan surface to presentation resources not associated with the authenticated session. If validation fails, the server MUST reject the request with MWS_ERROR_SESSION (type=702, fatal=0). The server MUST NOT reveal the existence, geometry, ownership, visibility, or presentation state of windows belonging to other sessions. These rules ensure that Vulkan surface creation cannot be used to infer or access graphical resources belonging to another user while still permitting the workstation runtime to maintain the internal per-window state required for ordinary Vulkan applications. 5.8.2. Vulkan Extension Registration Vulkan extension names, structure types, and other Vulkan registry values are allocated by the Khronos Group. This document does not allocate them. The names used in Section 5.8 describe the required application-facing semantics and are provisional until the corresponding Vulkan extension is registered. Implementations MUST NOT infer or privately assign a Vulkan numeric value from this document. Once registered, the extension specification and Khronos registry are authoritative for the application-facing ABI. Such registration does not alter the MWS wire protocol. The type VkMercuriusWindowTokenMWS is an opaque unsigned integer type used solely for application-facing surface creation. Its numeric value has no protocol meaning outside the workstation runtime. 5.9. Error Handling (700-799) Errors are six distinct MWS Message types: MWS_ERROR (type=700) An error for which no more specific type applies. MWS_ERROR_PROTOCOL (type=701) A malformed Message, unknown opcode, invalid state transition, wrong stream, or other violation of this specification. MWS_ERROR_SESSION (type=702) An invalid Session, Seat, Window, or other Session-scoped reference. MWS_ERROR_TRANSPORT (type=703) A failure while carrying a Message over the Transport. MWS_ERROR_POLICY (type=704) A request rejected by authentication, authorisation, compositor, or other local policy. MWS_ERROR_RESOURCE (type=705) A request that cannot be accepted because a required resource is unavailable or the peer's declared resource limit was exceeded. The error type is carried by the MWS header. It is not repeated in the payload. Every error Message has the following payload: uint16_t offending_type; uint16_t reserved; uint32_t window_id; uint32_t fatal; uint32_t description_len; uint8_t description[description_len]; All integer fields are in network byte order. offending_type is the opcode of the Message that caused the error, or zero when no decoded opcode is available. reserved MUST be zero. window_id is the relevant Window identifier, or zero when the error does not concern a Window or disclosing its identifier would reveal information outside the peer's Session. fatal MUST be zero or one. description is an optional UTF-8 diagnostic without a terminating NUL; description_len MAY be zero. The payload length MUST equal 16 plus description_len. Error Messages MUST be sent reliably and in order on Stream 0. Receipt of a recoverable error does not report the eventual outcome of any other accepted Message. It reports only that the indicated Message could not be accepted or completed by the object reporting the error. A fatal error requires the sender to close the association after attempting to transmit the error. If the association has already been lost, or the offending header cannot be parsed sufficiently to address a reply, no error Message can be sent. 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.8. All error payload fields follow the network-byte-order rules defined in Section 5.1. 5.9.1. Session and Resource Validation Errors The server MUST validate that all window_id, seat_id, and session_id fields in portal-originated messages refer to resources owned by the authenticated session associated with the transport association (for example, an SCTP association) identified by assoc_id in the servers internal session and transport tables, 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_SESSION (type=702, 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 * attempting to create or bind a Vulkan surface using runtime-managed presentation state that does not belong to the authenticated session * attempting to resume or manipulate a session not associated with the current transport association (assoc_id) * 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 portals 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 The Mercurius reference implementation is under active development. It provides executable evidence for the implemented subset of this specification; it is not yet a complete conforming implementation. In particular, DTLS, DANE, generic Vulkan application support, audio, video fallback, Session detach/resume, and full desktop environments remain future work at the time of this revision. The implementation targets contemporary UNIX-like systems, with Debian and FreeBSD as the primary development platforms. All components rely only on portable interfaces available across BSD and POSIX systems. The code builds and runs on Linux, but Linux is neither assumed nor required. Mercurius follows the same command-line mental model as SSH. A user on a remote device may run: flash$ ssh chris@xavier uptime flash$ mwsc chris@xavier mlogo In both cases the user authenticates to a remote workstation and executes a program there. SSH provides a remote shell; Mercurius provides a remote graphical session. The application executes on the workstation while its windows are projected to the user's portal. Mercurius Portals are a modern reimagining of the XTerminal concept. Like historical XTerminals, they provide display, input, and audio while applications execute entirely on the workstation. The secure, detachable, GPU-accelerated system specified here is the intended destination of the implementation, not a claim that every component is already complete. 6.1. Workstation Components The workstation components are installed on the workstation that owns GPU resources, compositor state, user sessions, and application execution. mwsd The Mercurius server daemon. It currently implements SCTP association handling, application-layer authentication, Session creation, application launch, Window management, and the present compositor path. It enumerates zero or more Vulkan devices and assigns Sessions across the available server GPUs. DTLS and DANE are not yet implemented. libmws The Mercurius application client library. Linked into applications running on the workstation, it provides the public API used to communicate with mwsd together with protocol bindings and object abstractions. mws_protocol.h The protocol is implemented by shared public headers and a protocol library. These define framing, opcodes, scalar types, Messages, Transports, and related facilities used by both server and Portal. mlogo A minimal demonstration application linked against libmws. It currently validates application launch, Window creation, mapping, resize, and RGBA presentation over the network. The Vulkan rendering path required by the first implementation milestone remains in development. 6.2. Portal Components The portal components are installed on laptops, thin portals, embedded devices, and other systems used to access a remote workstation. mwsc The Mercurius Portal. It currently implements SCTP transport, application-layer authentication, Session establishment, server-side application requests, X11 Window presentation, and Window configuration. DTLS, DANE, audio, AV1 decoding, and Vulkan presentation remain future work. mwsc is invoked similarly to SSH: flash$ mwsc chris@xavier mlogo 6.3. Demonstration Applications mlogo is the current end-to-end demonstration Application. More demanding Vulkan demonstrations, games, and complete desktop environments are validation goals for later milestones and are not capabilities claimed by this revision. 6.4. Dependencies The reference implementation targets contemporary UNIX-like systems, with Linux and FreeBSD as first-class development platforms. Current build dependencies include: * SCTP support (FreeBSD provides a full in-kernel SCTP stack) * Vulkan loader and headers * PAM -- Pluggable Authentication Modules * OpenSSL libcrypto * X11 and Wayland client development libraries for the Portal * SDL2 and SDL2_image for current server-side support code * POSIX threads 6.5. Bootstrap Example This example illustrates the intended minimal three-host deployment. Commands or capabilities not yet implemented are labelled accordingly: * xavier -- workstation running the MWS server * flash -- thin portal providing display and input * greenway -- thin portal based in Switzerland 1. Start the server: xavier$ mwsd --port TBD1 Here and below, TBD1 denotes the SCTP port assigned to MWS by IANA. mwsd listens for DTLS/SCTP associations on that port and exposes the compositor and session manager. 2. Run an application on the LAN: flash$ mwsc chris@xavier mlogo mlogo executes on xavier, connects to the local mwsd, joins the session associated with flash, creates a window, and renders the Mercurius logo. In the current implementation this validates SCTP transport, user authentication, Session creation, application launch, Window creation and mapping, resize, and RGBA presentation. It does not yet validate DTLS, DANE, Vulkan rendering, audio, or detach/resume. 3. Run an application over the Internet: greenway$ mwsc per@xavier.tebibyte.org mlogo mlogo executes on xavier, connects to the local mwsd, creates a new session and renders the Mercurius logo in a resizable, movable window on Per's machine in Switzerland. In this example both endpoints require suitable connectivity, routing, and the security profile specified by this document. Internet deployment is a protocol goal; the current reference implementation is not yet suitable for use on an untrusted network. 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 portals. 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 portal 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 Bootstrap and rendering: Establish a Session and render a minimal surface using the reference Portal. An initial frame MUST be displayed on the reference hardware, and the Session MUST terminate or detach cleanly. Window lifecycle: Create, map, unmap, and destroy a Window while observing compositor events. The CREATE, MAP, UNMAP, and DESTROY sequence MUST be correct, and no resources may be orphaned. Session persistence: Start a Session, detach it or allow the Portal to disconnect, and then resume it using the same Session identifier. The compositor state MUST be reconstructed as defined in Sections 4.8, 4.9, and 5.2.2, and the Portal MUST be able to redraw without a protocol violation. GPU isolation: Run multiple Portals concurrently, each creating independent surfaces. There MUST be no cross-Session resource leakage; surfaces and Windows MUST remain isolated. Transport stream allocation: Exercise control, rendering, input, video, and audio traffic. Messages MUST NOT be reordered where their class requires ordered delivery, and routing by Session, Seat, logical stream, and Window identifier MUST remain correct. Transport fragmentation: Negotiate max_user_message_size below the size of a MWS_RENDER_PRESENT. Transport MUST emit a valid MWS_MESSAGE_START and MWS_MESSAGE_APPEND sequence, and the peer MUST deliver exactly one reconstructed MWS_RENDER_PRESENT with an identical header and payload. Simultaneous associations with different limits MUST reassemble independently. Losing an association with a fragmented Message in progress MUST NOT deliver an incomplete Message or consume a later Message as continuation data. MWS_MESSAGE_ABANDON MUST discard an incomplete Message and permit the next Message on that stream to be processed normally. Error handling: Send invalid identifiers, malformed Messages, and protocol violations. The server MUST return the applicable error Message from the 700-799 range while preserving Session integrity unless the error is fatal. 7.1.2. Reference Implementation Commands (Non-Normative) The reference implementation provides the canonical server and portal binaries 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 three hosts: * xavier: a workstation acting as the server * flash: a thin portal * kitty: a laptop acting as a thin portal * Bootstrap + Render: root@xavier# mwsd chris@xavier$ mwsc -lc mlogo chris@xavier$ mwsc localhost mlogo Expected result: a logo window appears on the display attached to xavier; mlogo exits when the user closes the window. flash$ mwsc --host xavier --port TBD1 mlogo Run the mlogo command on the server 'xavier' from flash. Expected result: a logo window appears on the display attached to flash; mlogo exits when the user closes the window. * Session Persistence: flash$ mwsc xavier [mwsdm presents a login prompt; user authenticates] [mwsdm offers to resume an existing detached Session or start a new one] [user resumes their previous session] Expected result: the resumed session appears exactly as it was left, with windows and compositor state reconstructed as defined in Sections 4.8, 4.9, and 5.2.2. The portal can re-establish rendering without violating protocol or WSI rules. * GPU Isolation (multiple portals): flash$ mwsc xavier mlogo kitty$ mwsc xavier mlogo Expected result: independent windows are created in separate sessions on flash and kitty without visible interference. Destroying one portal or terminating one session does not affect the others. * CLI Variants (for completeness): mwsd variants: root@xavier# mwsd --help root@xavier# mwsd --version root@xavier# mwsd -p TBD1 mwsc variants: xavier$ mwsc -l mlogo xavier$ mwsc -lc mlogo xavier$ mwsc --local mlogo xavier$ mwsc --local --command /usr/local/bin/mlogo xavier$ mwsc localhost mlogo flash$ mwsc -h xavier -p TBD1 flash$ mwsc -h xavier -c mlogo kitty$ mwsc chris@xavier kitty$ mwsc chris@xavier.tebibyte.org "/usr/local/bin/mlogo" flash$ mwsc --help flash$ mwsc --version 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, regardless of whether the server contains a single GPU or multiple GPUs. * 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, per-session scheduling domains, or multi-GPU distribution strategies 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. On systems with multiple GPUs, implementations MAY assign sessions to different GPUs to improve isolation or load distribution. * The server SHOULD implement watchdog mechanisms to detect and recover from GPU hangs attributable to a particular session. Recovery MAY include resetting portal queues, revoking swapchains, or terminating the offending session while preserving other sessions. On multi-GPU systems, recovery MAY include migrating unaffected sessions to other GPUs. 7.3. Bandwidth and Transport Isolation Requirements Implementations MUST ensure that control and input remain responsive under load and that one portal cannot monopolise transport resources to the detriment of others. * Servers using a one-to-many SCTP socket MUST NOT treat writable readiness of that socket as readiness of a particular association. The SCTP sockets API explicitly permits writable readiness to mean that only one of the represented associations is writable [RFC6458]. To keep the handshake cheap, implementations SHOULD defer association-specific resources until authentication has succeeded. They SHOULD then isolate the association with sctp_peeloff(), or use an equivalent association-specific readiness and queueing mechanism, before sending MWS_SESSION_INFO. * Outbound buffering and backpressure MUST be tracked per association. A stalled association MUST NOT delay sends to another association. Implementations MUST bound per-association queued data so that one portal cannot exhaust workstation memory. * Stream 0 (control) MUST use reliable, ordered delivery and MUST be prioritised over bulk data on other streams. A later specification defining Stream 2 input MUST preserve equivalent ordering and priority unless it explicitly defines otherwise. * Stream 1 (rendering Messages) MUST use reliable, ordered delivery. The server MAY impose rate limits on VK_SUBMIT or equivalent rendering messages to prevent excessive queueing. * Stream 2 carries input according to the per-event reliability, ordering, and coalescing requirements in Section 5.4. * Stream 3 carries video and MAY use partial reliability where the Message definition permits obsolete frames to be discarded. * Stream 4 carries audio. Each audio Message definition MUST state its ordering, loss, buffering, and flow-control requirements. * The server SHOULD implement per-session or per-portal 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 portal without impacting other sessions. Termination SHOULD be signalled with the applicable fatal error Message followed by closure of the SCTP association, as defined in Section 5.9. Termination MUST release all GPU, transport, and compositor resources associated with that portal, and MUST NOT affect other active sessions. 8. Performance Considerations MWS was designed only after exploratory measurements indicated that the intended network-native architecture was technically plausible. These measurements were a feasibility study, not a benchmark of a complete Mercurius implementation. In the reference environment, the prospective Portal and workstation were located in different buildings. The path crossed a 10 GbE link, two switches, and a 10 Gbit/s fibre link. A 20-second, single-flow TCP test using fio's network engine and an I/O depth of one reported sustained throughput of approximately 1.3-1.5 Gbit/s. Representative ICMP measurements within the same site reported round-trip times of 0.181-0.339 ms, with a mean of 0.293 ms. These observations established that neither available bandwidth nor site-network propagation delay was an immediate obstacle to exploring a network-native Window system. They do not measure SCTP or DTLS overhead, GPU encoding, Portal decoding, display scheduling, or the complete input-to-display path. The completion latency reported by a local socket write is likewise not a measurement of network transit time. The reference workstation contains an NVIDIA GeForce RTX 5070. NVIDIA documents that device as providing a ninth-generation NVENC encoder with AV1 support [RTX50]. NVENC is dedicated encoding hardware and can operate independently of the graphics and CPU cores [NVENC]. These published capabilities supported the feasibility decision, but they are not measurements of Mercurius encode latency, processor use, or achievable resolution and refresh rate. No end-to-end performance figures are claimed by this specification. Implementations should measure at least transport latency and throughput, encode and decode latency, display scheduling delay, input-to-display latency, processor and GPU utilisation, and tail latency under concurrent Session load. Results should identify the measured boundary, topology, Message sizes, transport security, sample count, and percentile distribution. The protocol nevertheless provides mechanisms intended to avoid unnecessary interference between traffic classes. Control and rendering use separate SCTP streams, future input, video, and audio traffic have reserved streams, and buffering is bounded per association. These properties reduce avoidable head-of-line blocking but do not guarantee any particular latency, throughput, or user experience. 9. Security Considerations MWS is designed according to zero-trust principles: no portal 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 portal 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 DTLS 1.3 over SCTP using [I-D.6083BIS]. The Portal authenticates the server certificate, and DTLS provides confidentiality and integrity for MWS traffic. When DANE is deployed, the server certificate is validated against DNSSEC-protected TLSA records. 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 (for example, "PAM", "FIDO2") as UTF-8 identifiers in MWS_AUTH_CHALLENGE, and the portal selects one. This separation of device and user identity ensures that device identity alone does not grant access to a user's Session. Authentication proofs made with reusable credentials MUST be bound to the current DTLS association. In particular, SSHKEY signs the tls-exporter channel binding defined by [RFC9266]. A response captured on one association therefore cannot authenticate a new association. Authentication data received from a Portal MUST NOT be treated as evidence of freshness unless the server can derive and verify that freshness independently. Each user is given an isolated session and compositor context. Portals cannot observe or interfere with other users' windows, input events, or rendering state. Window identifiers are scoped to a session, and all portal-originated messages are validated by the server. Attempts to reference resources outside the authenticated session are rejected with MWS_ERROR_SESSION (type=702) as described in Section 5.9. Portal-association rendering Messages use a dedicated SCTP stream. Streams 2-4 are reserved so that later input, video, and audio definitions need not share the control or rendering paths. Partially reliable delivery MAY be used by a later video definition to avoid resource exhaustion and excessive retransmissions. Later input, video, and audio definitions MUST preserve Session isolation and MUST prevent a Portal from injecting, redirecting, or observing another Session's traffic. This revision makes no further security claim for those reserved protocol planes. The server does not trust a Portal as an authority over Session state or resources. An active Portal is nevertheless trusted by its user with displayed content, captured input, and any reusable credential stored or entered there. Compromise of that Portal can compromise that user, but MUST NOT cross Session or user boundaries. If a portal 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.8. 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.8 and MAY be resumed from another portal subject to policy. Explicit detachment is requested with MWS_SESSION_DETACH (type=103). It is distinct from unexpected association loss: detachment records the user's intention to suspend and preserve the Session, whereas association loss enters the bounded reconnection grace period. 9.1. DANE Deployment (Non-Normative) Deployments that operate their own DNS infrastructure MAY use DNSSEC and TLSA records (DANE) to authenticate server certificates during the DTLS/SCTP handshake. When DNSSEC validation is available, DANE provides a robust mechanism for binding workstation identity to DNS without relying on public certificate authorities. In this model, the portal validates the server's certificate against DNSSEC-protected TLSA records before proceeding with the MWS handshake, ensuring that it is communicating with the intended workstation even in the presence of compromised or mis-issued CA certificates. DANE is OPTIONAL and does not alter protocol semantics. When enabled, it reduces operational complexity in closed trust domains by eliminating external trust dependencies 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. Register the following entry in the Service Name and Transport Protocol Port Number Registry: Service Name: mws Port Number: TBD1 Transport Protocol: SCTP Description: Mercurius Window System Assignee: IESG Contact: IETF Chair Reference: This document IANA is requested to allocate TBD1 from the Registered Port range. The RFC Editor is requested to replace every occurrence of TBD1 with the assigned port number before publication. 2. Register the following entry in the TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs registry [RFC7301]: Protocol: Mercurius Window System Identification Sequence: 0x6d 0x77 0x73 ("mws") Reference: This document MWS does not require a dedicated SCTP Payload Protocol Identifier. MWS uses the SCTP encapsulation assigned by the DTLS-over-SCTP mapping, and the MWS application protocol is identified by ALPN. 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 the reference implementation. The reference implementation described in Section 6 is maintained in the Mercurius source code repository. Git and SSH access are available to contributors on request via mercurius@tebibyte.org. Additional background material, including architectural rationale, design philosophy, and example use cases, is available from the Mercurius project website . This information is provided for context only and is non-normative; the protocol defined in this document is complete and does not depend on any specific implementation or external documentation. 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 K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260, June 2022. [I-D.6083BIS] Tuexen, M., Tschofenig, H., and T. Reddy, "Datagram Transport Layer Security (DTLS) 1.3 for Stream Control Transmission Protocol (SCTP)", Work in Progress, Internet-Draft, draft-tuexen-tsvwg-rfc6083-bis-07, 21 April 2025. [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014. [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. [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015. [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022. [RFC9266] Whited, S., "Channel Bindings for TLS 1.3", RFC 9266, DOI 10.17487/RFC9266, July 2022. [VK14] Khronos Group, "Vulkan 1.4 Specification", 2024. 12.2. Informative References [RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V. Yasevich, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", RFC 6458, DOI 10.17487/RFC6458, December 2011. [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, DOI 10.17487/RFC3436, December 2002. [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/RFC6083, January 2011. [NIST800-207] National Institute of Standards and Technology, "Zero Trust Architecture", NIST Special Publication 800-207, August 2020. [NVENC] NVIDIA Corporation, "NVENC Application Note", NVIDIA Video Codec SDK 13.0, 2025, . [RTX50] NVIDIA Corporation, "GeForce RTX 50 Series GPUs Double Creative Performance", January 2025, . 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_PROTOCOL (type=701) as described in Section 5.9. Within each standard category, offsets 00-49 are available for Messages in the current protocol family. Values not allocated below are unassigned and remain available for future specifications. Offsets 50-99 are reserved to leave substantial space for later major revisions of Mercurius. The experimental range is the exception to this convention. 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_PROTOCOL (type=701, fatal=1). 001 MWS_QUERY 002 MWS_AUTH_CHALLENGE 003 MWS_AUTH_RESPONSE 004 MWS_SESSION_INFO 005-049 Unassigned 050-099 Reserved for later protocol revisions A.2. Session Management (100-199) 100 MWS_SESSION_RESUME_OFFER 101 MWS_SESSION_RESUME_REQUEST 102 MWS_SESSION_RESUME_COMPLETE 103 MWS_SESSION_DETACH 104 MWS_SESSION_NEW_REQUEST 105 MWS_SESSION_STATE_BEGIN 106-109 Unassigned 110 MWS_EXEC_REQUEST 111 MWS_EXEC_RESULT 112-149 Unassigned 150-199 Reserved for later protocol revisions 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 209 MWS_WINDOW_STATE 210-249 Unassigned 250-299 Reserved for later protocol revisions A.4. Rendering Messages (300-399) 300 MWS_RENDER_PRESENT 301 MWS_RENDER_SYNC 302 MWS_RENDER_DESTROY 303 MWS_RENDER_UPLOAD 304 MWS_RENDER_DAMAGE 305 MWS_RENDER_FENCE 306-349 Unassigned 350-399 Reserved for later protocol revisions A.5. Input Events (400-499) 400 MWS_INPUT_EVENT 401 MWS_INPUT_ACK 402-449 Unassigned 450-499 Reserved for later protocol revisions A.6. Video Plane (500-599) 500 MWS_AV1_FRAME 501 MWS_PLACEHOLDER_FRAME 502-549 Unassigned 550-599 Reserved for later protocol revisions A.7. Audio Plane (600-699) 600 MWS_AUDIO_PLAYBACK_OPEN 601 MWS_AUDIO_PLAYBACK_ACCEPT 602 MWS_AUDIO_PLAYBACK_REJECT 603 MWS_AUDIO_PLAYBACK_DATA 604 MWS_AUDIO_PLAYBACK_CLOSE 605-619 Unassigned 620 MWS_AUDIO_CAPTURE_OPEN 621 MWS_AUDIO_CAPTURE_ACCEPT 622 MWS_AUDIO_CAPTURE_REJECT 623 MWS_AUDIO_CAPTURE_DATA 624 MWS_AUDIO_CAPTURE_CLOSE 625-649 Unassigned 650-699 Reserved for later protocol revisions A.8. Error Reporting (700-799) 700 MWS_ERROR 701 MWS_ERROR_PROTOCOL 702 MWS_ERROR_SESSION 703 MWS_ERROR_TRANSPORT 704 MWS_ERROR_POLICY 705 MWS_ERROR_RESOURCE 706-749 Unassigned 750-799 Reserved for later protocol revisions A.9. Transport Services (800-899) 800 MWS_MESSAGE_START 801 MWS_MESSAGE_APPEND 802 MWS_MESSAGE_ABANDON 803-849 Unassigned for Transport-to-Transport Messages 850-899 Reserved for later protocol revisions 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 portal 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. "SSHKEY" The Portal proves possession of an SSH private key whose public key is authorised for the requested user. The private key is never transmitted. OpenSSH key files and authorised_keys files MAY be used as local storage formats; those formats do not form part of the MWS wire protocol. The SSHKEY credential has the following format: uint8_t username_len; char username[username_len]; uint8_t algorithm_len; char algorithm[algorithm_len]; uint16_t public_key_len; uint8_t public_key[public_key_len]; uint16_t signature_len; uint8_t signature[signature_len]; Length fields are in network byte order where they occupy more than one octet. Strings are UTF-8 and are not NUL-terminated. Every length MUST be non-zero, and the credential MUST contain exactly the declared fields with no trailing octets. algorithm identifies the SSH signature algorithm. This specification defines ssh-ed25519, rsa-sha2-256, and rsa-sha2-512. The public_key field contains an SSH public-key blob: ssh-ed25519 for an Ed25519 key or ssh-rsa for an RSA key. The signature field is an SSH signature blob containing the same signature algorithm identifier and the signature octets. The Portal and server independently obtain the 32-octet tls-exporter channel binding for the current DTLS association as defined by [RFC9266]. The Portal signs the following byte string: uint8_t domain_len; char domain[domain_len]; uint8_t username_len; char username[username_len]; uint8_t channel_binding_len; uint8_t channel_binding[channel_binding_len]; domain is the ASCII string "MWS-SSHKEY", without a terminating NUL, and channel_binding_len is 32. The username fields MUST be identical to those in the credential. The server MUST construct this byte string from the received username and its own channel binding; it MUST NOT accept a signing envelope supplied by the Portal. The server authenticates the user only if the public key is authorised for username and the signature verifies over this exact byte string. A malformed credential, an algorithm mismatch, an unauthorised key, or an invalid signature fails authentication. 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. Portals 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, video, and audio traffic. This appendix summarises the required stream assignments. All Portal-association 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) * Portal-association Window lifecycle Messages (200-299) * error messages (700-799) Messages on Stream 0 MUST be delivered reliably and in order. A logical Message larger than max_user_message_size is fragmented by Transport as defined in Section 5.1.1. C.2. Stream 1 -- Rendering Messages Stream 1 carries Portal-association rendering Messages, currently MWS_RENDER_PRESENT, MWS_RENDER_SYNC, and MWS_RENDER_DESTROY. MWS_RENDER_UPLOAD is a client-channel and in-process workstation Message and MUST NOT be sent on an SCTP Portal association. MWS_RENDER_DAMAGE and MWS_RENDER_FENCE are reserved and MUST NOT be sent by implementations of this version. Messages on Stream 1 MUST be delivered reliably and in order. A logical Message larger than max_user_message_size is fragmented by Transport as defined in Section 5.1.1. C.3. Stream 2 -- Input Events Stream 2 carries input Messages (400-499). Delivery semantics depend on the event class as specified in Section 5.4: state transitions are reliable and ordered, while superseded motion may be coalesced only where doing so preserves intervening state. C.4. Stream 3 -- Video Plane Stream 3 carries video Messages (500-599). Its definition permits partial reliability where obsolete frames can be discarded without invalidating subsequent decoder state. C.5. Stream 4 -- Audio Plane Stream 4 carries audio Messages (600-699). Playback and capture streams have independent logical stream_id values and the lifecycle specified in Section 5.6. Their eventual payload definitions MUST state ordering, loss, buffering, and flow-control semantics. C.6. Additional Streams Streams 5-15 are reserved for future standard 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 portal and server during initial connection, session resumption, and normal operation. All Portal-association control-plane transitions occur on SCTP Stream 0. Portal-association rendering, input, video, and audio traffic occur on their respective streams as defined in Appendix C. D.1. Initial Connection State Machine +------------------+ | TRANSPORT_UP | +------------------+ | | MWS_QUERY (001) | MWS_AUTH_CHALLENGE (002) | MWS_AUTH_RESPONSE (003) v +------------------+ | AUTH_VERIFY | +------------------+ | | failure -> fatal error and association loss | success -> MWS_SESSION_RESUME_OFFER (100) v +------------------+ | SESSION_SELECT | +------------------+ | | MWS_SESSION_NEW_REQUEST (104) v +------------------+ | NEW_PENDING | +------------------+ | | server MWS_SESSION_INFO (004) | Portal MWS_SESSION_INFO (004) v +------------------+ | ACTIVE_SESSION | +------------------+ | | normal Session traffic on Streams 0-4 v +------------------+ | RUNNING | +------------------+ D.2. Session Resume State Machine +------------------+ | RESUME_OFFERED | +------------------+ | | MWS_SESSION_RESUME_REQUEST (101) v +------------------+ | RESUME_VERIFY | +------------------+ | | failure -> MWS_ERROR_SESSION (702, fatal=0), | return to RESUME_OFFERED | success -> reserve Session v +------------------+ | RESUME_PENDING | +------------------+ | | server MWS_SESSION_INFO (004) | Portal MWS_SESSION_INFO (004) | MWS_SESSION_STATE_BEGIN (105) | MWS_WINDOW_STATE (209), repeated | MWS_SESSION_RESUME_COMPLETE (102) v +------------------+ | ACTIVE_SESSION | +------------------+ | | normal operation resumes: | * Portal-association rendering on Stream 1 | * input on Stream 2 | * video on Stream 3 | * audio on Stream 4 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_* (700-705, fatal=0) v +------------------+ | CONTINUE | +------------------+ | | fatal error | MWS_ERROR_* (700-705, fatal=1) v +------------------+ | TERMINATE | +------------------+ | | SCTP association closed v +------------------+ | END | +------------------+ D.4. Stream Interaction Summary The following summary illustrates the concurrency model across SCTP streams: Stream 0 (control): ordered, reliable * handshake (001-099) * session management (100-199) * window lifecycle (200-299) * error reporting (700-799) Stream 1 (rendering): ordered, reliable * rendering Messages (300-399), including pixel buffers Stream 2 (input): delivery policy depends on event class * input Messages (400-499) Stream 3 (video): partial reliability where defined * video Messages (500-599) Stream 4 (audio): delivery policy depends on Message type * audio Messages (600-699) These streams operate independently. Loss or delay on one stream MUST NOT block progress on any other stream. Author's Address Christopher Ross Independent Email: chris@tebibyte.org Project Website: https://mercurius.tebibyte.org