XEP-0045: Add explicit error definition when non-owners attempt to us…

…e 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 <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.") to the sections where it's missing.

xep-0045.xml

@@ -46,6 +46,12 @@
   </schemaloc>
   <registry/>
   &stpeter;
+  <revision>
+    <version>1.35.1</version>
+    <date>2024-09-17</date>
+    <initials>gk</initials>
+    <remark><p>Add explicit error definition when non-owners attempt to use owner-specific functionality.</p></remark>
+  </revision>
   <revision>
     <version>1.35.0</version>
     <date>2024-08-14</date>
@@ -4542,7 +4548,8 @@
 </iq>
 ]]></example>
     <p>As <link url='#affil'>affiliations are granted, revoked, and maintained based on the user's bare JID</link>, 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.</p>
-    <p>The service MUST add the user to the owner list and then inform the owner of success:</p>
+    <p>If the &lt;user@host&gt; of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.</p>
+    <p>Otherwise, the service MUST add the user to the owner list and then inform the owner of success:</p>
     <example caption='Service Informs Owner of Success'><![CDATA[
 <iq from='[email protected]'
     id='owner1'
@@ -4608,6 +4615,7 @@
 </iq>
 ]]></example>
     <p>As <link url='#affil'>affiliations are granted, revoked, and maintained based on the user's bare JID</link>, 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.</p>
+    <p>If the &lt;user@host&gt; of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.</p>
     <p>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.</p>
     <p>If an implementation does not allow one owner to revoke another user's owner status, the implementation MUST return a &notauthorized; error to the owner who made the request.</p>
     <p>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.</p>
@@ -4721,7 +4729,8 @@
 </iq>
 ]]></example>
     <p>As <link url='#affil'>affiliations are granted, revoked, and maintained based on the user's bare JID</link>, 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.</p>
-    <p>The service MUST add the user to the admin list and then inform the owner of success:</p>
+    <p>If the &lt;user@host&gt; of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.</p>
+    <p>Otherwise, the service MUST add the user to the admin list and then inform the owner of success:</p>
     <example caption='Service Informs Owner of Success'><![CDATA[
 <iq from='[email protected]'
     id='admin1'
@@ -4787,7 +4796,8 @@
 </iq>
 ]]></example>
     <p>As <link url='#affil'>affiliations are granted, revoked, and maintained based on the user's bare JID</link>, 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.</p>
-    <p>The service MUST remove the user from the admin list and then inform the owner of success:</p>
+    <p>If the &lt;user@host&gt; of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.</p>
+    <p>Otherwise, the service MUST remove the user from the admin list and then inform the owner of success:</p>
     <example caption='Service Informs Owner of Success'><![CDATA[
 <iq from='[email protected]'
     id='admin2'