]> Rohan Mahy Consulting Services

rohan.ietf@gmail.com

Applications and Real-Time Virtualized Conversations instant messaging message history This document describes extensions to the Virtualized Conversation (VCON) syntax for instant messaging systems using the More Instant Messaging Interoperability (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 . Discussion of this document takes place on the Virtualized Conversations Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction VCON is a format for recording and transmitting conversations. MIMI content is a format for conveying Instant Messages in an interoperable way when end-to-end encrypted. This document extends VCON, describing a way to translate a set of MIMI messages in a conversation or part of a conversation into a VCON.

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. The examples in this document may contain base64url encoded values that have extra whitespace added for readability, and to conform with Internet-Draft formatting conventions. That whitespace should be ignored. Some metadata about a MIMI content message is conveyed in the encryption protocol Messaging Layer Security (MLS) or in the MIMI protocol . For example, the sender, recipient, date, and message ID are not mandatory fields in a MIMI content message. The recipient is the MIMI room ID associated with the corresponding MLS group. The participants in the group are calculated from the MLS group state and MIMI participant list during the MLS "epoch" in which the message was sent. The sender is conveyed in MLS. The MIMI "Hub" received timestamp is conveyed in the MIMI protocol. The MIMI content message ID is constructed by hashing fields from the MIMI content, and the sender and room URIs (see ). The names of the parties comes from the participant list defined in , while the room metadata described in this document comes from {Section 7.6 of !I-D.ietf-mimi-protocol}}. When message franking is enabled, as defined in , the franking_tag is conveyed in the MLS message's Additional Authenticated Data (AAD) field, while the MIMI protocol conveys the Frank structure generated by the MIMI Hub.

Syntax A MIMI conversation (or portion thereof) is represented in VCON with a mandatory list of parties and dialogs, a new top-level room object, and optionally attachment objects.

Room information This document adds a mandatory, top-level room object. It contains metadata known about the room at the start of the VCON period.

• id is the MIMI room ID URL. It is mandatory.
• name is the textual name of the room. It is optional.
• avatar is a URL referencing the room image. It is optional.
• subject is the room subject. It is optional.
• mood is the room mood. It is optional
• description is an array of room_description objects. It is optional. Each object can contain:
  • a type- a media type or an empty string. It is optional. It's default value is text/plain;charset=UTF-8.
  • a lang - a Language-tag as defined by . It is optional.
  • a content - if the type begins with "text/" or is empty, the content the is UTF-8 text description of the room. Otherwise it is the base64url encoding of whatever type is described. The content field is mandatory in a room_description object.

Parties The parties array MUST contain all the participants that initiated any event in the dialog events array. It SHOULD contain all the participants that were in the participant list at any point in time during the period represented by the VCON. For example, in very large groups, it may not be necessary to include every participant that took no action. The first party in the array is the MIMI room URI. This document adds a new party_object_type: im_uri. It is mandatory. The name field is optional. The role indicates the MIMI role and is optional. The document also adds a thumbprint party_object_type, which is the JWK thumbprint of the public key of the party. If there are multiple parties (clients) with the same im_uri then the thumbprint is required, otherwise it is optional.

The dialog object (text type) The following section refers to changes and additions to the dialog object when the type field is "text".

Semantics of the existing fields for text The dialog object consists of an array of instant messages of type "text". The start time is set to the hub received timestamp when available. The duration is zero. The originator is set to the parties index of the sender of the message. The message_id is the base64url encoding of the MIMI content message ID. It is mandatory. The first MIMI message represented in a MIMI VCON should contain the complete list of parties who were participants in the room at that time. For subsequent messages, a parties array consisting of index zero, indicates the recipients of the message are the active participants of the room. Changes to the roster can be tracked if party_history is present for those changes (see ).

Extensions to the dialog object for text The parties array consists of the party indexes of those who were active participants when the message was sent, or zero to indicate the current membership of the room.

• salt is the base64url encoding of the MIMI content salt. It is mandatory.
• replaces is the base64url encoding of the MIMI content message_id of the message this message replaces. It is optional if empty.
• topic_id is the base64url encoding of the MIMI topic_id. It is optional if empty.
• expires is present if not null in MIMI. It contains a non-extensible object with the following items:
  • relative is a boolean that is true if the time is expressed relative to the recipient read time, and false if it is expressed as an absolute date/time. It is mandatory when expires is present.
  • relative_time is an integer number of seconds. If relative is true, once the message has been read, the client is expected to delete the message after relative_time seconds. It is mandatory if relative is true and forbidden otherwise.
  • absolute_time is the expiration date/time of the message expressed as a VCON (text) date_type. It is mandatory if relative is false and forbidden otherwise.
• in_reply_to is the base64url encoding of the MIMI content message_id of the message to which this message is replying (or reacting). It is optional if empty.
• mimi_extensions is a base64 encoding of the CBOR MIMI content extensions map or null. It is optional if not present in the MIMI content.
• franking_tag is a base64url encoding of the MIMI franking_tag, or null. It is optional if not present.
• frank is a base64url encoding of the MIMI protocol Frank TLS struct, or null. It is optional if not present.
• disposition - optional if set to the default value ("render"). Refers to the overall disposition of the entire message.
• language - optional if absent. Refers to the language of the entire message.

VCON typically expresses message content using the body, encoding, and mediatype fields. In order to preserve this convention we use these fields directly for a MIMI SinglePart structure, but use new multi_part and external_part objects for the MultiPart and ExternalPart MIMI structures, respectively. If the message contains a single MIMI ExternalPart, the dialog object contains an external_part object. If the message contains multiple parts (a MIMI MultiPart), the dialog object contains a multi_part object. If there is only a single part in the message, there is no Part object. The part has a virtual part_index of 0, which is not transmitted. A MIMI message with a NullPart has no body, encoding, or mediatype fields.

external_part objects The external_part object can contain the following fields with similar meanings to those in MIMI content, with exceptions noted below.

• mediatype is the value of the contentType in MIMI. It is mandatory if present in the MIMI message and recommended otherwise. No mediatype is present in the dialog object.
• url is the URL of the content as a text string. It is mandatory
• expires is a date_type (text) date. It is optional if not present.
• size is an integer number of octets. It is optional if not present.
• description is a text string. It is optional if not present.
• filename is a text string. It is optional if not present.
• content_hash is the base64url encoded string of the MIMI contentHash of the ExternalPart, prefixed with the name of the hash algorithm corresponding to hashAlg and a colon (for example "sha256:"). content_hash is mandatory if it was included in the MIMI content ExternalPart, and omitted otherwise.

In addition, the following fields are unique to MIMI VCON.

• cached is a boolean. It is mandatory if it is true, which means that a copy of the external content is available in a vcon attachment object (see ). If cache is true and no content_hash is present, a new content hash is calculated for the attachment and placed the cache_ref field (which can only be present in this case).

external_part has several fields for the decryption of the referenced content. If it is not necessary to reconstruct the original MIMI content (for example to allow later verification of the message ID), these fields can be omitted once the content has been downloaded, decrypted, verified, and included in the VCON attachments array. Otherwise they are mandatory if present in the MIMI content. All of these fields are base64url encoded strings.

• enc_alg
• key
• nonce
• aad

multi_part objects A multi_part object is designed to carry multiple items, as with the MultiPart structure in MIMI content or the top level multipart media types. It contains the following fields.

• part_semantics is one of "chooseOne", "singleUnit", or "processAll". It is mandatory.
• parts is an array of Part objects. It is mandatory in a multi_part object.

Part objects The following fields can be in a Part object. They have the same meaning as their MIMI content counterparts.

• disposition optional if set to the default value ("render"). It refers to a specific part.
• language - optional if absent. It refers to a specific part.
• part_index is an unsigned integer. It is mandatory.
• cardinality is one of "nullpart", "single", "external", or "multi". mandatory.

If cardinality is "single", then body, encoding, and mediatype fields are included directly in the Part object. If cardinality is "external" or "multi", an external_part or multi_part object is included, respectively.

Changes to the parties The party_history object can be interleaved with text objects in the dialog objects array. It indicates when changes have been made to the participants represented by party index zero, as well as properties of individual parties (such as their role or name). The party_history object contains the following fields.

• party is the party index of the modified party. It is mandatory.
• originator is the party that originated the change. It is optional.
• time is the time that the change was effected
• event is the type of change. It is mandatory and for MIMI VCONs can be one of the following new event types:
  • add: user added by someone else
  • self_add: user added herself directly
  • leave: user leaves of their own accord
  • remove: user is removed by another user
  • ban: user is banned from the group
  • update: user or client is updated
  • room: room metadata was updated
• name is the new name of the user. It is only permitted for an update event.
• role is the new role assigned to the user. It is only permitted for an update event.
• room is a new room object containing the new room metadata. It is only permitted for an event of type room.

The updated room object can contain anything in the top-level room object except for the id field (which MUST NOT be present). When the room metadata is changed, the party field is set to 0.

Attachments An attachment consists of the following fields:

• start: is the time when the attachment was downloaded. It is mandatory.
• party: is the party that downloaded the attachment. It is mandatory.
• content_hash: is the base64url encoded hash using the hash name prefixed with a colon before the hash (ex: "sha256:"). It is mandatory.
• dialog_object_ref is a string consisting of: "mid:" (representing the message ID URI), the message_id of the message in the dialog object, a colon, the part_index of the Part (or "0" if the ExternalPart is at the top level), and the string "@anon.invalid"

The mediatype, filename, encoding, and body fields are as they are defined in VCON and are all mandatory.

Message tombstones When a message has been deleted/retracted, or it expires, it can be valuable to present a record that such a message was previously present, by generating a dialog object with the following fields (which are all mandatory):

• type is "tombstone"
• start is the time the tombstone was generated
• message_id is the message ID of the message.
• status is the status of the former message, either "retracted" or "expired".

Examples

MIMI examples as a VCON The example vcon consists of the example messages from Section 5 of the MIMI content specification plus a party_history object adding two new participants, and a single multipart message at the end.

MIMI VCON with an Attachment This example vcon consists of a single message in a dialog which references an attachment.

Security Considerations TODO Security

IANA Considerations This document requests IANA to add following entries under the relevant registries in the vCon JSON Objects Group. IANA, please replace RFCXXXX with the number of this document.

vCon Object Parameter Names Registry

Name	Description	Change Control	Reference
room	metadata about an instant messaging room or channel	IETF	of RFCXXXX

Room object registry

Name	Description	Change Control	Reference
id	room ID	IETF	RFCXXXX
name	The human-readable name of the room	IETF	RFCXXXX
avatar	An image associated with the room	IETF	RFCXXXX
subject	The subject of the room	IETF	RFCXXXX
mood	The mood of the room	IETF	RFCXXXX
description	The description of the room	IETF	RFCXXXX

Room description object registry This documents creates a new Room description object registry under the vCon JSON Objects Group. It has the following values.

Name	Description	Change Control	Reference
type	an optional media type of the description	IETF	RFCXXXX
lang	the language of the description	IETF	RFCXXXX
content	the content of the description	IETF	RFCXXXX

Party object

Name	Description	Change Control	Reference
im_uri	The URI of an instant messaging users or room	IETF	RFCXXXX
role	The role of an instant messaging user	IETF	RFCXXXX
thumbprint	The public key thumbprint of an instant messaging client	IETF	RFCXXXX

Dialog Type Name Registry

Name	Description	Change Control	Reference
tombstone	a placeholder for an no longer available message (ex: deleted, expired)	IETF	RFCXXXX

Dialog object types

Name	Description	Change Control	Reference
salt	The message salt	IETF	RFCXXXX
replaces	The message_id of another message this message replaces	IETF	RFCXXXX
expires	When this message expires	IETF	RFCXXXX
in_reply_to	The message_id of another message to which this message replies or reacts	IETF	RFCXXXX
mimi_extensions	A map of any mimi_extensions associated with this message	IETF	RFCXXXX
franking_tag	The sender-asserted franking_tag	IETF	RFCXXXX
frank	The frank data structure returned by the MIMI server with the message	IETF	RFCXXXX
disposition	The disposition of the message content	IETF	RFCXXXX
language	The language of the message content	IETF	RFCXXXX
status	The status of a former message	IETF	RFCXXXX
multi_part	A multi_part object containing the content	IETF	RFCXXXX
external_part	An external_part object referencing out-of-band content	IETF	RFCXXXX

external_part object type This documents creates a new External_part object registry under the vCon JSON Objects Group. It has the following values.

Name	Description	Change Control	Reference
mediatype	the media type of the externally referenced content	IETF	RFCXXXX
url	the url of the externally referenced content	IETF	RFCXXXX
size	the size in bytes of the externally referenced content	IETF	RFCXXXX
description	the description of the externally referenced content	IETF	RFCXXXX
filename	the filename of the externally referenced content	IETF	RFCXXXX
content_hash	a representation of the MIMI contentHash and hashAlg of the externally referenced content	IETF	RFCXXXX
cached	whether the referenced content is cached	IETF	RFCXXXX
enc_alg_	the encryption algorithm used to encrypt the externally referenced content	IETF	RFCXXXX
key	the encryption key of the externally referenced content	IETF	RFCXXXX
nonce	the encryption nonce of the externally referenced content	IETF	RFCXXXX
aad	the media type of the externally referenced content	IETF	RFCXXXX

multi_part object type This documents creates a new Multi_part object registry under the vCon JSON Objects Group. It has the following values.

Name	Description	Change Control	Reference
part_semantics	How multiple parts in the same multi_part object are handled	IETF	RFCXXXX
parts	An array of part objects	IETF	RFCXXXX

part object type This documents creates a new Part object registry under the vCon JSON Objects Group. It has the following values.

Name	Description	Change Control	Reference
disposition	The disposition of the message part	IETF	RFCXXXX
language	The language of the message part	IETF	RFCXXXX
part_index	The relative index of the part within the message	IETF	RFCXXXX
cardinality	one of "nullpart", "single", "external", or "multi"	IETF	RFCXXXX
mediatype	The media type of the part	IETF	RFCXXXX
encoding	The encoding of the message part (as in Section 2.3.1 of )	IETF	RFCXXXX
body	The content of the message part	IETF	RFCXXXX
multi_part	A multi_part object containing more parts of the content	IETF	RFCXXXX
external_part	An external_part object referencing out-of-band content	IETF	RFCXXXX

party_history object type

Name	Description	Change Control	Reference
originator	which party index initiated this party_history event	IETF	RFCXXXX
name	the name of the party that initiated this party_history event	IETF	RFCXXXX
role	the role of the party that initiated this party_history event	IETF	RFCXXXX
room	a room object containing updated room metadata	IETF	RFCXXXX

party_event object type

Name	Description	Change Control	Reference
add	indicates the party was added by someone else	IETF	RFCXXXX
self_add_	indicates the party was added by itself	IETF	RFCXXXX
leave	indicates the party left of their own accord	IETF	RFCXXXX
remove	indicates the party was removed by someone else	IETF	RFCXXXX
ban	indicates the party was banned	IETF	RFCXXXX
update	indicates the party changed	IETF	RFCXXXX
room	indicates room metadata changed	IETF	RFCXXXX

attachment object type

Name	Description	Change Control	Reference
dialog_object_ref	the message_id of the dialog object referencing this attachment	IETF	RFCXXXX

Normative References SIPez LLC vCon is a standardized framework for the exchange of conversational data. Conversations, which may involve one or more participants, occur across a wide variety of modes and application platforms. This document defines a JSON format for representing conversational data, encompassing metadata, conversation media, related documents, and analysis. The goal of this standard is to provide an abstracted, platform-independent data format for conversations, regardless of the mode or application platform. By doing so, it facilitates the integration and seamless exchange of conversational data across application platforms, enterprises, and trust boundaries. 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. 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. Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. Cisco The Matrix.org Foundation C.I.C. Phoenix R&D Rohan Mahy Consulting Services The Matrix.org Foundation C.I.C. Phoenix R&D This document specifies the More Instant Messaging Interoperability (MIMI) transport protocol, which allows users of different messaging providers to interoperate in group chats (rooms), including to send and receive messages, share room policy, and add participants to and remove participants from rooms. MIMI describes messages between providers, leaving most aspects of the provider-internal client- server communication up to the provider. MIMI integrates the Messaging Layer Security (MLS) protocol to provide end-to-end security assurances, including authentication of protocol participants, confidentiality of messages exchanged within a room, and agreement on the state of the room. This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

JSON Schema TODO

Change list

Changes in draft-ietf-vcon-mimi-messages-00

• adopted as a WG item
• added IANA registrations under the new framework
• fixed an inconsistency with disposition and language tags not consistent with MIMI content
• including all parties in the participant list is now a SHOULD
• room metadata changes are now expressed as a party_history event
• expires is not not present unless it was present in MIMI. Only either absolute_time or relative_time is allowed.
• updated references
• refactor to use the new message_id field name from core
• more case adjustments

Changes in draft-mahy-vcon-mimi-messages-02

• adjust to make consistent with new syntax of MIMI content (add salt, removed lastSeen, in_reply_to is just a message id, expires is an object to handle relative expiration, added mimi_extensions).
• use a different field from content_hash when attaching an ExternalPart that did not have a hash in the MIMI message.
• allow the parties list of 0 to indicate sending to every active participant in the room.
• added a description of using party_history to track changes to the participant list.
• added room metadata, and a way to modify it
• added support for message "tombstones"
• use mediatype instead of mimetype throughout
• make the case of field names more consistent

Acknowledgments TODO acknowledge.