Add explicit error definition when non-owners attempt to use owner-specific functionality.
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: