MIMI Terminology

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 13 October 2023.¶

Copyright Notice

Copyright (c) 2023 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

The More Instant Messaging Interoperability (MIMI) working group is chartered to specify the minimal set of mechanisms to make modern instant messaging applications interoperable. Through prior discussions and upcoming documents, it's become important to have a shared understanding for what is being discussed specifically.¶

This document expands upon MLS's [I-D.ietf-mls-protocol] [I-D.ietf-mls-architecture] terminology by defining terms specific to MIMI's purpose. Document authors SHOULD prefix terms from the MLS specification with "MLS" to denote that the term is specifically coming from the MLS specification. For example, "MLS Group" versus "Group". This document defines terms which are non-conflicting to help ensure clarity when the MLS prefix is missing, however.¶

Documents within the MIMI working group may introduce their own terminology to explain concepts within their context. Those documents SHOULD NOT override or change the terminology described in this document or from MLS.¶

2. Terminology

MIMI defines:¶

User: A (normally) human operator of a client. Users have a User ID to identify them canonically within the system.¶

Client: A user interface for messaging, performing encryption as needed. Presents conversations to the user to interact with. Synonymous with MLS Client. Clients have a Client ID to canonically identify them among a user's other clients.¶

Conversation: The place where users communicate. Depending on design, this may be synonymous with an MLS Group. The default assumption if not clarified is that the conversation and group are different concepts/entities. Conversations have a Conversation ID to canonically identify them within the system, which may be a Group ID if the concepts are synonymous.¶

Conversation Member: A user's membership in relation to a conversation. If the concepts of conversation and MLS Group are synonymous, this will be no different than an MLS Member, however if different then this will be which represents the MLS Member to the conversation.¶

Event: The container for an encrypted MLS Message, sent over the wire between servers and clients (through their local servers). Events have an Event ID to canonically identify them at least within the conversation.¶

Conversation Property: Information stored in the conversation, such as the name, topic, avatar, conversation membership, etc. This may be in the shape of an event. Note that conversation properties are different from what is needed to construct an MLS Group Context.¶

Message: Synonymous with an MLS Message. Messages have a Message ID to canonically identify them at least within the group.¶

Server: Synonymous with an MLS Delivery Service (DS). Responsible for routing events to other servers and local clients. Note that the role of a server can be accomplished in the same logical place as a client (i.e.: in peer-to-peer environments), however the default assumption if not clarified is that the client and server are two different entities.¶

Client-Server API: The interface between a client and server. This may be nothing more than a function call if the client and server are the same logical entity.¶

Server-Server API: The interface between a server and another server.¶

Transport: The method and format for moving information between entities. For example, a Client-Server API might describe HTTPS and JSON as its transport. For added clarity, documents should clarify which API surface they are defining a transport for ("Server-Server Transport", for example).¶

Access Control: The set of algorithms which determine whether an event or MLS Message is permitted in the conversation/group. For instance, this may define whether an MLS Proposal is accepted or whether the user is able to become a conversation member.¶

Message Format: The specific format that clients use within the encrypted body of an MLS Message. Sometimes this will also be called the Content Format.¶

User Identity: A mapping of User ID to external identifier, such as a phone number. In some cases, the user identity can be synonymous with the user ID, however the default assumption if not clarified is that they are different concepts.¶

Messaging Provider or Provider: A service offering instant messaging to users. Typically a provider will have a server to route events between users (or clients, specifically).¶

3. IANA Considerations

This document has no IANA actions.¶

Author's Address