More Instant Messaging Interoperability T. Ralston Internet-Draft The Matrix.org Foundation C.I.C. Intended status: Informational 11 April 2023 Expires: 13 October 2023 MIMI Terminology draft-ralston-mimi-terminology-00 Abstract This document introduces a set of terminology to use when discussing or describing concepts within MIMI. 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://turt2live.github.io/ietf-mimi-terminology/draft-ralston-mimi- terminology.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ralston-mimi-terminology/. Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (mailto:mimi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mimi/. Subscribe at https://www.ietf.org/mailman/listinfo/mimi/. Source for this draft and an issue tracker can be found at https://github.com/turt2live/ietf-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. Ralston Expires 13 October 2023 [Page 1] Internet-Draft MIMI Terminology April 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Diagram Reference . . . . . . . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 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: Ralston Expires 13 October 2023 [Page 2] Internet-Draft MIMI Terminology April 2023 *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. Ralston Expires 13 October 2023 [Page 3] Internet-Draft MIMI Terminology April 2023 *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). 2.1. Diagram Reference In the simplest possible form, interoperable messaging between two end users looks as such: +----------+ +------------+ +------------+ +----------+ | | A | | B | | C | | | Client 1 |<----->| Provider 1 |<----->| Provider 2 |<----->| Client 2 | | | | | | | | | +----------+ +------------+ +------------+ +----------+ ^ ^ | D | +-------------------------------------------------------------+ Figure 1: Typical, simplified, architecture for interoperability In this figure, Client 1 is directly connected to Provider 1 over channel A. A is a provider-specific Client-Server API and transport. Similarly, Client 2 is directly connected to Provider 2 over channel C. C is also a provider-specific Client-Server API and transport. Ralston Expires 13 October 2023 [Page 4] Internet-Draft MIMI Terminology April 2023 Provider 1 and 2 talk to each other with a Server-Server API over a transport. This is B in the figure. Clients additionally have an implicit channel (D in the figure) where they use a shared Message Format. There is no transport for D in this figure: the figure is denoting that servers/providers are unable to assist with a format conversion due to the event's content (an MLS message) being encrypted. 3. IANA Considerations This document has no IANA actions. 4. Normative References [I-D.ietf-mls-architecture] Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and A. Duric, "The Messaging Layer Security (MLS) Architecture", Work in Progress, Internet-Draft, draft- ietf-mls-architecture-10, 16 December 2022, . [I-D.ietf-mls-protocol] Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", Work in Progress, Internet- Draft, draft-ietf-mls-protocol-20, 27 March 2023, . Author's Address Travis Ralston The Matrix.org Foundation C.I.C. Email: travisr@matrix.org Ralston Expires 13 October 2023 [Page 5]