XEP-0045: Explicitly use bare JIDs when operating on affiliations.

Section 5.2 defines that affiliations are granted, revoked, and maintained based on the user's bare JID. This commit adds a reference to this definition where affiliations are used (in section 10), and adds a SHOULD to downcast to a bare JID when a request provides a full JID.

xep-0045.xml

@@ -48,7 +48,7 @@
   &stpeter;
   <revision>
     <version>1.34.7</version>
-    <date>2024-07-13</date>
+    <date>2024-08-14</date>
     <initials>gk</initials>
     <remark>
       <ul>
@@ -59,6 +59,7 @@
         <li>Clarify usage of presence stanzas when removing a non-member from a members-only room.</li>
         <li>Replace inappropriate RFC 2119 key word usage in §9.7.</li>
         <li>Presence sent to occupants of a destroyed room includes a &lt;destroy/&gt; element.</li>
+        <li>Explicitly use bare JIDs when operating on affiliations.</li>
       </ul>
     </remark>
   </revision>
@@ -4537,6 +4538,7 @@
   </query>
 </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>
     <example caption='Service Informs Owner of Success'><![CDATA[
 <iq from='[email protected]'
@@ -4602,6 +4604,7 @@
   </query>
 </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>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>
@@ -4653,7 +4656,7 @@
   </query>
 </iq>
 ]]></example>
-    <p>The owner can then modify the owner list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; <note>This is different from the behavior of room configuration, wherein the "muc#roomconfig_roomowners" field specifies the full list of room owners, not the delta.</note> each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner):</p>
+    <p>The owner can then modify the owner list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; <note>This is different from the behavior of room configuration, wherein the "muc#roomconfig_roomowners" field specifies the full list of room owners, not the delta.</note> each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner). 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 users in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.</p>
     <example caption='Owner Sends Modified Owner List to Service'><![CDATA[
 <iq from='[email protected]/globe'
     id='owner4'
@@ -4714,6 +4717,7 @@
   </query>
 </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>
     <example caption='Service Informs Owner of Success'><![CDATA[
 <iq from='[email protected]'
@@ -4779,6 +4783,7 @@
   </query>
 </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>
     <example caption='Service Informs Owner of Success'><![CDATA[
 <iq from='[email protected]'
@@ -4845,7 +4850,7 @@
   </query>
 </iq>
 ]]></example>
-    <p>The owner can then modify the admin list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; <note>This is different from the behavior of room configuration, wherein the "muc#roomconfig_roomadmins" field specifies the full list of room admins, not the delta.</note> each item MUST include the 'affiliation' attribute (normally set to a value of "admin" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner).</p>
+    <p>The owner can then modify the admin list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; <note>This is different from the behavior of room configuration, wherein the "muc#roomconfig_roomadmins" field specifies the full list of room admins, not the delta.</note> each item MUST include the 'affiliation' attribute (normally set to a value of "admin" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner). 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 users in the request. When processing a request that identifies a user by its full JID, a service SHOULD use the bare JID representation.</p>
     <example caption='Owner Sends Modified Admin List to Service'><![CDATA[
 <iq from='[email protected]/globe'
     id='admin4'