[Standards] XEP-0045: Multi-User Chat: Question/problem with modifying member list (e.g. in offline case)
waqas20 at gmail.com
Tue Mar 25 16:31:40 UTC 2014
On Tue, Mar 25, 2014 at 9:54 AM, Christian Schudt
<christian.schudt at gmx.de> wrote:
> Dear XMPP community,
> I recently had the following requirement for a Multi-User Chat implementation:
> User A (owner) and User B are in a members-only room. User A modifies the member list according to "9.3 and 9.5 Modifying the Member List" and adds another User C to the member list and also sends an invitation to User C.
> The room shall then inform User B about the new member / affiliation change. But it doesn't, because User C is not available in the room yet (he might be offline or currently doesn't wish to participate in a discussion).
> 9.3 Granting Membership (Example 123) says:
> "If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of membership..."
> So, why is there the "If the user is in the room" clause? Unfortunately with that, the above requirement can't be met.
> What do you think of the possibility to send the following stanza for this use case (with type="unavailable")?
> from='coven at chat.shakespeare.lit/thirdwitch'
> to='crone1 at shakespeare.lit/desktop'>
> <x xmlns='http://jabber.org/protocol/muc#user'>
> <item affiliation='member'
> jid='hag66 at shakespeare.lit/pda'
> (same is true for other affiliation changes, if the user, whose affiliation has changed is not in the room).
> Kind regards,
So you essentially want occupants to be informed about affiliation
changes of users not in the room.
MUC is inconsistent here. For affiliation changes involving admins or
owners, an implementation MAY broadcast a message to occupants (see
XEP-0045, examples 176 and 190). Example 190 has a typo, 'member'
should be 'owner'.
These messages are however limited to admin and owner affiliations,
not members. And they are also optional for implementations.
Your suggestion of using presence for this doesn't fit the MUC
protocol very well. Instead it would be useful to update the XEP to be
consistent about the messages it already sends (send for all
affiliations, not select ones), while allowing implementations freedom
in what they send (it should remain a MAY, and deployments should be
free to limit broadcasts to e.g., moderators only).
More information about the Standards