]> Rohan Mahy Consulting Service

rohan.ietf@gmail.com

Applications and Real-Time More Instant Messaging Interoperability participant list roles capabilities room metadata components registry TODO Abstract About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the More Instant Messaging Interoperability Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction TODO Introduction

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 when, and only when, they appear in all capitals, as shown here.

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. RoomMetaData is the format of the data field inside the ComponentData struct for the Room Metadata component in the application_data GroupContext extension. ; } 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.

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. 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. ; 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.

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. ; 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.

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. ; /* 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.

Security Considerations TODO Security

IANA Considerations

New MIMI Role Capabilities registry Create a new registry with the following values assigned sequentially using the reference RFCXXXX.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments TODO acknowledge.