draft-ralston-mimi-policy-00.txt		draft-ralston-mimi-policy-01.txt
	More Instant Messaging Interoperability T. Ralston		More Instant Messaging Interoperability T. Ralston
	Internet-Draft M. Hodgson		Internet-Draft M. Hodgson
	Intended status: Standards Track The Matrix.org Foundation C.I.C.		Intended status: Standards Track The Matrix.org Foundation C.I.C.
	Expires: 26 March 2024 23 September 2023		Expires: 23 September 2024 22 March 2024
	MIMI Policy Envelope		More Instant Messaging Interoperability (MIMI) Policy
	draft-ralston-mimi-policy-00		draft-ralston-mimi-policy-01
	Abstract		Abstract
	The MIMI Policy Envelope describes a _policy control protocol_ and		This document specifies an authorization policy framework for the
	_participation control protocol_ for use in a room, applied at the		More Instant Messaging Interoperability (MIMI) working group's
	user participation level, as described by [I-D.barnes-mimi-arch].		transport protocol. It makes use of a Role-Based Access Control
			(RBAC) mechanism to grant/deny permissions to users, clients, and
			servers.
	About This Document		About This Document
	This note is to be removed before publishing as an RFC.		This note is to be removed before publishing as an RFC.
	The latest revision of this draft can be found at		The latest revision of this draft can be found at
	https://turt2live.github.io/ietf-mimi-policy/draft-ralston-mimi-		https://turt2live.github.io/ietf-mimi-policy/draft-ralston-mimi-
	policy.html. Status information for this document may be found at		policy.html. Status information for this document may be found at
	https://datatracker.ietf.org/doc/draft-ralston-mimi-policy/.		https://datatracker.ietf.org/doc/draft-ralston-mimi-policy/.
	skipping to change at page 1, line 48 ¶		skipping to change at page 2, line 4 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
			This Internet-Draft will expire on 23 September 2024.
	This Internet-Draft will expire on 26 March 2024.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3		2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
	2.1. Permissions Definitions . . . . . . . . . . . . . . . . . 4		2.1. Permissions Definitions . . . . . . . . . . . . . . . . . 4
	2.2. Participation Definitions . . . . . . . . . . . . . . . . 4		2.2. Participation Definitions . . . . . . . . . . . . . . . . 4
	3. Event Authorization . . . . . . . . . . . . . . . . . . . . . 5		3. Types of Senders . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Auth Events Selection . . . . . . . . . . . . . . . . . . 5		4. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Types of Senders . . . . . . . . . . . . . . . . . . . . . . 6		4.1. Calculating Permissions . . . . . . . . . . . . . . . . . 5
	5. Permissions . . . . . . . . . . . . . . . . . . . . . . . . . 6		4.2. Effective Power Level . . . . . . . . . . . . . . . . . . 6
	5.1. Calculating Permissions . . . . . . . . . . . . . . . . . 7		4.3. List of Permissions . . . . . . . . . . . . . . . . . . . 7
	5.2. Effective Power Level . . . . . . . . . . . . . . . . . . 8		4.4. Role Changes . . . . . . . . . . . . . . . . . . . . . . 8
	5.3. List of Permissions . . . . . . . . . . . . . . . . . . . 8		5. User Participation . . . . . . . . . . . . . . . . . . . . . 8
	5.4. Event Sending Permissions . . . . . . . . . . . . . . . . 10		5.1. General Conditions . . . . . . . . . . . . . . . . . . . 9
	5.5. Role Changes . . . . . . . . . . . . . . . . . . . . . . 10		5.2. Invite Conditions . . . . . . . . . . . . . . . . . . . . 9
	6. User Participation . . . . . . . . . . . . . . . . . . . . . 10		5.3. Join Conditions . . . . . . . . . . . . . . . . . . . . . 9
	6.1. General Conditions . . . . . . . . . . . . . . . . . . . 11		5.4. Knock Conditions . . . . . . . . . . . . . . . . . . . . 9
	6.2. Invite Conditions . . . . . . . . . . . . . . . . . . . . 11		5.5. Ban Conditions . . . . . . . . . . . . . . . . . . . . . 10
	6.3. Join Conditions . . . . . . . . . . . . . . . . . . . . . 11		5.6. Leave Conditions . . . . . . . . . . . . . . . . . . . . 10
	6.4. Knock Conditions . . . . . . . . . . . . . . . . . . . . 11		5.6.1. Voluntary . . . . . . . . . . . . . . . . . . . . . . 10
	6.5. Ban Conditions . . . . . . . . . . . . . . . . . . . . . 12		5.6.2. Kicks . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.6. Leave Conditions . . . . . . . . . . . . . . . . . . . . 12		5.7. Join Rules . . . . . . . . . . . . . . . . . . . . . . . 11
	6.6.1. Voluntary . . . . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6.6.2. Kicks . . . . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6.7. m.room.join_rules . . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	7. Event/History Visibility . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . 11
	7.1. m.room.history_visibility . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The primary objective for the More Instant Messaging Interoperability		This document relies on the concepts described by
	(MIMI) working group is to specify the needed protocols to achieve		[I-D.barnes-mimi-arch] and [I-D.ralston-mimi-protocol].
	interoperability among modern messaging providers. The protocols
	which make up the "MIMI stack" are described by
	[I-D.barnes-mimi-arch].
	In the stack are a policy control protocol and a participation
	control protocol. These two control protocols are described by this
	document, supported by *TODO(TR): Link to I-D.ralston-mimi-
	signaling*.
	Policy control is handled through permissions, while participation is
	managed primarily through the rules governing m.room.user. Together,
	these control protocols create this policy document.
	When an action is impossible for a server to enforce, such as when a		Policy within MIMI defines who or what is allowed to take a certain
	client operated by a user sends an encrypted instant message, the		action, and what the allowable actions are. Some examples include
	receiving clients are responsible for enforcing the remainder of the		whether a given user is able to send messages or promote/demote other
	policy. This may mean, for example, decrypting a message but not		users within the room. This document outlines the minimum
	rendering it due to a policy violation.		permissions required for interoperability, and how the Role-Based
			Access Control (RBAC) mechanism works.
	The concepts of permissions and participation state for a user are		Some actions are enforceable by the hub server or local follower
	deliberately separated in this policy document. A user's		server in a room, however other actions can only be handled by end
	participation state might affect which permissions they can use, but		clients. Whether a server can enforce the policy largely depends on
	a user's permissions do not change their participation in a room.		the server's visibility of the message being checked: MLS Private
			Messages cannot be inspected, and therefore cannot have policy
			applied to them by the server. Such messages will need to be checked
			by the clients instead.
	2. Conventions and Definitions		2. Conventions and Definitions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Terms from [I-D.barnes-mimi-arch] and [I-D.ralston-mimi-terminology]		Terms from [I-D.barnes-mimi-arch], [I-D.ralston-mimi-terminology],
	are used throughout this document. [I-D.barnes-mimi-arch] takes		and [I-D.ralston-mimi-protocol] are used throughout this document.
	precedence where there's conflict.		[I-D.barnes-mimi-arch] takes precedence where there's conflict.
	Terms from *TODO(TR): Link to I-D.ralston-mimi-signaling* are used
	throughout this document.
	Other terms include:		Other terms include:
	_Rejected_: The action being performed ceases to continue through the		_Rejected_: The action being performed ceases to continue through the
	remainder of the send/rendering steps. For a hub server, this means		remainder of the send/rendering steps. For a hub server, this means
	the event being sent is not added to the room and is not sent to any		the event being sent is not added to the room and is not sent to any
	other server. For a client, this equates to not rendering or		other server. For a client, this equates to not rendering or
	respecting the action.		respecting the action.
	_Allowed_: The opposite of Rejected. The action is expressly		_Allowed_: The opposite of Rejected. The action is expressly
	skipping to change at page 5, line 8 ¶		skipping to change at page 4, line 47 ¶
	_Banned_: The target is kicked and cannot be invited, joined, or		_Banned_: The target is kicked and cannot be invited, joined, or
	knock on the room until unbanned.		knock on the room until unbanned.
	_Knocking_: The sender is requesting an invite into the room. They		_Knocking_: The sender is requesting an invite into the room. They
	can either be welcomed in (invited) or declined (kicked).		can either be welcomed in (invited) or declined (kicked).
	_Kicked_: Involuntary leave. The target and sender are not the same		_Kicked_: Involuntary leave. The target and sender are not the same
	user.		user.
	3. Event Authorization		3. Types of Senders
	When a hub server receives an event, and before it adds it to the
	room, it MUST ensure the event passes the policy for the room. In
	the case of this document, the server MUST ensure the following
	checks are performed:
	1. The event is correctly signed and hashed.
	2. The event's authEvents include the appropriate event types
	(Section 3.1).
	3. The sender has permission (Section 5.1) to send the event.
	4. Any event type-specific checks are performed, as described
	throughout this document.
	3.1. Auth Events Selection
	When a server is populating authEvents, it MUST include the event IDs
	for the following event types. These SHOULD be the most recent event
	IDs for the event types.
	Note: m.room.create MUST always have an empty authEvents array.
	* The m.room.create event.
	* The m.room.user event for the sender, if applicable.
	* The m.room.role_map event (Section 5), if set.
	* The m.room.role events (Section 5) assigned to the user sender, if
	any.
	* If the event type is m.room.user:
	- The target user's m.room.user event, if any.
	- If the participation state is join or invite, the
	m.room.join_rules event (Section 6.7), if any.
	*TODO(TR): Restricted joins join_authorised_via_users_server? (GH
	issue (https://github.com/turt2live/ietf-mimi-policy/issues/1))*
	If an event is missing from authEvents but should have been included
	with the above selection algorithm, the event is rejected.
	If events not intended to be selected using the above algorithm above
	are included in authEvents, the event is rejected. This extends to
	events which aren't known or are malformed in authEvents.
	If an event uses non-current events in its authEvents, it is
	rejected.
	4. Types of Senders		*TODO*: Figure out non-user permission structures.
			https://github.com/turt2live/ietf-mimi-policy/issues/2
	*TODO(TR): Do we want to send as not-users? (GH issue		4. Permissions
	(https://github.com/turt2live/ietf-mimi-policy/issues/2))*
	Currently this document only supports sender being a user ID.		Groups of permissions are known as roles. These roles are then
			assigned to a user or server as needed. Permissions cannot be
			assigned without being part of a role.
	5. Permissions		Roles do not currently carry aesthetic characteristics, such as a
			name, badge color, or avatar.
	Rooms are capable of defining their own roles for grouping		Roles, and their assignees, are persisted through the AppSync MLS
	permissions to apply to users. These roles do not currently have		extension. Changes are proposed with MLS Proposals, and confirmed
	aesthetic characteristics, such as a display name, badge color, or		with MLS Commits. This uses the mimiRoomPolicy applicationId defined
	avatar.		by [I-D.ralston-mimi-protocol].
	Roles are described by an m.room.role state event. The state key for		*TODO*: Define actual example/schema once AppSync is more reviewed
	the event is the "role ID", and is not intended to be human readable.		by the MLS working group. Initial indications are unclear if a
			diff or "irreducible" blob is preferred.
	The content for the event has the following structure in TLS		A role _notionally_ looks like the following:
	presentation language format (Section 3 of [RFC8446]):
	enum {		enum {
	// Iterated later in the document.		/* Iterated later in the document. */
	} Permission;		} Permission;
	struct {		struct {
	select (Permission) {		select (Permission) {
	// cases defined later in the document.		/* cases defined later in the document. */
	} permission;		} permission;
	} PermissionValue;		} PermissionValue;
	struct {		struct {
	PermissionValue permissions[];		PermissionValue permissions<V>;
	} MRoomRoleEventContent;		IdentifierUri assignees<V>;
			int order;
	Users are assigned to roles using an m.room.role_map state event,		} Role;
	with empty string for a state key. The content being as follows:
	struct {
	// The role's ID.
	opaque roleId;
	// The user IDs who are assigned this role.
	opaque userIds[];
	// The power level for the role. This is used in cases of tiebreak and to
	// override permissions from another role.
	uint32 order;
	} RoleConfig;
	struct {
	RoleConfig roles[];
	} MRoomRoleMapEventContent;
	Each role ID MUST only appear once in MRoomRoleMapEventContent.roles.		IdentifierUri is as defined by Section 5.2 of
	Each RoleConfig.order MUST be distinct from all other entries. If		[I-D.ralston-mimi-protocol].
	either of these checks fail when a server receives the event, the
	event is rejected.
	5.1. Calculating Permissions		4.1. Calculating Permissions
	A user's permissions is the sum of the permissions described by their		An entity's permissions is the sum of the permissions described by
	assigned roles. When two roles define the same permission (but with		their assigned roles. When two roles define the same permission (but
	different values), the higher order role takes precedence.		with different values), the higher order role takes precedence.
	For example, if given the following role structure...		For example, if given the following role structure...
	* Role A, order 1.		* Role A, order 1.
	- Permission A = true		- Permission A = true
	- Permission B = false		- Permission B = false
	* Role B, order 2.		* Role B, order 2.
	skipping to change at page 8, line 14 ¶		skipping to change at page 6, line 30 ¶
	... and a user assigned all three roles, the user's resolved set of		... and a user assigned all three roles, the user's resolved set of
	permissions would be:		permissions would be:
	* Permission A = false (takes Role B's value)		* Permission A = false (takes Role B's value)
	* Permission B = true (takes Role C's value)		* Permission B = true (takes Role C's value)
	* Permission C = false (defined by Role B, no conflict with Role C)		* Permission C = false (defined by Role B, no conflict with Role C)
	These permissions are then used to define whether a user can "send"		These permissions are then used to define whether a user can perform
	the event.		the action.
	5.2. Effective Power Level		4.2. Effective Power Level
	In some cases it is required to know the "power level" for a user to		In some cases it is required to know the "power level" for a user to
	solve tiebreaks. The power level of a user is the highest order role		solve tiebreaks. The power level of a user is the highest order role
	they are assigned with the desired permission set, regardless of		they are assigned with the desired permission set, regardless of
	value for that permission.		value for that permission.
	Using the example from Section 5.1, a user with all three roles would		Using the example from Section 4.1, a user with all three roles would
	have the following effective power levels for each permission in		have the following effective power levels for each permission in
	question:		question:
	* Permission A = 2		* Permission A = 2
	* Permission B = 3		* Permission B = 3
	* Permission C = 3		* Permission C = 3
	5.3. List of Permissions		4.3. List of Permissions
	The full definitions for Permission and PermissionValue in Section 5		The full definitions for Permission and PermissionValue in Section 4
	is:		is:
	enum {		enum {
	// Whether other users can be invited to the room by the role.		// Whether other users can be added to the room by the role.
	// Default: false.		// Default: false.
	invite(1),		add(1),
	// Whether other users can be kicked from the room by the role.		// Whether other users can be kicked from the room by the role.
	// Default: false.		// Default: false.
	kick(2),		kick(2),
	// Whether other users can be banned from the room by the role.		// Whether other users can be banned from the room by the role.
	// Default: false.		// Default: false.
	ban(3),		ban(3),
	// Whether another user's events can be redacted by the role.		// Whether another user's events can be redacted by the role.
	skipping to change at page 9, line 4 ¶		skipping to change at page 7, line 24 ¶
	// Whether other users can be kicked from the room by the role.		// Whether other users can be kicked from the room by the role.
	// Default: false.		// Default: false.
	kick(2),		kick(2),
	// Whether other users can be banned from the room by the role.		// Whether other users can be banned from the room by the role.
	// Default: false.		// Default: false.
	ban(3),		ban(3),
	// Whether another user's events can be redacted by the role.		// Whether another user's events can be redacted by the role.
	// Senders can always redact their own events regardless of this permission.		// Senders can always redact their own events regardless of this permission.
	// Default: false.		// Default: false.
	redact(4), // TODO(TR): Do we need this one?		redact(4), // TODO(TR): Do we need this one?
	// The event types the role is able to send.
	// Default: None.
	events(5),
	// The actions this role can take against roles. For example, adding or		// The actions this role can take against roles. For example, adding or
	// removing permissions.		// removing permissions.
	// Default: None.		// Default: None.
	roles(6),		roles(5),
			// Whether the assigned entities can send messages to the room.
			// Default: true.
			sendMessages(6), // TODO(TR): This likely needs breaking out.
	} Permission;		} Permission;
	struct {		struct {
	select (Permission) {		select (Permission) {
	case invite: BooleanPermission;		case invite: BooleanPermission;
	case kick: BooleanPermission;		case kick: BooleanPermission;
	case ban: BooleanPermission;		case ban: BooleanPermission;
	case redact: BooleanPermission;		case redact: BooleanPermission;
	case events: EventTypePermission;
	case roles: RolePermission;		case roles: RolePermission;
			case sendMessages: BooleanPermission;
	} permission;		} permission;
	} PermissionValue;		} PermissionValue;
	struct {		struct {
	// When false, the permission is explicitly not granted.		// When false, the permission is explicitly not granted.
	byte granted;		byte granted;
	} BooleanPermission;		} BooleanPermission;
	struct {
	// The event type being gated by a permission.
	opaque eventType;
	// When false, the permission to send the event is explicitly not granted.
	byte granted;
	} EventTypePermissionRecord;
	struct {
	// The event type restrictions. If there are duplicates, the lastmost entry
	// takes priority.
	EventTypePermissionRecord eventTypes[];
	} EventTypePermission;
	struct {		struct {
	// The role IDs that can be affected by this role. This includes adding,		// The role IDs that can be affected by this role. This includes adding,
	// removing, and changing permissions.		// removing, and changing permissions.
	// TODO(TR): We might want something more comprehensive.		// TODO(TR): We might want something more comprehensive.
	opaque affectRoleId[];		opaque affectRoleId[];
	} RolePermission;		} RolePermission;
	5.4. Event Sending Permissions		*TODO*: Determine which permissions are needed to fulfill
			[I-D.ietf-mimi-content].
	The sender for an event MUST have permission (Section 5.1) to send		4.4. Role Changes
	that event type, unless the event type is m.room.user. User
	participation events are handled specifically in Section 6.
	The sender MUST also be in the joined state to send such events.		*TODO*: I believe we need words to describe how to use the role
			permissions described above. Probably something using effective
			power levels and talking about what "add", "remove", and "change"
			actually mean.
	5.5. Role Changes		*TODO*: We also need to specify that the creator has superuser
			permissions until a role is defined/assigned.
	*TODO(TR): I believe we need words to describe how to use the role		5. User Participation
	permissions described above. Probably something using effective
	power levels and talking about what "add", "remove", and "change"
	actually mean.*
	*TODO(TR): We also need to specify that the creator has superuser		*TODO*: Needs updating considering participation state changes are
	permissions until a role is defined/assigned.*		proposed through AppSync now. The concepts around the rules of
			state changes still apply.
	6. User Participation		*TODO*: "Invite" likely needs swapping for "Add".
	User participation is tracked as m.room.user state events. The		User participation is tracked as m.room.user state events. The
	content for such an event has the following structure in TLS		content for such an event has the following structure in TLS
	presentation language format (Section 3 of [RFC8446]):		presentation language format (Section 3 of [RFC8446]):
	enum {		enum {
	invite, // "Invited" state.		invite, // "Invited" state.
	join, // "Joined" state.		join, // "Joined" state.
	leave, // "Left" state (including Kicked).		leave, // "Left" state (including Kicked).
	ban, // "Banned" state.		ban, // "Banned" state.
	skipping to change at page 11, line 5 ¶		skipping to change at page 9, line 10 ¶
	A user is considered to be "joined" to a room if they have a		A user is considered to be "joined" to a room if they have a
	participation state of join. All servers with users in the joined		participation state of join. All servers with users in the joined
	state are considered to be "in" the room.		state are considered to be "in" the room.
	Servers which are in the room can send events for their users		Servers which are in the room can send events for their users
	directly. The signaling protocol is able to assist servers (and		directly. The signaling protocol is able to assist servers (and
	therefore users) in sending the appropriate participation events		therefore users) in sending the appropriate participation events
	until they are able complete the join process.		until they are able complete the join process.
	6.1. General Conditions		5.1. General Conditions
	*TODO(TR): This is where we'd put server ACLs. (GH issue		*TODO*: This is where we'd put server ACLs -
	(https://github.com/turt2live/ietf-mimi-policy/issues/3))*		https://github.com/turt2live/ietf-mimi-policy/issues/3
	6.2. Invite Conditions		5.2. Invite Conditions
	The target user for an invite MUST:		The target user for an invite MUST:
	* NOT already be in the banned state.		* NOT already be in the banned state.
	* NOT already be in the joined state.		* NOT already be in the joined state.
	The sender for an invite MUST:		The sender for an invite MUST:
	* Already be in the joined state.		* Already be in the joined state.
	* Have permission (Section 5.1) to invite users.		* Have permission (Section 4.1) to invite users.
	Otherwise, reject.		Otherwise, reject.
	6.3. Join Conditions		5.3. Join Conditions
	The target and sender of a join MUST be the same.		The target and sender of a join MUST be the same.
	Whether a user can join without invite is dependent on the join rules		Whether a user can join without invite is dependent on the join rules
	(Section 6.7).		(Section 5.7).
	If the join rule is invite or knock, the user MUST already be in the		If the join rule is invite or knock, the user MUST already be in the
	joined or invite state.		joined or invite state.
	If the join rule is public, the user MUST NOT already be in the		If the join rule is public, the user MUST NOT already be in the
	banned state.		banned state.
	Otherwise, reject.		Otherwise, reject.
	6.4. Knock Conditions		5.4. Knock Conditions
	The target and sender of a knock MUST be the same.		The target and sender of a knock MUST be the same.
	If the current join rule (Section 6.7) for the room is knock, the		If the current join rule (Section 5.7) for the room is knock, the
	user MUST NOT already be in the banned or joined state.		user MUST NOT already be in the banned or joined state.
	Otherwise, reject.		Otherwise, reject.
	6.5. Ban Conditions		5.5. Ban Conditions
	The sender for a ban MUST:		The sender for a ban MUST:
	* Already be in the joined state.		* Already be in the joined state.
	* Have permission (Section 5.1) to ban users.		* Have permission (Section 4.1) to ban users.
	Otherwise, reject.		Otherwise, reject.
	Note that a ban implies kick.		Note that a ban implies kick.
	6.6. Leave Conditions		5.6. Leave Conditions
	Leaves in a room come in two varieties: voluntary and kicks.		Leaves in a room come in two varieties: voluntary and kicks.
	Voluntary leaves are when the user no longer wishes to be an active		Voluntary leaves are when the user no longer wishes to be an active
	participant in the room. A kick is done to remove a user forcefully.		participant in the room. A kick is done to remove a user forcefully.
	When the target and sender of a leave is the same, it is a voluntary		When the target and sender of a leave is the same, it is a voluntary
	leave.		leave.
	6.6.1. Voluntary		5.6.1. Voluntary
	The user MUST be in the invited, joined, or knocking state.		The user MUST be in the invited, joined, or knocking state.
	Otherwise, reject.		Otherwise, reject.
	6.6.2. Kicks		5.6.2. Kicks
	The target user for a kick MUST:		The target user for a kick MUST:
	* Already be in the joined state.		* Already be in the joined state.
	The sender for a kick MUST:		The sender for a kick MUST:
	* Already be in the joined state.		* Already be in the joined state.
	* Have permission (Section 5.1) to kick users.		* Have permission (Section 4.1) to kick users.
	* Have a higher (and NOT equal to) effective power level with		* Have a higher (and NOT equal to) effective power level with
	respect to the kick permission (Section 5.2) than the target user.		respect to the kick permission (Section 4.2) than the target user.
	If the target user is in the banned state, the sender requires		If the target user is in the banned state, the sender requires
	permission to ban users instead (as to ban means to unban as well).		permission to ban users instead (as to ban means to unban as well).
	This additionally extends to the effective power level check.		This additionally extends to the effective power level check.
	Otherwise, reject.		Otherwise, reject.
	6.7. m.room.join_rules		5.7. Join Rules
	*State key*: Empty string.
	*Content*:		*TODO*: Convert to an AppSync-style policy flag. It will need an
			associated permission.
	enum {		enum {
	invite,		invite,
	knock,		knock,
	public,		public,
	} JoinRule;		} JoinRule;
	struct {		struct {
	// The current join rule for the room. Defaults to `invite` if no join rules		// The current join rule for the room. Defaults to `invite` if no join rules
	// event is in the room.		// event is in the room.
	JoinRule rule;		JoinRule rule;
	} MRoomJoinRulesEventContent;		} PolicyJoinRule;
	*Redaction considerations*: rule under content is protected from
	redaction.
	7. Event/History Visibility
	Unless otherwise specified by the event type, non-state events MUST
	NOT be sent to a user's client if the history visibility rules
	prohibit it. State events are always visible to clients.
	When a server is fetching events it is missing to build history, the
	returned events are redacted unless the server has at least one user
	which is able to see the event under the history visibility rules.
	The server must then further filter the events before sending them to
	clients.
	History visibility rules are defined by m.room.history_visibility
	(Section 7.1), and can only affect future events. Events sent before
	the history visibility rule change are not retroactively affected.
	Taking into consideration the m.room.history_visibility event that is
	current at the time an event was sent, a user's visibility of a that
	event is described as:
	* If the visibility rule was world, show.
	* If the user was in the joined state, show.
	* If the visibility rule was shared and the user was in the joined
	state at any point after the event was sent, show.
	* If the user was in the invited state, and the visibility rule was
	invited, show.
	* Otherwise, don't show.
	7.1. m.room.history_visibility
	*State key*: Empty string.
	*Content*:
	enum {
	invited,
	joined,
	shared,
	world,
	} Visibility;
	struct {
	// The current join rule for the room. Defaults to `shared` if no history
	// visibility event is present in the room.
	Visibility visibility;
	} MRoomHistoryVisibilityEventContent;
	*Redaction considerations*: visibility under content is protected
	from redaction.
	8. IANA Considerations
	This document as a whole makes up the m.0 policy ID, as per
	*TODO(TR): Link to I-D.ralston-mimi-signaling*.
	This document's descriptions for the following event types are
	registered to the event types registry in *TODO(TR): Link to I-
	D.ralston-mimi-signaling*:
	* m.room.role (Section 5)		6. Security Considerations
	* m.room.role_map (Section 5)		*TODO*: Verbosely describe the security considerations throughout
			the doc.
	* m.room.join_rules (Section 6.7)		7. IANA Considerations
	* m.room.history_visibility (Section 7.1)		None.
	9. References		8. References
	9.1. Normative References		8.1. Normative References
	[I-D.barnes-mimi-arch]		[I-D.barnes-mimi-arch]
	Barnes, R., "An Architecture for More Instant Messaging		Barnes, R., "An Architecture for More Instant Messaging
	Interoperability (MIMI)", Work in Progress, Internet-		Interoperability (MIMI)", Work in Progress, Internet-
	Draft, draft-barnes-mimi-arch-01, 22 September 2023,		Draft, draft-barnes-mimi-arch-03, 4 March 2024,
	<https://datatracker.ietf.org/doc/html/draft-barnes-mimi-		<https://datatracker.ietf.org/doc/html/draft-barnes-mimi-
	arch-01>.		arch-03>.
			[I-D.ralston-mimi-protocol]
			Barnes, R., Hodgson, M., Kohbrok, K., Mahy, R., Ralston,
			T., and R. Robert, "More Instant Messaging
			Interoperability (MIMI) using HTTPS and MLS", Work in
			Progress, Internet-Draft, draft-ralston-mimi-protocol-02,
			4 March 2024, <https://datatracker.ietf.org/doc/html/
			draft-ralston-mimi-protocol-02>.
	[I-D.ralston-mimi-terminology]		[I-D.ralston-mimi-terminology]
	Ralston, T., "MIMI Terminology", Work in Progress,		Ralston, T., "MIMI Terminology", Work in Progress,
	Internet-Draft, draft-ralston-mimi-terminology-02, 10 July		Internet-Draft, draft-ralston-mimi-terminology-03, 23
	2023, <https://datatracker.ietf.org/doc/html/draft-		October 2023, <https://datatracker.ietf.org/doc/html/
	ralston-mimi-terminology-02>.		draft-ralston-mimi-terminology-03>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.		<https://www.rfc-editor.org/rfc/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.		May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
	9.2. Informative References		8.2. Informative References
			[I-D.ietf-mimi-content]
			Mahy, R., "More Instant Messaging Interoperability (MIMI)
			message content", Work in Progress, Internet-Draft, draft-
			ietf-mimi-content-02, 4 March 2024,
			<https://datatracker.ietf.org/doc/html/draft-ietf-mimi-
			content-02>.
	[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol		[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
	Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,		Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
	<https://www.rfc-editor.org/rfc/rfc8446>.		<https://www.rfc-editor.org/rfc/rfc8446>.
	Authors' Addresses		Authors' Addresses
	Travis Ralston		Travis Ralston
	The Matrix.org Foundation C.I.C.		The Matrix.org Foundation C.I.C.
	Email: travisr@matrix.org		Email: travisr@matrix.org
End of changes. 73 change blocks.
	303 lines changed or deleted		155 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/