More Instant Messaging Interoperability R. Mahy Internet-Draft Rohan Mahy Consulting Service Intended status: Informational 18 December 2024 Expires: 21 June 2025 Application State Components for More Instant Messaging Interoperability (MIMI) draft-mahy-mimi-app-components-00 Abstract TODO Abstract 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://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. 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 21 June 2025. Mahy Expires 21 June 2025 [Page 1] Internet-Draft MIMI Application State December 2024 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 3. Room Metadata . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Role-Based Access Control . . . . . . . . . . . . . . . . . . 3 5. Participant List . . . . . . . . . . . . . . . . . . . . . . 4 6. Preauthorized Participants . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8.1. New MIMI Role Capabilities registry . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction TODO Introduction 2. Conventions and Definitions 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. 3. Room Metadata 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. Mahy Expires 21 June 2025 [Page 2] Internet-Draft MIMI Application State December 2024 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; } Uri; /* a sequence of valid UTF8 without nulls */ struct { opaque string; } 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. 4. Role-Based Access Control 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. Mahy Expires 21 June 2025 [Page 3] Internet-Draft MIMI Application State December 2024 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; opaque role_description; CapabilityType role_capabilities; int minimum_participants_constraint; optional int maximum_participants_constraint; int minimum_active_participants_constraint; optional int maximum_active_participants_constraint; } Role; struct { Role roles; } 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. 5. Participant List 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. Mahy Expires 21 June 2025 [Page 4] Internet-Draft MIMI Application State December 2024 struct { opaque user; int role_index; } UserRolePair; struct { uint32 user_index; int role_index; } UserindexRolePair struct { UserRolePair participants; } ParticipantListData; struct { uint32 removedIndices; UserindexRolePair changedRoleParticipants UserRolePair addedParticipants; } ParticipantListUpdate; ParticipantListUpdate is the contents of an ApplicationDataUpdate Proposal with the component ID for the participant list. 6. Preauthorized Participants Preauthorized Participants are MIMI users who have authorization to adopt a role in a room by virtue of certain credential claims or properties, as opposed to being individually enumerated in the participant list. For example, a room for employee benefits might be available to join with the regular participant role to all employees with a residence in a specific country; anyone working in the human resources department might be able to join the same room as a moderator. PreAuthData is the format of the data field inside the ComponentData struct for the Preauthorized Participants component in the application_data GroupContext extension. Mahy Expires 21 June 2025 [Page 5] Internet-Draft MIMI Application State December 2024 struct { int target_role_index; /* preauth_domain consists of ASCII letters, digits, and hyphens */ opaque preauth_domain; /* the remaining fields are in the form of a URI */ opaque preauth_workgroup; opaque preauth_group; opaque preauth_user; } PreAuthPerRoleList; struct { /* MLS Credential Type of the "claim" */ CredentialType credential_type; /* the binary representation of an X.509 OID, a JWT claim name string, */ /* or the CBOR representation of a CWT claim (an int or tstr) */ opaque id; } ClaimId; struct { ClaimId claim_id; opaque claim_value; } Claim; struct { /* when all claims in the claimset are satisfied, claimset is satisfied */ Claim claimset; Role target_role; } PreAuthRoleEntry; struct { PreAuthRoleEntry preauthorized_entries; } PreAuthData; PreAuthData PreAuthUpdate; PreAuthUpdate (which has the same format as PreAuthData) is the format of the update field inside the ApplicationDataUpdate struct in an ApplicationDataUpdate Proposal for the Preauthorized Participants 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. 7. Security Considerations TODO Security 8. IANA Considerations Mahy Expires 21 June 2025 [Page 6] Internet-Draft MIMI Application State December 2024 8.1. New MIMI Role Capabilities registry 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 Mahy Expires 21 June 2025 [Page 7] Internet-Draft MIMI Application State December 2024 canSendAudio canReceiveAudio canSendVideo canReceiveVideo canShareScreen canViewSharedScreen canChangeOtherPolicyAttribute canDestroyRoom canSendMLSUpdateProposal cansendMLSReinitProposal canSendMLSPSKProposal canSendMLSExternalProposal canSendMLSExternalCommit 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Acknowledgments TODO acknowledge. Author's Address Rohan Mahy Rohan Mahy Consulting Service Email: rohan.ietf@gmail.com Mahy Expires 21 June 2025 [Page 8]