Internet DRAFT - draft-ralston-mimi-terminology
draft-ralston-mimi-terminology
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]
