MIMI Terminology
draft-ralston-mimi-terminology-00

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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mls-
              architecture-10>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-mls-
              protocol-20>.

Author's Address

   Travis Ralston
   The Matrix.org Foundation C.I.C.
   Email: travisr@matrix.org

Ralston                  Expires 13 October 2023                [Page 5]