Media Over QUIC C. Jennings Internet-Draft S. Nandakumar Intended status: Standards Track Cisco Expires: 7 January 2027 6 July 2026 MOCHA Chat: Messaging over MoQ Transport draft-jennings-moq-mocha-chat-00 Abstract This document specifies the messaging functionality for MOCHA (MoQ Open Communication & Hosting Architecture). It defines how participants send and receive messages in channels using MoQ Transport (MOQT) publish/subscribe primitives. Each device publishes messages on its own track within a channel namespace, enabling decentralized message production with relay-based fan-out. This specification covers message naming, format, causal ordering, delivery, roster management, and channel discovery for text-based chat. About This Document This note is to be removed before publishing as an RFC. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-jennings-moq-mocha-chat/. Discussion of this document takes place on the Media Over QUIC Working Group mailing list (mailto:moq@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at https://www.ietf.org/mailman/listinfo/moq/. 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." Jennings & Nandakumar Expires 7 January 2027 [Page 1] Internet-Draft mocha-chat July 2026 This Internet-Draft will expire on 7 January 2027. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. MOCHA Chat Naming . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Identifier Derivation . . . . . . . . . . . . . . . . . . 4 3.2. Channel Namespace . . . . . . . . . . . . . . . . . . . . 4 3.3. Track Names . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. Group Semantics . . . . . . . . . . . . . . . . . . . . . 5 3.5. Object Semantics . . . . . . . . . . . . . . . . . . . . 5 3.6. MOQT Object Mapping . . . . . . . . . . . . . . . . . . . 5 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Compression Track Property . . . . . . . . . . . . . . . 6 4.3. Message Structure . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Top-Level Fields . . . . . . . . . . . . . . . . . . 7 4.3.2. Sender Info . . . . . . . . . . . . . . . . . . . . . 8 4.3.3. Content Structure . . . . . . . . . . . . . . . . . . 9 4.3.4. Message Type Values . . . . . . . . . . . . . . . . . 9 4.4. Example Message . . . . . . . . . . . . . . . . . . . . . 9 5. Causal Ordering . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Previous Message List . . . . . . . . . . . . . . . . . . 10 5.2. Ordering Semantics . . . . . . . . . . . . . . . . . . . 11 5.3. Display Ordering . . . . . . . . . . . . . . . . . . . . 11 6. Message Edit and Delete . . . . . . . . . . . . . . . . . . . 11 6.1. Edit (type 2) . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Delete (type 3) . . . . . . . . . . . . . . . . . . . . . 12 6.3. Processing Rules . . . . . . . . . . . . . . . . . . . . 12 7. Threading . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Thread Replies . . . . . . . . . . . . . . . . . . . . . 13 7.2. Thread Display . . . . . . . . . . . . . . . . . . . . . 13 7.3. Thread Edits and Deletes . . . . . . . . . . . . . . . . 13 Jennings & Nandakumar Expires 7 January 2027 [Page 2] Internet-Draft mocha-chat July 2026 8. MOCHA Roster Naming . . . . . . . . . . . . . . . . . . . . . 13 8.1. Roster Namespace . . . . . . . . . . . . . . . . . . . . 13 8.2. Roster Track Names . . . . . . . . . . . . . . . . . . . 14 8.3. Roster Object Format . . . . . . . . . . . . . . . . . . 14 8.4. Roster Usage . . . . . . . . . . . . . . . . . . . . . . 14 9. Channel Discovery . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Channel Info Namespace . . . . . . . . . . . . . . . . . 15 9.2. Channel Info Track Names . . . . . . . . . . . . . . . . 15 9.3. Channel Info Object Format . . . . . . . . . . . . . . . 15 10. Availability . . . . . . . . . . . . . . . . . . . . . . . . 16 10.1. Availability Namespace . . . . . . . . . . . . . . . . . 16 10.2. Availability Track Names . . . . . . . . . . . . . . . . 16 10.3. Availability States . . . . . . . . . . . . . . . . . . 17 10.4. Availability Object Format . . . . . . . . . . . . . . . 17 10.5. Availability Updates . . . . . . . . . . . . . . . . . . 17 10.6. Typing Indicators . . . . . . . . . . . . . . . . . . . 18 10.6.1. Typing Object Format . . . . . . . . . . . . . . . . 18 10.7. Subscribing to Availability . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 12.1. MOCHA_COMPRESSION Track Property . . . . . . . . . . . . 18 12.2. MOCHA Compression Algorithms Registry . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction Messaging is the most fundamental operation in any communication system. This document specifies how MOCHA enables real-time message exchange between participants in channels using MOQT's publish/ subscribe model. MOCHA Chat assigns each publishing device its own MOQT track within a channel namespace. Messages are grouped by NTP time in minutes, enabling straightforward time-based history retrieval and relay caching. Causal ordering is maintained through a previous-message linkage that forms a DAG across the per-device tracks in a channel. 2. Conventions and Definitions See BCP 14 [RFC2119] [RFC8174]. Jennings & Nandakumar Expires 7 January 2027 [Page 3] Internet-Draft mocha-chat July 2026 This document uses terminology and architecture defined in [MOCHA-ARCH], including Provider, Organization, Team, Channel, Device, GroupID, and ObjectID. The MOQT transport primitives (Track, Group, Object, Namespace, Relay) are defined in [MoQTransport]. HClientID and HDevID are defined in [MOCHA-IDENTITY]. The following additional terms are used: Provider: The service provider operating the MOCHA deployment. Identified by a domain name or similar unique string. OrgID: The organization identifier within a provider's deployment. TeamID: An identifier for a team or workspace within an organization. ChannelID: An identifier for a specific channel within a team. MsgID: A globally unique identifier for a message. Implementations SHOULD use a UUID (version 4) to generate MsgIDs. 3. MOCHA Chat Naming 3.1. Identifier Derivation The HClientID and HDevID used in namespace tuples and track names are derived per [MOCHA-IDENTITY], Section "Identifier Derivation". 3.2. Channel Namespace The MOQT tracks that carry chat messages use a namespace tuple with the following fields: ("mocha_v1", , , "chat", , , ) For example, messages in the "general" channel of team "engineering" at organization "acme" hosted by provider "example.com": ("mocha_v1", "example.com", "acme", "chat", "engineering", "general", ) 3.3. Track Names Each device publishes messages on its own track within the channel namespace. The track name is a single byte sequence: msg_v1_ Jennings & Nandakumar Expires 7 January 2027 [Page 4] Internet-Draft mocha-chat July 2026 For example: Namespace: ("mocha_v1", "example.com", "acme", "chat", "engineering", "general", ) Track Name: "msg_v1_" This per-device track design allows each device to publish independently without coordinating Group IDs with other publishers. 3.4. Group Semantics Groups are NTP time in minutes. The Group ID corresponds to the NTP timestamp (in minutes) at the time the message is published: group_id = floor(ntp_timestamp_seconds / 60) This provides: * Natural time-based partitioning of messages. * Straightforward mapping from wall-clock time to Group ID for history retrieval. * One-minute granularity balances caching efficiency with latency. 3.5. Object Semantics Within each group, messages are assigned sequentially increasing Object IDs starting at 0. Each message occupies exactly one MOQT object. 3.6. MOQT Object Mapping Jennings & Nandakumar Expires 7 January 2027 [Page 5] Internet-Draft mocha-chat July 2026 Namespace: ("mocha_v1", "example.com", "acme", "chat", "engineering", "general") | +-- Track: msg_v1_alice-laptop-1 | +-- Group 29598720 (minute: 2024-05-15 16:00 UTC) | | +-- Object 0: "Hello everyone" | | +-- Object 1: "Ready for standup?" | | | +-- Group 29598721 (minute: 2024-05-15 16:01 UTC) | +-- Object 0: "Let's start" | +-- Track: msg_v1_bob-desktop-1 | +-- Group 29598720 | | +-- Object 0: "Hey Alice!" | | | +-- Group 29598721 | +-- Object 0: "Sounds good" | +-- Object 1: "Sharing my screen now" | +-- Track: msg_v1_carol-phone-1 +-- Group 29598721 +-- Object 0: "On my way, 2 min" 4. Message Format 4.1. Encoding Messages are encoded as JSON [JSON] and compressed before being placed in the MOQT object payload. The compression algorithm is signaled via the MOCHA_COMPRESSION track property (see Section 4.2). 4.2. Compression Track Property The MOCHA_COMPRESSION track property signals the compression algorithm applied to ALL objects on a message track. Publishers MUST include this property in the PUBLISH message (publisher-initiated flow) or SUBSCRIBE_OK (subscriber-initiated flow). Subscribers MUST check for this property before processing track payloads. If the property is absent, the subscriber MUST treat the payload as uncompressed. If the property is present with a value the subscriber does not support, the subscriber MUST NOT attempt to process the payload and SHOULD unsubscribe from the track. The following compression algorithm values are defined: Jennings & Nandakumar Expires 7 January 2027 [Page 6] Internet-Draft mocha-chat July 2026 +=======+===========+===============+ | Value | Algorithm | Reference | +=======+===========+===============+ | 0 | None | This document | +-------+-----------+---------------+ | 1 | GZIP | [RFC1952] | +-------+-----------+---------------+ | 2 | Brotli | [RFC7932] | +-------+-----------+---------------+ Table 1 Implementations MUST support GZIP (value 1) and MAY support Brotli (value 2). A publisher that does not compress MUST either set the property to 0 or omit it entirely. 4.3. Message Structure The message structure follows the MIMI content format style [MIMI-CONTENT], adapted for MOCHA's channel-based messaging. Fields use short keys for compact JSON encoding. { "msgId": "", "type": 0, "ts": 1715788800000, "sender": { "userId": "", "displayName": "", "devId": "" }, "content": { "type": "text/plain", "body": "" }, "prev": ["", ...], "threadId": "", "replaces": "", "expires": 0, "ext": {} } The message fields are defined as follows: 4.3.1. Top-Level Fields msgId (REQUIRED): The globally unique identifier for this message Jennings & Nandakumar Expires 7 January 2027 [Page 7] Internet-Draft mocha-chat July 2026 within the channel. Implementations SHOULD use a UUID (version 4). type (REQUIRED): Integer message type. This specification defines type 0 (none/system) and type 1 (text). The type field is extensible for future message categories. ts (REQUIRED): The time the message was created, in milliseconds since the Unix epoch. Set by the publisher's local clock. sender (REQUIRED): The originator of the message. See Section 4.3.2. content (REQUIRED): The message payload. See Section 4.3.3. prev (REQUIRED): A list of hex-encoded MsgIDs of the immediately preceding message(s) in the channel. This forms a causal ordering DAG across all tracks in the channel. An empty array indicates no known predecessors. See Section 5. threadId (OPTIONAL): The hex-encoded MsgID of the root message that started the thread. Present when this message is a reply within a thread. Threads are flat — nested threading is not supported. If absent, the message is a top-level channel message. replaces (OPTIONAL): The hex-encoded MsgID of a prior message that this message edits or deletes. Present when type is 2 (edit) or 3 (delete). See Section 6. expires (OPTIONAL): Expiration time in milliseconds since the Unix epoch. If non-zero, clients SHOULD hide the message after this time. A value of 0 indicates no expiration. ext (OPTIONAL): An object containing extension fields. Implementations MUST ignore unknown extension keys. Extensions are namespaced to avoid collisions (see [MOCHA]). 4.3.2. Sender Info The sender object identifies the message author: userId (REQUIRED): A stable identifier for the user within the identity system (e.g., "alice@acme.example.com"). displayName (REQUIRED): A human-readable label for rendering in the UI. devId (REQUIRED): The identifier of the publishing device. MUST Jennings & Nandakumar Expires 7 January 2027 [Page 8] Internet-Draft mocha-chat July 2026 match the HDevID in the track name from which the message is published. 4.3.3. Content Structure The content object carries the message payload, following MIMI's content disposition pattern: type (REQUIRED): A MIME type string indicating the content format. This specification defines "text/plain" for plain text messages. Implementations MUST support "text/plain". body (REQUIRED): The content payload. For "text/plain", this is a UTF-8 string containing the message text. Future specifications MAY define additional content types (e.g., "text/markdown"). Clients receiving an unknown content type SHOULD render the body as plain text if it is a string, or display a placeholder indicating an unsupported format. 4.3.4. Message Type Values +=======+========+======================================+ | Value | Name | Description | +=======+========+======================================+ | 0 | none | System or control message (no body) | +-------+--------+--------------------------------------+ | 1 | text | Text message | +-------+--------+--------------------------------------+ | 2 | edit | Replaces content of a prior message | +-------+--------+--------------------------------------+ | 3 | delete | Removes a prior message from display | +-------+--------+--------------------------------------+ Table 2 The type enum is extensible. Future specifications define additional values for media and other content. 4.4. Example Message A text message as JSON (before compression): Jennings & Nandakumar Expires 7 January 2027 [Page 9] Internet-Draft mocha-chat July 2026 { "msgId": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2", "type": 1, "ts": 1715788800000, "sender": { "userId": "alice@acme.example.com", "displayName": "Alice Smith", "devId": "" }, "content": { "type": "text/plain", "body": "Hello everyone, ready for the standup?" }, "prev": ["e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6"] } 5. Causal Ordering 5.1. Previous Message List Each message contains a "previous" field listing the MsgID(s) of the most recent message(s) the publisher has observed in the channel at the time of publishing. This forms a directed acyclic graph (DAG) across all per-device tracks in a channel. Causal DAG across devices: Alice's track: A1 -----> A2 ---------> A3 \ \ / Bob's track: --> B1 --> B2 ------> \ Carol's track: --> C1 In this example: * A1 has no previous (first message in channel, or references messages not shown). * B1.previous = [A1] (Bob saw Alice's first message). * A2.previous = [B1] (Alice saw Bob's reply). * B2.previous = [A2] (Bob saw Alice's second message). * C1.previous = [B2] (Carol saw Bob's second message). * A3.previous = [B2, C1] (Alice saw both Bob and Carol's latest messages). Jennings & Nandakumar Expires 7 January 2027 [Page 10] Internet-Draft mocha-chat July 2026 5.2. Ordering Semantics The previous message list provides causal ordering: * If message B lists message A in its previous list (directly or transitively), then A causally precedes B. * Messages with no causal relationship are concurrent and may be displayed in any order (typically by timestamp). * Clients reconstruct channel ordering by traversing the DAG. 5.3. Display Ordering Clients SHOULD use the causal DAG to determine display order. When causal ordering does not fully determine order (concurrent messages), clients SHOULD fall back to timestamp ordering. A simple linearization algorithm: 1. Topologically sort messages using the DAG. 2. For concurrent messages (no causal relationship), sort by timestamp. 3. For identical timestamps, sort by MsgID (lexicographic on the hash bytes) for deterministic ordering. 6. Message Edit and Delete A sender can edit or delete a message it previously published by publishing a new object on the same track with the replaces field set to the MsgID of the original message. 6.1. Edit (type 2) An edit message replaces the content of a prior message. The content field carries the new text. The original message's position in the causal DAG is preserved; the edit object itself also participates in the DAG via its own prev field. Jennings & Nandakumar Expires 7 January 2027 [Page 11] Internet-Draft mocha-chat July 2026 { "msgId": "b2c3d4...", "type": 2, "ts": 1715788900000, "sender": { "userId": "alice@acme.example.com", "displayName": "Alice Smith", "devId": "" }, "content": { "type": "text/plain", "body": "Hello everyone, ready for standup? (corrected)" }, "prev": ["a1b2c3..."], "replaces": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2" } 6.2. Delete (type 3) A delete message removes a prior message from display. No content field is required; if present it is ignored. { "msgId": "c3d4e5...", "type": 3, "ts": 1715789000000, "sender": { "userId": "alice@acme.example.com", "displayName": "Alice Smith", "devId": "" }, "prev": ["b2c3d4..."], "replaces": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2" } 6.3. Processing Rules 1. Only the original sender (matching userId) MAY edit or delete a message. Receivers MUST ignore edit or delete objects from a different userId than the original message. 2. Multiple edits to the same message are permitted. The edit with the latest causal ordering (per Section 5) takes precedence. 3. A delete after an edit takes precedence: the message is removed from display regardless of prior edits. Jennings & Nandakumar Expires 7 January 2027 [Page 12] Internet-Draft mocha-chat July 2026 4. Receivers SHOULD display an indicator that a message has been edited. Receivers MAY offer access to the edit history. 5. Relays forward edit and delete objects like any other message object without interpreting their semantics. 7. Threading MOCHA supports threaded conversations where replies are grouped under a parent message. Threads are flat — nested threading is not supported. 7.1. Thread Replies To reply within a thread, a device publishes a message on its regular msg_v1_ track with the threadId field set to the MsgID of the root message that started the thread. The root message itself has no threadId field. 7.2. Thread Display Clients SHOULD group messages with the same threadId and display them as a thread under the root message. The root message is identified by its MsgID matching the threadId of the replies. 7.3. Thread Edits and Deletes Edit and delete messages (types 2 and 3) within a thread MUST carry the same threadId as the message they replace. This allows clients to correctly scope the edit or delete to the thread view. 8. MOCHA Roster Naming The roster provides a discovery mechanism for participants to learn which devices are active in a channel. Each device publishes its availability and user identity on a dedicated roster track. Participants subscribe to the roster namespace to build the set of message tracks they should follow. 8.1. Roster Namespace The roster tracks for a channel use the namespace tuple: ("mocha_v1", , , "roster", , , ) HClientID and HDevID are derived per Section 3.1. Jennings & Nandakumar Expires 7 January 2027 [Page 13] Internet-Draft mocha-chat July 2026 For example: ("mocha_v1", "example.com", "acme", "roster", "engineering", "general", ) 8.2. Roster Track Names Each device publishes its user information on a track: user_ For example: Namespace: ("mocha_v1", "example.com", "acme", "roster", "engineering", "general", ) Track Name: "user_" 8.3. Roster Object Format Each object on a roster track contains a JSON document providing information about the mapping of the device to a user in the identity system. The display_name is obtained from the user's PAB entry (see [MOCHA]) and the user_id is obtained from the identity system (see [MOCHA-IDENTITY]). { "user_id": "alice@acme.example.com", "display_name": "Alice Smith", "dev_id": "", "joined_at": 1715788000000, "status": "active" } 8.4. Roster Usage Participants subscribe to the roster namespace to discover which devices are active in a channel. The roster provides the set of msg_v1_ tracks that should be subscribed for receiving channel messages. When a new device joins a channel, it publishes a roster object. When a device leaves, it publishes an updated roster object with status "departed" or the track simply becomes inactive. Jennings & Nandakumar Expires 7 January 2027 [Page 14] Internet-Draft mocha-chat July 2026 9. Channel Discovery Channel discovery allows participants to learn which channels are available within a team. A designated device (or server) publishes channel metadata on a channel info track. Participants subscribe to this namespace to present users with a list of channels they can join. 9.1. Channel Info Namespace Channel discovery tracks use the namespace tuple: ("mocha_v1", , , "channel_info", ) For example: ("mocha_v1", "example.com", "acme", "channel_info", "engineering") 9.2. Channel Info Track Names Each device (or server) that creates or manages channels publishes channel information on a track: channel_ For example: Namespace: ("mocha_v1", "example.com", "acme", "channel_info", "engineering") Track Name: "channel_admin-server-1" 9.3. Channel Info Object Format Objects on channel info tracks contain the names and metadata of channels available in the team: Jennings & Nandakumar Expires 7 January 2027 [Page 15] Internet-Draft mocha-chat July 2026 { "channels": [ { "channel_id": "general", "name": "#general", "topic": "General discussion", "type": "public" }, { "channel_id": "backend", "name": "#backend", "topic": "Backend engineering", "type": "public" }, { "channel_id": "secret-project", "name": "#secret-project", "type": "private" } ] } 10. Availability MOCHA provides an availability system for communicating user availability and status within a channel. Channel membership implicitly grants availability visibility — all channel members can see each other's availability without explicit subscription consent. 10.1. Availability Namespace Availability tracks for a channel use the namespace tuple: ("mocha_v1", , , "availability", , , ) HClientID is derived per Section 3.1. 10.2. Availability Track Names Each device publishes its availability on a dedicated track: availability_v1_ HDevID is derived per Section 3.1. Jennings & Nandakumar Expires 7 January 2027 [Page 16] Internet-Draft mocha-chat July 2026 10.3. Availability States +=========+=========================================+ | State | Description | +=========+=========================================+ | online | User is active and available | +---------+-----------------------------------------+ | away | User is idle or stepped away | +---------+-----------------------------------------+ | dnd | Do not disturb — suppress notifications | +---------+-----------------------------------------+ | offline | User is disconnected | +---------+-----------------------------------------+ Table 3 10.4. Availability Object Format Each object on an availability track contains: { "status": "online", "status_message": "In meetings until 3pm", "last_active": 1715790000000, "idle_seconds": 0 } Fields: * *status*: One of the availability states above. * *status_message*: Optional human-readable status text. * *last_active*: NTP timestamp (milliseconds) of last user activity. * *idle_seconds*: Seconds since last user interaction on this device. Set to 0 when active. 10.5. Availability Updates A device publishes a new availability object whenever its state changes (e.g., user becomes idle, changes status, or goes offline). Each new object replaces the previous state. Devices SHOULD publish an availability object with status "offline" when gracefully disconnecting. If a device disconnects without publishing an offline status, subscribers detect the absence via track inactivity. Jennings & Nandakumar Expires 7 January 2027 [Page 17] Internet-Draft mocha-chat July 2026 10.6. Typing Indicators Typing indicators are ephemeral availability signals scoped to a channel. They use the same availability namespace with a separate track: typing_v1_ 10.6.1. Typing Object Format { "is_typing": true, "thread_id": null, "ts": 1715790000000 } Typing indicators: * SHOULD be delivered via QUIC datagrams (unreliable) for low latency. * SHOULD timeout after 5 seconds without an update. * MAY be disabled per-user or per-channel. 10.7. Subscribing to Availability Participants subscribe (SUBSCRIBE_NAMESPACE) to the availability namespace to receive availability and typing updates from all channel members. This follows the same pattern as roster subscription — joining a channel implicitly subscribes the device to availability. 11. Security Considerations TODO 12. IANA Considerations 12.1. MOCHA_COMPRESSION Track Property This document requests IANA registration of the MOCHA_COMPRESSION track property in the "MoQ Track Properties" registry (if established by [MoQTransport]). Property Name: MOCHA_COMPRESSION Property Type: Track Property Jennings & Nandakumar Expires 7 January 2027 [Page 18] Internet-Draft mocha-chat July 2026 Value Type: Varint Description: Signals the compression algorithm applied to all objects on a MOCHA message track. Reference: This document, Section 4.2 12.2. MOCHA Compression Algorithms Registry This document establishes a new "MOCHA Compression Algorithms" registry with the following initial entries: +=======+===========+===============+ | Value | Algorithm | Reference | +=======+===========+===============+ | 0 | None | This document | +-------+-----------+---------------+ | 1 | GZIP | [RFC1952] | +-------+-----------+---------------+ | 2 | Brotli | [RFC7932] | +-------+-----------+---------------+ Table 4 New entries require Specification Required (per [RFC8126]). 13. References 13.1. Normative References [JSON] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [MOCHA] "*** BROKEN REFERENCE ***". [MOCHA-ARCH] "*** BROKEN REFERENCE ***". [MOCHA-IDENTITY] "*** BROKEN REFERENCE ***". Jennings & Nandakumar Expires 7 January 2027 [Page 19] Internet-Draft mocha-chat July 2026 [MoQTransport] Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet- Draft, draft-ietf-moq-transport-18, 12 May 2026, . [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7932] Alakuijala, J. and Z. Szabadka, "Brotli Compressed Data Format", RFC 7932, DOI 10.17487/RFC7932, July 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 13.2. Informative References [MIMI-CONTENT] Mahy, R., "More Instant Messaging Interoperability (MIMI) Content Format", 2024, . Authors' Addresses Cullen Jennings Cisco Email: fluffy@iii.ca Suhas Nandakumar Cisco Email: snandaku@cisco.com Jennings & Nandakumar Expires 7 January 2027 [Page 20]