More Instant Messaging Interoperability T. Ralston
Internet-Draft The Matrix.org Foundation C.I.C.
Intended status: Informational 9 June 2023
Expires: 11 December 2023
MIMI Terminology
draft-ralston-mimi-terminology-01
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 11 December 2023.
Ralston Expires 11 December 2023 [Page 1]
Internet-Draft MIMI Terminology June 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 . . . . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Normative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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 11 December 2023 [Page 2]
Internet-Draft MIMI Terminology June 2023
*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).
*User*: A (normally) human operator of a _client_. _Users_ have a
*User ID* to identify them canonically within the system.
*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.
*Client*: A user interface for messaging, performing encryption as
needed. Presents _chats_ 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_. _Clients_ can
additionally be called *Devices* to differentiate them from a named
application.
*Chat*: The place where _users_ communicate. This is semantically
distinct from an _MLS Group_: an _MLS Group_ is responsible for
handling _client_ keys while a _chat_ is simply the user-facing
construct for communication, however systems can declare a _chat_ to
be the same as an _MLS Group_ depending on their design. _Chats_ have
a *Chat ID* to canonically identify them within the system. _Chats_
can additionally be called *Rooms*, *Conversations*, and *Channels*.
A _chat_ can have any one of many different characterizations/
behaviours, called *Chat Types*:
* *DM*: A _direct message_ _chat_ between exactly two _users_. _DMs_
are typically created when a _user_ searches for another _user_ to
message, rather than creating a _group chat_. All _users_ in the
_chat_ have the same permission capabilities under the _access
control_ semantics. The _chat name_ is that of the opponent
_user_ in the _DM_. _DMs_ are typically canonical: exactly one
_chat_ with the opponent exists at a time.
* *Group DM*: A subtype of _DMs_ where there are more than two
_users_. The _chat name_ consists of the opponent _users_ in the
_DM_. Inherited from _DMs_, _Group DMs_ are also canonical:
creating a new _Group DM_ with the exact same _users_ ultimately
redirects to the existing _chat_ instead of creating a new one.
These may also be called *Ad-hoc Chats* in some scenarios.
* *Group Chat*: A _chat_ which requires an _invite_ to be able to
participate, and can have zero or more _users_. A _user_-provided
_chat name_ is defined for the _chat_. Typically, the creator has
Ralston Expires 11 December 2023 [Page 3]
Internet-Draft MIMI Terminology June 2023
_admin permissions_ while other designated _users_ have either
_admin permissions_ or _moderator permissions_. Most _users_ have
default permissions which allow them to send _events_ to the
_chat_. Unlike _(Group) DMs_, multiple _chats_ with the same set
of _users_ can exist at the same time, even with the same _chat
name_.
* *Public Chat*: A _group chat_ which does not require an _invite_
to participate. Usually these types of _chats_ are discovered
through a directory or website. _Chats_ which require a request to
join, or _knock_, are considered _public chats_. Sometimes these
will be referred to as *Public Chatrooms*.
* *Auditorium Chat*: Either a _group chat_ or _public chat_ where
most _users_ are unable to send _events_ and cannot be seen as
_chat members_ by other _users_. When an _event_ is sent, it may
appear to be sent by the _chat_ itself rather than the specific
_user_ who sent it. Sometimes these are called *Auditorium
Rooms*.
Depending on the system, a _chat's_ _type_ can be mutable. For
example, a _user_ may be permitted to introduce new _users_ to a
_group DM_ to implicitly convert it to a _group chat_, or they simply
may be unable to implicitly or explicity change the _chat type_.
*Chat Name*: The title or human-focused textually distinguishing
factor for the _chat_. It may be automatically generated based on the
_chat members_.
*Chat Avatar*: A picture or graphic associated with the _chat_,
usually in combination with a _chat name_. _Chat avatars_ can be
automatically generated based on the _chat members_.
*Chat Member*: A joined _user_ in the _chat_. Note that this may have
implications on the associated _MLS Members_ in the _MLS Group_ for
the _user's_ _devices_.
*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 _chat_.
*Chat Property*: Information stored in the _chat_, such as the name,
topic, avatar, _chat members_, etc. This may be in the shape of an
_event_. Note that _chat properties_ are different from what is
needed to construct an _MLS Group Context_.
Ralston Expires 11 December 2023 [Page 4]
Internet-Draft MIMI Terminology June 2023
*Message*: Synonymous with an _MLS Message_. _Messages_ have a
*Message ID* to canonically identify them at least within the
_group_. These are essentially what a _user_ would call a "message",
though specifically the unencrypted portion. When encrypted, they
are called _events_.
*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).
*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*.
*Access Control*: The set of algorithms which determine whether an
_event_ or _MLS Message_ is permitted in the _chat_/_group_. For
instance, this may define whether an _MLS Proposal_ is accepted or
whether the _user_ is able to become a _chat member_.
*Admin Permissions*: Typically at least the _user_ who created the
_chat_, these permissions grant the associated _users_ an ability to
change the permissions of other _users_ in the _chat_. The set of
_users_ with these permissions in a _chat_ are called *Admins*.
_Admin permissions_ inherit _moderator permissions_.
*Moderator Permissions*: These permissions grant the associated
_users_ an ability to _kick_, _ban_, or otherwise restrict another
_user's_ ability to use the _chat_. For example, deleting a spammer's
_events_. The set of _users_ with these permissions in a _chat_ are
called *Moderators*.
Ralston Expires 11 December 2023 [Page 5]
Internet-Draft MIMI Terminology June 2023
Note that with both _moderator permissions_ and _admin permissions_ a
system may have finer granularity, such as a set of _users_ being
able to _kick_ but not _ban_. Documents with these semantics should
clarify this case.
*Invite*: An action taken by a _user_ in a _chat_ to encourage
another _user_ to become a _chat member_ (or joined to the _chat_).
This can be explicit through the _server-server API_, or implicit
with an _invite code_.
*Invite Code*: An out-of-band _invite_ for a _user_ to join the
_chat_, such as a text string shared with the target _user_. The
sharing mechanism can additionally be a URL or QR code.
*Direct Invite*: An invite to a _DM_ or _Group DM_. These _invites_
might appear in a different section of the _client's_ UI to denote
their semantic difference from a non-_DM_ _invite_.
*Kick*: An action taken by a _user_ in a _chat_ to remove another
_user_, assuming the sender has _moderator permissions_. The affected
_user_ can re-join the _chat_ with either another _invite_ or by
simply joining, depending on the _chat type_.
*Ban*: Similar to _kicking_, a _user_ is _kicked_ from the room and
not allowed to re-join until _unbanned_ by a _moderator_. If a _user_
is _banned_, they are typically not able to _knock_ to get back into
the _chat_ either.
*Knock*: A request from a _user_ (who is not currently a _chat
member_) to participate in the _chat_. Upon acceptance, the
requesting _user_ may receive an _invite_ or be directly joined to
the _chat_. Upon rejection, the requesting _user_ can be _banned_ or
otherwise declined.
*Status*: Temporarily displayed text or images associated with a
_user's_ profile. Instagram Stories are an example of a _user's_
_status_.
2.1. Diagram Reference
In the simplest possible form, interoperable messaging between two
end users looks as such:
Ralston Expires 11 December 2023 [Page 6]
Internet-Draft MIMI Terminology June 2023
+----------+ +------------+ +------------+ +----------+
| | 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 A.
A is a provider-specific Client-Server API and transport. Similarly,
Client 2 is directly connected to Provider 2 over C. C is also a
provider-specific Client-Server API and transport.
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 method of communication (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>.
Ralston Expires 11 December 2023 [Page 7]
Internet-Draft MIMI Terminology June 2023
Author's Address
Travis Ralston
The Matrix.org Foundation C.I.C.
Email: travisr@matrix.org
Ralston Expires 11 December 2023 [Page 8]