From 949dacec42b6cb0189dfd1639d912e9818506416 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 5 Jul 2024 19:32:29 +0200 Subject: [PATCH 1/3] XEP-0045: Improve consistency of role and affiliation change notifications A presence-based notification of a role or affiliation change can only be sent when the affected user is in the room. The XEP mostly used wording to this effect. In this commit, this wording has been applied to a few places where it was missing. --- xep-0045.xml | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 07f91955e..a04d1f719 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -46,6 +46,12 @@ &stpeter; + + 1.34.7 + 2024-07-05 + gk +

Improve consistency of role and affiliation change notifications

 + 1.34.6 2024-05-01 @@ -3423,7 +3429,7 @@ to='crone1@shakespeare.lit/desktop' type='result'/> ]]> -

The service MUST then send updated presence from this individual to all occupants, indicating the loss of membership by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "none".

+

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of membership by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "none".

]]> -

The service MUST then send updated presence from this individual to all occupants, indicating the addition of moderator status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator".

+

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the addition of moderator status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator".

]]> -

The service MUST then send updated presence from this individual to all occupants, indicating the removal of moderator status by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "participant".

+

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the removal of moderator status by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "participant".

]]> -

The service MUST then send updated presence for any affected individuals to all occupants, indicating the change in moderator status by sending the appropriate extended presence stanzas as described in the foregoing use cases.

+

For any affected individual that is in the room, the service MUST then send updated presence to all occupants, indicating the change in moderator status by sending the appropriate extended presence stanzas as described in the foregoing use cases.

As noted, moderator status cannot be revoked from a room owner or room admin. If a room admin attempts to revoke moderator status from such a user by modifying the moderator list, the service MUST deny the request and return a ¬allowed; error to the sender:

Date: Fri, 5 Jul 2024 19:51:34 +0200 Subject: [PATCH 2/3] XEP-0045: Fix typo in example --- xep-0045.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0045.xml b/xep-0045.xml index a04d1f719..45b2cb375 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -4565,7 +4565,7 @@ id='22B0F570-526A-4F22-BDE3-52EC3BB18371' to='crone1@shakespeare.lit/desktop'> - From 0b6a3baf3dfb31e63990f73a0d15d66118db96ac Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Fri, 5 Jul 2024 21:17:11 +0200 Subject: [PATCH 3/3] XEP-0045: Introduce section on role/affilition change notifications The mechanisms in which occupants are notified of a role or affiliation change is quite similar throughout the specification, but is not consistently documented. This commit introduces a new section, describing the pre-existing MUST of using a presence stanza when to affected user is in the room, as well as the pre-existing MAY of usinga message stanza when the user is not. --- xep-0045.xml | 130 +++++++++++++++++++++++++++------------------------ 1 file changed, 68 insertions(+), 62 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 45b2cb375..b85f82023 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1124,6 +1124,57 @@ + +

When the role or affiliation of a user is changed, notifications of such a change uses stanzas that include an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child, with the 'role' and/or 'affiliation' attribute set to a value of new role or affiliation.

+

If the user is in the room, the service MUST send updated presence from this individual's &OCCUPANTJID; to all occupants, indicating the change in affiliation or role, by including such an <x/> element.

+ + + + + +]]> + + + + + +]]> +

If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the change in affiliation or role, by including such an <x/> element. As roles not necessarily persist across a user's visits to the room, the value of the 'role' attribute may differ from the equivalent notification sent when the affected is present in the room (as described above).

+ + + + + +]]> + + + + + +]]> + @@ -2966,7 +3017,7 @@ to='crone1@shakespeare.lit/desktop' type='result'/> ]]> -

The service MUST then send updated presence from this individual's &OCCUPANTJID; to all occupants, indicating the addition of voice privileges by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "participant".

+

The service MUST then send to all occupants a notification indicating the addition of voice privileges, as described under Notifications of Changes, using the 'role' attribute set to a value of "participant".

]]> -

The service MUST then send updated presence from this individual to all occupants, indicating the removal of voice privileges by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "visitor".

+

The service MUST then send to all occupants a notification indicating the removal of voice privileges, as described under Notifications of Changes, using the 'role' attribute set to a value of "visitor".

]]> -

The service MUST then send updated presence for any affected individuals to all occupants, indicating the change in voice privileges by sending the appropriate extended presence stanzas as described in the foregoing use cases.

+

The service MUST then send to all occupants a notification indicating changes in voice privilege for any affected individual, as described under Notifications of Changes as described in the foregoing use cases.

As noted, voice privileges cannot be revoked from a room owner or room admin, nor from any user with a higher affiliation than the moderator making the request. If a room admin attempts to revoke voice privileges from such a user by modifying the voice list, the service MUST deny the request and return a ¬allowed; error to the sender:

]]> -

If a moderator approves the voice request, the service shall grant voice to the occupant and send a presence update as described in the Granting Voice to a Visitor section of this document.

+

If a moderator approves the voice request, the service shall grant voice to the occupant and send notifications as described in the Granting Voice to a Visitor section of this document.

@@ -3378,7 +3429,7 @@ to='crone1@shakespeare.lit/desktop' type='result'/> ]]> -

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 by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".

+

The service MUST then send to all occupants a notification indicating the granting of membership, as described under Notifications of Changes, using the 'affiliation' attribute set to a value of "member".

]]> -

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of membership by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "none".

+

The service MUST then send to all occupants a notification indicating the loss of membership, as described under Notifications of Changes, using the 'affiliation' attribute set to a value of "none".

The service MUST change the affiliation of any affected user. If the user has been removed from the member list, the service MUST change the user's affiliation from "member" to "none". If the user has been added to the member list, the service MUST change the user's affiliation to "member".

If a removed member is currently in a members-only room, the service SHOULD kick the occupant by changing the removed member's role to "none" and send appropriate presence to the removed member as previously described. The service MUST subsequently refuse entry to the user.

-

For all room types, the service MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "none".

+

For all room types, the service MUST then send to all occupants a notification indicating the change in affiliation, as described under Notifications of Changes, using the 'affiliation' attribute set to a value of "none".

]]>

Invitations sent through an open room MUST NOT trigger the addition of the invitee to the member list.

-

If a user is added to the member list of an open room and the user is in the room, the service MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".

+

If a user is added to the member list of an open room, the service MUST then send to all occupants a notification indicating the change in affiliation, as described under Notifications of Changes, using the 'affiliation' attribute set to a value of "member".

]]> -

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the addition of moderator status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator".

+

The service MUST then send to all occupants a notification indicating the addition of moderator status, as described under Notifications of Changes, using the 'role' attribute set to a value of "moderator".

]]> -

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the removal of moderator status by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "participant".

+

The service MUST then send to all occupants a notification indicating the removal of moderator status, as described under Notifications of Changes, using the 'role' attribute set to a value of "participant".

]]> -

For any affected individual that is in the room, the service MUST then send updated presence to all occupants, indicating the change in moderator status by sending the appropriate extended presence stanzas as described in the foregoing use cases.

+

For any affected user, the service MUST then send to all occupants a notification indicating the change of moderator status, as described under Notifications of Changes, using the appropriate 'role' attribute value as described in the foregoing use cases.

As noted, moderator status cannot be revoked from a room owner or room admin. If a room admin attempts to revoke moderator status from such a user by modifying the moderator list, the service MUST deny the request and return a ¬allowed; error to the sender:

]]> -

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of owner status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).

+

The service MUST then send to all occupants a notification indicating the granting of owner status, as described under Notifications of Changes, using the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).

-[ ... ] -]]> -

If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of owner status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "owner".

- - - - - - [ ... ] ]]> @@ -4612,7 +4648,7 @@ to='crone1@shakespeare.lit/desktop' type='result'/> ]]> -

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of owner status by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "owner" and the 'role' attribute set to an appropriate value:

+

The service MUST then send to all occupants a notification indicating the loss of owner status, as described under Notifications of Changes, using the 'affiliation' attribute set to a value other than "owner" and the 'role' attribute set to an appropriate value:

]]> -

The service MUST also send presence notifications related to any affiliation changes that result from modifying the owner list as previously described.

+

The service MUST then send to all occupants a notification related to any affiliation changes that result from modifying the owner list as previously described.

@@ -4721,7 +4757,7 @@ to='crone1@shakespeare.lit/desktop' type='result'/> ]]> -

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of admin status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to an appropriate value given the affiliation and room type (typically "moderator").

+

The service MUST then send to all occupants a notification indicating the granting of admin status, as described under Notifications of Changes, using the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to an appropriate value given the affiliation and room type (typically "moderator").

-[ ... ] -]]> -

If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of admin status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin".

- - - - - - [ ... ] ]]> @@ -4786,7 +4807,7 @@ to='crone1@shakespeare.lit/desktop' type='result'/> ]]> -

If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of admin status by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "admin" or "owner" and the 'role' attribute set to an appropriate value given the affiliation level and the room type (typically "participant").

+

The service MUST then send to all occupants a notification indicating the loss of admin status, as described under Notifications of Changes, using the 'affiliation' attribute set to a value other than "admin" or "owner" and the 'role' attribute set to an appropriate value given the affiliation level and the room type (typically "participant").

-[ ... ] -]]> -

If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the loss of admin status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "admin".

- - - - - - [ ... ] ]]> @@ -4879,7 +4885,7 @@ to='crone1@shakespeare.lit/desktop' type='result'/> ]]> -

The service MUST also send presence notifications related to any affiliation changes that result from modifying the admin list as previously described.

+

The service MUST also send notifications related to any affiliation changes that result from modifying the admin list as previously described.