More Instant Messaging Interoperability R. Mahy Internet-Draft 4 July 2025 Intended status: Informational Expires: 5 January 2026 A Message Status format for the More Instant Messaging Interoperability (MIMI) content format draft-mahy-mimi-message-status-00 Abstract The More Instant Messaging Interoperability (MIMI) content format describes a message format for instant messaging. This specification defines a concise, efficient format for communicating status of messages sent using MIMI content. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://rohanmahy.github.io/mimi-message-status/draft-mahy-mimi- message-status.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mahy-mimi-message- status/. Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (mailto:mimi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mimi/. Subscribe at https://www.ietf.org/mailman/listinfo/mimi/. Source for this draft and an issue tracker can be found at https://github.com/rohanmahy/mimi-message-status. 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/. Mahy Expires 5 January 2026 [Page 1] Internet-Draft MIMI Message Status July 2025 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 Internet-Draft will expire on 5 January 2026. Copyright Notice Copyright (c) 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Delivery Reporting and Read Receipts . . . . . . . . . . . . 3 4. Formal Data Definition . . . . . . . . . . . . . . . . . . . 4 5. Message Status Format Example . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7.1. MIME subtype registration of application/ mimi-message-status . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This document describes the semantics of a status report of MIMI content format [I-D.ietf-mimi-content] messages. Because some messaging systems deliver messages in batches and allow a user to mark several messages read at a time, the report format allows a single report to convey the read/delivered status of multiple messages (by message ID) within the same MIMI room at a time. This specification defines a concise, efficient format for communicating status of messages sent using MIMI content. It could also represent messages sent using other messaging formats that have similar per- Mahy Expires 5 January 2026 [Page 2] Internet-Draft MIMI Message Status July 2025 message unique message IDs and security characteristics. 2. Conventions and Definitions 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. This document uses the term "room" as defined in [I-D.ietf-mimi-arch]. 3. Delivery Reporting and Read Receipts In instant messaging systems, read receipts typically generate a distinct indicator for each message. In some systems, the number of users in a group who have read the message is subtly displayed and the list of users who read the message is available on further inspection. Of course, Internet mail has support for read receipts as well, but the existing message disposition notification mechanism defined for email in [RFC8098] is completely inappropriate in this context: * notifications can be sent by intermediaries * only one notification can be sent about a single message per recipient * a human-readable version of the notification is expected * each notification can refer to only one message * it is extremely verbose Instead, we would like to be able to include status changes about multiple messages in each report, the ability to mark a message delivered, then read, then unread, then expired for example. The format, like the MIMI content format, uses Common Binary Object Representation (CBOR) [RFC8949] encoding. It has the media type application/mimi-message-status. It is sent by individual members of a chat room and can refer to multiple messages sent in the same room in a single message. The format contains a list of message ID / status pairs. As the status at the recipient changes, the status can be updated in subsequent notification. Mahy Expires 5 January 2026 [Page 3] Internet-Draft MIMI Message Status July 2025 The status of each message can be one of the following values: * 0 (unread) indicates that the message was not yet read by the sender of the report. * 1 (delivered) indicates that a messaging client of the sender of the report received the message. * 2 (read) indicates that the sender of the report read the message. * 3 (expired) indicates that the message expired and is not available for reading. In the case of absolute expiration, it does not indicate if the message was read before its expiry. * 4 (deleted) indicates that the message was deleted, either by the local client, or by another member of the room with the power to retract messages. * 5 (hidden) indicates that the message was hidden by the local client (for example archived). * 6 (error) indicates that the sender client is aware of the message ID, but that there was an unspecified error with the reception of the message. Not every state is relevant for every type of message, and it does not make sense to transition from any one state to any other state. For example, a transition from deleted to delivered does not make sense. The implementer of this format needs to decide which state transitions are meaningful given their implementation and its available policy options. Depending on the policy of the room and a potential sender of delivery reports, sending delivery receipts and/or read receipt messages might be required, optional, or forbidden. Clients might also have policies about specific status values that are shared and others that are not. Some status values might only be shared among the reporting user's own clients, for example. 4. Formal Data Definition Below is the Concise Data Definition Language (CDDL) [RFC8610] definition for the message status format. Mahy Expires 5 January 2026 [Page 4] Internet-Draft MIMI Message Status July 2025 MessageStatusReport = [ * PerMessageStatus ] PerMessageStatus = [ messageId: MessageId, status: baseStatus / $extStatus / unknownStatus ] baseStatus = &( unread: 0, delivered: 1, read: 2, expired: 3, deleted: 4, hidden: 5, error: 6 ) unknownStatus = &( unknown: 7..255 ) MessageId = bstr .size 32 Figure 1: CDDL for MIMI message status format 5. Message Status Format Example The following example message assumes the sender user handle URL is mimi://example.com/u/bob-jones. It uses the example message names and message IDs from Section 5 of the MIMI content [I-D.ietf-mimi-content]. Mahy Expires 5 January 2026 [Page 5] Internet-Draft MIMI Message Status July 2025 [ [ / Original message / h'01b0084467273cc43d6f0ebeac13eb84 229c4fffe8f6c3594c905f47779e5a79', 2 / status = read / ], [ / Reply message / h'01a419aef4e16d43cfc06c28235ecfbe 9faebc740d0148e7ca20b22150930836', 2 / status = read / ], [ / Mention message / h'01cbc26869928fd13edf55ace00f9976 8ca4e62ad17fede45520eaca58f69d02', 0 / status = unread / ], [ / Expiring message / h'0106308e2c03346eba95b24abdfa9fe6 43aa247debfb7192feae647155316920', 3 / status = expired / ] ] Figure 2: Example message report A CBOR pretty printed hexadecimal version is shown below: Mahy Expires 5 January 2026 [Page 6] Internet-Draft MIMI Message Status July 2025 84 # array(4) 82 # array(2) 58 20 # bytes(32) d3c14744d1791d02548232c23d35efa9 7668174ba385af066011e43bd7e51501 02 # unsigned(2) 82 # array(2) 58 20 # bytes(32) e701beee59f9376282f39092e1041b2a c2e3aad1776570c1a28de244979c71ed 02 # unsigned(2) 82 # array(2) 58 20 # bytes(32) 6b50bfdd71edc83554ae21380080f4a3 ba77985da34528a515fac3c38e4998b8 00 # unsigned(0) 82 # array(2) 58 20 # bytes(32) 5c95a4dfddab84348bcc265a479299fb d3a2eecfa3d490985da5113e5480c7f1 03 # unsigned(3) 6. Security Considerations Delivery and Read Receipts can provide useful information inside a group, or they can reveal sensitive private information. In many IM systems there are per-group policies for read receipts (and/or delivery notifications): * they are required * they are permitted, but optional * they are forbidden In the first case, everyone in the group would have to claim to support read receipts to be in the group and agree to the policy of sending them whenever a message was read. A user who did not wish to send read receipts could review the policy (automatically or manually) and choose not to join the group. Of course, requiring read receipts is a cooperative effort just like using self-deleting messages. A malicious client could obviously read a message and not send a read receipt, or send a read receipt for a message that was never rendered. However, cooperating clients have a way to agree that they will send read receipts when a message is read in a specific group. Mahy Expires 5 January 2026 [Page 7] Internet-Draft MIMI Message Status July 2025 In the second case, sending a read receipt would be at the discretion of each receiver of the message (via local preferences). 7. IANA Considerations RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to this document. 7.1. MIME subtype registration of application/mimi-message-status This document proposes registration of a media subtype with IANA. Type name: application Subtype name: mimi-message-status Required parameters: none Optional parameters: none Encoding considerations: This message type should be encoded as binary data Security considerations: See Section A of RFC XXXX Interoperability considerations: See Section Y.Z of RFC XXXX Published specification: RFC XXXX Applications that use this media type: Instant Messaging Applications Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person & email address to contact for further information: IETF MIMI Working Group mimi@ietf.org 8. References Mahy Expires 5 January 2026 [Page 8] Internet-Draft MIMI Message Status July 2025 8.1. Normative References [I-D.ietf-mimi-arch] Barnes, R., "An Architecture for More Instant Messaging Interoperability (MIMI)", Work in Progress, Internet- Draft, draft-ietf-mimi-arch-01, 21 November 2024, . [I-D.ietf-mimi-content] Mahy, R., "More Instant Messaging Interoperability (MIMI) message content", Work in Progress, Internet-Draft, draft- ietf-mimi-content-06, 28 February 2025, . [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, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . 8.2. Informative References [RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, February 2017, . Author's Address Rohan Mahy Email: rohan.mahy@gmail.com Mahy Expires 5 January 2026 [Page 9]