Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 2 commits into from
Aug 23, 2024
Merged

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

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d81aea5
XEP-0045: Explicitly use bare JIDs when operating on affiliations.
guusdk Aug 14, 2024
e84c697
Merge branch 'master' into XEP-0045_10_Make-bare-JID-affiliation-more…
iNPUTmice Aug 23, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 8 additions & 3 deletions xep-0045.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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>
Expand All @@ -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>
Expand Down Expand Up @@ -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]'
Expand Down Expand Up @@ -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>
Expand Down Expand Up @@ -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'
Expand Down Expand Up @@ -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]'
Expand Down Expand Up @@ -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]'
Expand Down Expand Up @@ -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'
Expand Down