]>

rohan.ietf@gmail.com

Cisco

fluffy@iii.ca

MIMI content extensions lastSeen sender timestamp outer message ID This document defines some new useful extensions for the MIMI content format. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction This document defines a set of new fields for the MIMI content format extensions map. These particular extensions were chosen to provide functionality already in some other messaging systems, so that they can carry this information safely with the MIMI content format.

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.

Sender Timestamp Extension This extension represents the sender asserted sending timestamp. It is a map containing the whole number of seconds since the start of the UNIX epoch, and optionally the number of additional milliseconds, microseconds, or nanoseconds. The Concise Data Definition Language (CDDL) description of the extension is below. { 1: uint, ? fractional } ) fractional = ( -3: millisecs // -6: microsecs // -9: nanosecs) millisecs = 0..999 microsecs = 0..999999 nanosecs = 0..999999999 TBD1 = 3 ; recommended value for IANA ]]>

External Message ID Extension While the MIMI content format has its own message ID derived from a hash of its content, many messaging systems already have a native message ID format. This extension allows this "external" message ID to also be included in the MIMI content extensions map. It consists of an array of two parts, a byte string for the native message ID, and a scope. The scope could be be an Internet domain name (represented as a text string), a tagged URI, or an IANA-registered Private Enterprise Number (PEN), which is a positive integer. The PEN option allows for a concise, but unambiguous scope in many organizations. The CDDL description is below. ExtMessageId ) ExtMessageId = [ bstr, scope ] scope = pen / domain / uri pen = uint .gt 0 ; IANA Private Enterprise Number domain = tstr ; Internet domain name TBD2 = 4 ]]>

Subject Extension The subject extension allows messaging systems which already have a Subject field to carry a text string of up to 4096 octets of legal UTF-8. The CDDL description is below. tstr .size (1..4096) ) TBD3 = 5 ]]>

Message Ordering via lastSeen The lastSeen data field indicates the latest message(s) the sender was aware of in the group. It is a list of MIMI message IDs, or a list of external message IDs. If the sender recently joined the group and has not yet seen any messages, the list is empty. If the sender identifies a single message as unambiguously the latest message in the group, the lastSeen list contains a single message id from that message. Imagine however that two users (Bob and Cathy) see a message from Alice offering free Hawaiian pizza, and reply at the same time. Bob and Cathy both send messages with their lastSeen including a single message id (Alice's message about pizza). Their messages don't need to be replies or reactions. Bob might just send a message saying he doesn't like pineapple on pizza. Now Doug receives all these messages and replies as well. Doug's message contains a lastSeen including the message id list of both Bob's and Cathy's replies, effectively "merging" the order of messages. The next message after Doug's message contains a lastSeen containing only the message id of Doug's message. The CDDL description is below. [ * MessageId ] / [ * ExtMessageId ] ) TBD4 = 256 ]]>

Security Considerations The Security Consideration of MIMI content apply. These extensions are most likely to be used for interoperability with messaging systems other than MIMI. The security of the MIMI content format needs to be considered in combination with the properties of the messaging system that carries the messages. The situations listed below are considered anomalies and could indicate a malicious sender. When they are encountered the receiver MAY reject the MIMI message. When the senderTimestamp extension:

• dates from before the start of the UNIX epoch,
• dates from before the first known message exchanged in the target messaging system,
• is from a time dramatically in the future (ex: hundreds of years), or
• jumps more than expected for the target messaging system. For example, a messaging system designed to deliver messages no more that one month old, could reject messages more than 32 days in the past or future.

• Note that occasionally out-of-order messages are a consequence of normal operations in most messaging systems.

When the externalMessageId extension:

• is a duplicate of another external message ID already encountered, or
• is from a completely unexpected scope.

When the subject extension:

• is not a string of legal UTF-8 characters.

When the lastSeen extension:

• is empty, but the sender has previously sent messages in the room,
• results in a loop,
• contains a mix of both native MIMI MessageId and external message IDs,
• contains external message IDs from a completely unexpected scope, or
• refers to an excessive number of lastSeen messages simultaneously (ex: contains more than 65535 message IDs).

• Note that a popular message sent in a large group can result in thousands of reactions in a few hundred milliseconds.

IANA Considerations IANA is requested to add the following entries to the MIMI Content Extension Keys registry.

senderTimestamp MIMI Content Extension Key The following completed registration template is provided:

• Key: TBD1 (suggested value 3)
• Name: senderTimestamp
• Type: map
• Recommended: N
• Reference: of this document

externalMessageId MIMI Content Extension Key The following completed registration template is provided:

• Key: TBD2 (suggested value 4)
• Name: externalMessageId
• Type: array of 2 items
• Recommended: N
• Reference: of this document

subject MIMI Content Extension Key The following completed registration template is provided:

• Key: TBD3 (suggested value 5)
• Name: subject
• Type: tstr
• Recommended: N
• Reference: of this document

lastSeen MIMI Content Extension Key The following completed registration template is provided:

• Key: TBD4 (suggested value 256)
• Name: lastSeen
• Type: array
• Recommended: N
• Reference: of this document

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Informative References Rohan Mahy Consulting Services This document describes content semantics common in Instant Messaging (IM) systems and describes a profile suitable for instant messaging interoperability of messages end-to-end encrypted inside the MLS (Message Layer Security) Protocol.

Complete CDDL Schema

A complete CDDL description of the new extensions { 1: uint, ? fractional } ) fractional = ( -3: millisecs // -6: microsecs // -9: nanosecs) millisecs = 0..999 microsecs = 0..999999 nanosecs = 0..999999999 $$otherKnownExtensions //= ( &(externalMessageId: TBD2) ^ => ExtMessageId ) ExtMessageId = [ bstr, scope ] scope = pen / domain / uri pen = uint .gt 0 ; IANA Private Enterprise Number domain = tstr ; Internet domain name $$otherKnownExtensions //= ( &(subject: TBD3) ^ => tstr .size (1..4096) ) $$otherKnownExtensions //= ( &(lastSeen: TBD4) ^ => [ * MessageId ] / [ * ExtMessageId ] ) TBD1 = 3 TBD2 = 4 TBD3 = 5 TBD4 = 256 ]]>