moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 02:02:16 -05:00
Code Issues Releases Wiki Activity

Merge branch 'xep-0280' into premerge

Browse Source
This commit is contained in:
Jonas Schäfer 2021-09-28 22:12:50 +02:00
commit 57f5881127
1 changed files with 10 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
xep-0280.xml
View File

@ -53,6 +53,12 @@
<email>georg@op-co.de</email>
<jid>georg@yax.im</jid>
</author>
<revision>
<version>0.14.0</version>
<date>2021-09-28</date>
<initials>gl</initials>
<remark><p>Incorporate LC feedback: Remove requirement to remove "private" elements (and add interop note), completely reword mobile considerations to fit modern reality.</p></remark>
</revision>
<revision>
<version>0.13.4</version>
<date>2021-05-25</date>
@ -330,8 +336,8 @@
<ul>
<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 contains payload elements typically used in IM (&xep0184;, &xep0085;, &xep0333;).</li>
<li>it is of type "error" and it was sent in response to a &MESSAGE; that was eligible for carbons delivery.</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 apply to MUC-related messages:
@ -466,9 +472,9 @@
<li> The sending client MAY exclude a &MESSAGE; from being forwarded to other Carbons-enabled resources, by adding a &lt;private/&gt; element qualified by the namespace "urn:xmpp:carbons:2" and a &lt;no-copy/&gt; hint as described in &xep0334; as child elements of the &MESSAGE; stanza.</li>
<li>The sending server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resources of the sender.</li>
<li>The receiving server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resource of the recipient,</li>
<li>and the receiving server SHOULD remove the &lt;private/&gt; element before delivering to the recipient.</li>
</ul>
<p>Interoperability note: earlier versions of this XEP required or recommended the removal of the &lt;private/&gt; element (albeit not of the &lt;no-copy/&gt; hint) by one of the involved servers, but this behavior was considered as a potential security issue as the sender could silently manipulate the delivery of messages, so that the requirement was lifted. However, clients MUST NOT assume that a message without the element was actually routed to all other resources of the account.</p>
<p><strong>Note:</strong>
Use of the private mechanism might lead to partial conversations on other devices. This is the intended effect.
If the private &MESSAGE; stanza is addressed to a bare JID, the receiving server still delivers it according to <cite>RFC 6121</cite>. This might result in a copy being delivered to each resource for the recipient, which effectively negates the behavior of the &lt;private/&gt; element for recipients.</p>
@ -529,7 +535,7 @@
<p>Forwarded inbound messages MUST NOT be auto-replied to unless the client has some way of ensuring no more than one auto-reply is sent from all of its user's resources.</p>
</section2>
<section2 topic='Mobile Considerations' anchor='bizrules-mobile'>
<p>Enabling this protocol on mobile devices needs to be undertaken with care. This protocol can result in additional bandwidth and power usage, possibly decreasing battery lifetime and increasing monetary costs. Additional mechanisms for controlling the Carbon-copying of individual conversations might need to be added to deal with mobile clients in the future.</p>
<p>Mobile clients are often connected to the server in parallel to another (desktop) client. Therefore, it is highly recommended for mobile clients to implement this protocol to receive all live traffic, and to generally follow the <link url="https://xmpp.org/about/compliance-suites-current#mobile">Mobile Compliance Suite</link> recommendations.</p>
</section2>
</section1>
<section1 topic='Security Considerations' anchor='security'>