Internet-Draft VCON for MIMI October 2024
Mahy Expires 24 April 2025 [Page]
Workgroup:
Virtualized Conversations
Internet-Draft:
draft-mahy-vcon-mimi-messages-00
Published:
Intended Status:
Informational
Expires:
Author:
R. Mahy
Rohan Mahy Consulting Services

VCON for MIMI Messages

Abstract

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

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/vcon-mimi-messages/draft-mahy-vcon-mimi-messages.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mahy-vcon-mimi-messages/.

Discussion of this document takes place on the Virtualized Conversations Working Group mailing list (mailto:vcon@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/vcon/. Subscribe at https://www.ietf.org/mailman/listinfo/vcon/.

Source for this draft and an issue tracker can be found at https://github.com/rohanmahy/vcon-mimi-messages.

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 24 April 2025.

Table of Contents

1. Introduction

VCON [I-D.ietf-vcon-vcon-container] is a format for recording and transmitting conversations. MIMI content [I-D.ietf-mimi-content] is a format for conveying Instant Messages in an interoperable way when end-to-end encrypted. This document describes a way to translate a set of MIMI messages in a conversation or part of a conversation into a VCON.

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.

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

3.1. Room information

This document adds a 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.

3.2. Parties

The parties array MUST contain all the participants who were in the conversation at any point in time during the period represented by the VCON.

This document adds a new party_object_type: imUri. It is mandatory. The name field is optional. The role indicates the MIMI role and is optional.

3.3. Extensions to the dialog object

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 parties array consist of the party indexes of those who were active participants when the message was sent. The originator is set to the parties index of the sender of the message.

  • messageId is the base64url encoding of the MIMI content messageId. It is mandatory.

  • replaces is the base64url encoding of the MIMI content messageId of the message this message replaces. It is optional if empty.

  • expires is the expiration date/time of the message expressed as a VCON (text) date_type. It is optional if empty.

  • inReplyTo is the base64url encoding of the MIMI content messageId of the message to which this message is replying (or reacting). It is optional if empty.

  • lastSeen is an array of base64url-encoded message ids. It is mandatory.

  • mimiExtensions is a object (map) containing MIMI extensions. It is optional.

VCON typically expresses content using the body, encoding, and mimetype fields. In order to preserve this convention we use these fields directly for a MIMI SinglePart structure, but use new MultiPart and ExternalPart structure for those MIMI structures.

ExternalPart has several fields for the decryption and integrity of the referenced content. These can be omitted once the content has been downloaded, decrypted, verified, and included in the VCON attachments array.

  • disposition - optional if set to the default value ("render")

  • language - optional if absent

  • partIndex is an integer. It is mandatory

3.4. MultiPart

  • partSemantics is one of "chooseOne", "singleUnit", or "processAll". It is mandatory.

  • parts is an array of Parts. It is mandatory.

3.5. ExternalPart

  • mimetype (contentType in MIMI). optional but recommended.

  • url is the URL of the content as a text string. mandatory

  • expires is a date_type (text) date. optional.

  • size is an integer number of octets. optional.

  • description is a text string. optional.

  • filename is a text string. optional.

These encryption/validation related fields can be omitted once the content is available locally as an attachment. All of them are base64url encoded strings. Otherwise they are mandatory if present in the MIMI content.

TODO: how to represent a downloaded and decrypted object in attachments?

3.6. Part

  • disposition - optional if set to the default value ("render")

  • language - optional if absent

  • partIndex is an integer. It is mandatory

  • cardinality is one of "nullpart", "single", "external", or "multi". mandatory.

if cardinality is "single", then body, encoding, and mimetype fields are included directly in the Part object.

3.7. Changes to the room

Changes to the room metadata or participation should be accompanied by a new dialog type:

  • room metadata changes

  • participants joining and leaving

  • participants adding new clients

  • moderation events?

TODO

3.8. party_event_type events

party_event_type.event /= "add" / "welcome" / "leave" / "remove" / "ban"
  • add: user added herself directly

  • welcome: user added by someone else

  • leave: user leaves of their own accord

  • remove: user is removed by another user

  • ban: user is banned from the group

4. Examples

Will fill in after the draft deadline.

5. Security Considerations

TODO Security

6. IANA Considerations

This document has no IANA actions.

7. Normative References

[I-D.ietf-mimi-content]
Mahy, R., "More Instant Messaging Interoperability (MIMI) message content", Work in Progress, Internet-Draft, draft-ietf-mimi-content-04, , <https://datatracker.ietf.org/doc/html/draft-ietf-mimi-content-04>.
[I-D.ietf-vcon-vcon-container]
Petrie, D. and T. McCarthy-Howe, "The JSON format for vCon - Conversation Data Container", Work in Progress, Internet-Draft, draft-ietf-vcon-vcon-container-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-vcon-vcon-container-01>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

Acknowledgments

TODO acknowledge.

Author's Address

Rohan Mahy
Rohan Mahy Consulting Services