moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-03 06:22:16 -05:00
Code Issues Releases Wiki Activity

Merge branch 'feature/xep-0280'

Browse Source
This commit is contained in:
Jonas Schäfer 2019-05-15 18:23:01 +02:00
commit 12eb7de93a
1 changed files with 38 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

46
xep-0280.xml
View File

@ -45,6 +45,19 @@
<email>linuxwolf@outer-planes.net</email>
<jid>linuxwolf@outer-planes.net</jid>
</author>
<revision>
<version>0.13.0</version>
<date>2019-04-24</date>
<initials>gl</initials>
<remark>
<p>Create more explicit and more binding copying rules under the "urn:xmpp:carbons:rules:0" namespace:</p>
<ul>
<li>Replace MAY with MUST if feature is advertised.</li>
<li>Include XEP-0085 and XEP-0184 as eligible for carbon-copying.</li>
<li>Specify explicit rules for MUC related messages.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.12.1</version>
<date>2019-03-14</date>
@ -197,6 +210,7 @@
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:carbons:2'/>
<feature var='urn:xmpp:carbons:rules:0'/>
...
</query>
</iq>]]></example>
@ -278,18 +292,34 @@
<section1 topic='Messages Eligible for Carbons Delivery' anchor='which-messages'>
<p>The focus of this specification is instant messaging applications and so those (and only those) &MESSAGE; stanzas used for instant messaging SHOULD be delivered as Carbons.</p>
<p>Defining precisely which messages are used for instant messaging and which are not is difficult, as future specifications may add additional payloads used for, or not used for, instant messaging; as such, the rules for which messages are eligible for carbons delivery is left as an implementation detail for servers.</p>
<p>The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules:</p>
<p>The following is the set of rules that a server implementation SHOULD use to determine which messages should be carbon-copied. Future specifications MAY add or override rules, though they are generally advised to <link url='#avoiding'>use the &lt;private/&gt; element</link>.</p>
<section2 topic='Recommended Rules' anchor='recommended-rules'>
<p>A &MESSAGE; is eligible for carbons delivery if it does not contain a &lt;private/&gt; child element and if at least one the following is true:</p>
<ul>
<li>A &MESSAGE; is eligible for carbons delivery if it is of type "chat".</li>
<li>A &MESSAGE; is eligible for carbons delivery if it is of type "normal" and it contains a &lt;body&gt; element.</li>
<li>A &MESSAGE; is eligible for carbons delivery if it is of type "error" and sent in response to a &MESSAGE; that was itself 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>A &MESSAGE; is not eligible for carbons delivery if it is determined to have been sent by a MUC room or service, even if it would be otherwise eligible (this also includes private messages from MUC participants).</li>
<li>A &MESSAGE; is not eligible for carbons delivery if it does not meet any of these criteria.</li>
<li>it is of type "chat".</li>
<li>it is of type "normal" and contains a &lt;body&gt; element.</li>
<li>it contains payload elements typically used in IM (&xep0184;, &xep0085;).</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>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>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 apply to 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 can not respond to carbon-copies of MUC-PMs related to a MUC they are not joined to. Therefore, they SHOULD either ignore such carbon copies, or provide a way for the user to join the MUC before answering.</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 the above is an 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>
<p><strong>Note:</strong> previous versions of this specification limited eligible messages to those of type "chat" - however, this was generally found to be inadequate due to the proliferation of type "normal" messages used in instant messaging.</p>
</section2>
<section2 topic='Mandatory Support' anchor='mandatory-support'>
<p>A server implementation can choose to advertise full support of all the rules in §6.1 by including the "urn:xmpp:carbons:rules:0" feature in its service discovery information. If that feature is advertised, the rules above must be treated as REQUIRED and not merely as RECOMMENDED.</p>
<p>Accordingly, if this feature is advertised, a client MAY rely on the server supporting this exact set of rules.</p>
<p>While future versions of this specification (or other specifications) might use a different set of delivery rules, they would signify this by advertising a namespace other than "urn:xmpp:carbons:rules:0".</p>
</section2>
</section1>
<section1 topic='Receiving Messages' anchor='inbound'>