1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00

XEP-0280: clearly specify MUC-related rules

This commit is contained in:
Georg Lukas 2017-02-22 11:27:27 +01:00
parent a982331a6c
commit 7e5e0a587e

View File

@ -284,6 +284,16 @@
<li>it is of type "chat".</li>
<li>it is of type "normal" and contains a &lt;body&gt; element.</li>
<li>it is of type "error" and it was sent in response to a &MESSAGE; that was eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).</li>
<li>it matches the MUC-related rules outlined below.</li>
</ul>
<p>To properly handle messages exchanged with a MUC (or similar service), the server must be able to identify MUC-related messages. This can be accomplished by tracking the clients' presence in MUCs, or by checking for the <tt>&lt;x xmlns="http://jabber.org/protocol/muc#user"&gt;</tt> element in messages. The following rules are suggested for MUC-related messages:
</p>
<ul>
<li>A &MESSAGE; of type "groupchat" SHOULD NOT be carbon-copied.</li>
<li>A &MESSAGE; containing a &xep0249; SHOULD be carbon-copied.</li>
<li>A &MESSAGE; containing a <link url='https://xmpp.org/extensions/xep-0045.html#invite-mediated'>Mediated Invitation</link> SHOULD be carbon-copied.</li>
<li>A private &MESSAGE; from a local user to a MUC participant (sent to a full JID) SHOULD be carbon-copied<note>The server SHOULD limit carbon-copying to the clients sharing a <strong>Multi-Session Nick</strong> in that MUC, and MAY inject the &lt;x/&gt; element into such carbon copies. Clients SHOULD ignore carbon-copies of MUC-PMs related to a MUC they are not joined to.</note>.</li>
<li>A private &MESSAGE; from a MUC participant (received from a full JID) to a local user SHOULD NOT be carbon-copied (these messages are already replicated by the MUC service to all joined client instances).</li>
</ul>
<p>As this is a implementation detail of servers, clients MUST NOT rely on the server implementing a particular set of rules for which messages are eligible for Carbons delivery.</p>
<p>Future specifications may have more precise requirements on which messages need to be eligible for carbons delivery; such future specifications will provide their own discovery and negotiation mechanisms, such that a client negotiating Carbons using the protocol defined in this specification will cause the server to consider messages eligible for Carbons delivery based on the requirements described herein.</p>