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

Introduction This document describes the semantics of a status report of MIMI content format 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.

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 when, and only when, they appear in all capitals, as shown here. This document uses the term "room" as defined in .

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

Formal Data Definition Below is the Concise Data Definition Language (CDDL) definition for the message status format.

CDDL for MIMI message status format

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 .

Example message report A CBOR pretty printed hexadecimal version is shown below:

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 (see ) 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).

IANA Considerations RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to this document.

MIME subtype registration of application/mimi-message-status This document proposes registration of a media subtype with IANA.