A Message Status format for the More Instant Messaging Interoperability (MIMI) content format

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 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

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-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.¶

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.¶

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

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].¶

[
  [
    /  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 /
  ]
]

A CBOR pretty printed hexadecimal version is shown below:¶

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.¶

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.¶

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

Author's Address