questions from Timo Kösters which the note taker was not able to
follow. No decisions were made.
question from Eric Burger: what about extensibility?
Rohan: MIMI will ship with a set of capabilities that impls must
support, plus some more optional ones. Rooms will advertise the
set of capabilities that clients must understand to participate.
Clients are required to abort if they don't recognize some
capability. Defining new roles uses existing extensibility
mechanism.
Timo: tradeoff here is between a more compact set of roles which is
more complex to compose, or a longer set of roles with fewer invalid
combinations
Rohan: we aren't clear on what kick means: are we removing one or
more clients (devices) or removing a participant (and all its
clients)? Spreadsheet of existing messaging provider features
doesn't clarify which one is widely supported. WG needs to decide
which one we want: https://github.com/ietf-wg-mimi/mimi-room-policy/issues/3
Rohan: if anyone has particular scenarios that aren't handled by
room policy mechanisms we have, please raise them in issues on https://github.com/ietf-wg-mimi/mimi-room-policy so we can figure
out whether they're solvable
Timo: must clarify that subrooms are on the same hub as superior
room, as only hub can see the participants
Timo: What's the value of per-client granularity in policies:
Rohan: There are enterprise cases that want this, so different
policy can be applied to different clients.
Raphael: MLS WG is currently considering "virtual clients" which
might help here. An indirection between a participant and
however many clients they might be using.
Timo and Rohan to continue collaborating offline on identifying and
addressing use cases.