| Internet-Draft | MIMI Application State | December 2024 |
| Mahy | Expires 21 June 2025 | [Page] |
TODO Abstract¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://rohanmahy.github.io/mimi-app-components/draft-mahy-mimi-app-components.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mahy-mimi-app-components/.¶
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/rohanmahy/mimi-app-components.¶
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 21 June 2025.¶
Copyright (c) 2024 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.¶
TODO Introduction¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The Room Metadata component contains data about a room which might be displayed as human-readable information for the room, such as the name of a room and its room image/avatar.¶
RoomMetaData is the format of the data field inside the ComponentData struct for the Room Metadata component in the application_data GroupContext extension.¶
/* a valid URI (ex: MIMI URI) */
struct {
opaque uri<V>;
} Uri;
/* a sequence of valid UTF8 without nulls */
struct {
opaque string<V>;
} UTF8String;
struct {
Uri room_uri;
UTF8String room_name;
/* an https URI resolving to an avatar image */
Uri room_avatar;
UTF8String room_subject;
UTF8String room_mood;
} RoomMetaData;
RoomMetaData RoomMetaUpdate;
¶
RoomMetaUpdate (which has the same format as RoomMetaData) is the format of the update field inside the ApplicationDataUpdate struct in an ApplicationDataUpdate Proposal for the Room Metadata component.
If the contents of the update field are valid and if the proposer is authorized to generate such an update, the value of the update field completely replaces the value of the data field.¶
The Role-Based Access Control component contains a list of all the roles in the room, and the capabilities associated with them. It contains a role_index, which is used to refer to the role elsewhere. It also contains a role_name (a human readable text string name for the role), and a role_description (another string, which can have zero length).¶
Each Role also can contain constraints on the minimum and maximum number of participants, and the minimum and maximum number of active participants. If the minimum number is zero, there is no minimum number of participants for that particular role. If there is no maximum number of participants for a particular role, that parameter is absent.¶
RoleData is the format of the data field inside the ComponentData struct for the Role-Based Access Control component in the application_data GroupContext extension.¶
/* See MIMI Capability Types IANA registry */
uint16 CapablityType;
struct {
int role_index;
opaque role_name<V>;
opaque role_description<V>;
CapabilityType role_capabilities<V>;
int minimum_participants_constraint;
optional int maximum_participants_constraint;
int minimum_active_participants_constraint;
optional int maximum_active_participants_constraint;
} Role;
struct {
Role roles<V>;
} RoleData;
RoleData RoleUpdate;
¶
RoleUpdate (which has the same format as RoleData) is the format of the update field inside the ApplicationDataUpdate struct in an ApplicationDataUpdate Proposal for the Role-Based Access Control component.
If the contents of the update field are valid and if the proposer is authorized to generate such an update, the value of the update field completely replaces the value of the data field.¶
The participant list is a list of "users" in a room. Each user is assigned one role (expressed as the role_index) in the room.¶
struct {
opaque user<V>;
int role_index;
} UserRolePair;
struct {
uint32 user_index;
int role_index;
} UserindexRolePair
struct {
UserRolePair participants<V>;
} ParticipantListData;
struct {
uint32 removedIndices<V>;
UserindexRolePair changedRoleParticipants<V>
UserRolePair addedParticipants<V>;
} ParticipantListUpdate;
¶
ParticipantListUpdate is the contents of an ApplicationDataUpdate Proposal with the component ID for the participant list.¶
TODO Security¶
Create a new registry with the following values assigned sequentially using the reference RFCXXXX.¶
canAddParticipant canRemoveParticipant canAddOwnClient canRemoveSelf canAddSelf canCreateJoinLink canUseJoinLink canUnBan canKick canRevokeVoice canGrantVoice canKnock canAcceptKnock canChangeUserRole canCreateSubgroup canTargetMessage canReceiveMessage canReportAbuse canReactToMessage canEditReaction canDeleteReaction canEditOwnMessage canDeleteOwnMessage canDeleteAnyMessage canStartTopic canReplyInTopic canSendDirectMessage canTargetMessage canUploadVideo canUploadAttachment canDownloadImage canDownloadVideo canDownloadAttachment canSendLink canSendLinkPreview canFollowLink canChangeRoomSubject canChangeRoomAvatar canChangeOwnName canChangeOwnPresence canChangeOwnMood canChangeOwnAvatar canJoinCall canSendAudio canReceiveAudio canSendVideo canReceiveVideo canShareScreen canViewSharedScreen canChangeOtherPolicyAttribute canDestroyRoom canSendMLSUpdateProposal cansendMLSReinitProposal canSendMLSPSKProposal canSendMLSExternalProposal canSendMLSExternalCommit¶
TODO acknowledge.¶