From 957b203540d86ccfb1c03ba3ba3b954ae62f7073 Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Wed, 14 Aug 2024 12:18:41 +0200 Subject: [PATCH] XEP-0045: Add explicit error definition when non-owners attempt to use owner-specific functionality XEP-0045 explicitly states that modifying the Owner List (section 10.5) is 'forbidden' to any non-owner, but does not explicitly state that error in 10.3 (Granting Owner Status) and 10.4 (Revoking Owner Status). The same issue is there in the sections 10.6, 10.7 and 10.8 (granting/revoking Admin Status). This commit copies the text that's used throughout the specification ("If the of the 'from' address does not match the bare JID of a room owner, the service MUST return a error to the sender.") to the sections where it's missing. --- xep-0045.xml | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index bb1cbd7c..b494bd9b 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -46,6 +46,12 @@ &stpeter; + + 1.35.1 + 2024-09-17 + gk +

Add explicit error definition when non-owners attempt to use owner-specific functionality.

 + 1.35.0 2024-08-14 @@ -4542,7 +4548,8 @@ ]]>

As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

-

The service MUST add the user to the owner list and then inform the owner of success:

+

If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.

+

Otherwise, the service MUST add the user to the owner list and then inform the owner of success:

]]>

As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

+

If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.

A service MUST NOT allow an owner to revoke his or her own owner status if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own owner status if there are other owners.

If an implementation does not allow one owner to revoke another user's owner status, the implementation MUST return a ¬authorized; error to the owner who made the request.

Note: Allowing an owner to remove another user's owner status can compromise the control model for room management; therefore this feature is OPTIONAL, and implementations are encouraged to support owner removal through an interface that is open only to individuals with service-wide admin status.

@@ -4721,7 +4729,8 @@ ]]>

As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

-

The service MUST add the user to the admin list and then inform the owner of success:

+

If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.

+

Otherwise, the service MUST add the user to the admin list and then inform the owner of success:

]]>

As affiliations are granted, revoked, and maintained based on the user's bare JID, the requesting entity SHOULD use the bare JID of the user in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.

-

The service MUST remove the user from the admin list and then inform the owner of success:

+

If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.

+

Otherwise, the service MUST remove the user from the admin list and then inform the owner of success: