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

XEP-0308: incorporate Council feedback, remove dep on #736

Browse Source
This commit is contained in:
Georg Lukas 2019-04-24 07:16:19 +02:00
parent fe8a1ad143
commit 171db7f20d
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0308.xml
View File

@ -96,7 +96,7 @@
<p>To deal with multiple payloads, the sender MUST re-send the entire stanza, only altering id and the payloads being corrected and adding the 'replace' payload. It is expected that the receiver SHOULD then treat the new stanza as complete replacement for all the payloads received in the original stanza.</p>
<p>The Sender MUST NOT include a correction for a message with non-messaging payloads. For example, a sender MUST NOT include a correction for a roster item exchange request or a file transfer part.</p>
<p>A single message may be corrected multiple times by subsequent edits.</p>
<p>A correction MUST only be allowed when both the original message and correction originate from the same sender<note>In direct conversations, this means the bare-JID must match the original bare-JID, in MUCs and MUC-PMs the correction's full-JID must match the original full-JID, and either the recipient or the MUC service need to ensure that the real bare JID of the sending occupant didn't change in between.</note>.</p>
<p>A correction MUST only be allowed when both the original message and correction originate from the same sender<note>In direct conversations, this means the bare-JID must match the original bare-JID, in MUCs and MUC-PMs the correction's full-JID must match the original full-JID, and the recipient needs to ensure that the real bare JID of the sending occupant didn't change in between, e.g. by keeping track of leave/join presences.</note>.</p>
<p>While it's not possible to prevent this protocol from being used in such a way, it is not intended that it provides a way to continue expanding a previous message indefinitely and clients, in as much as it is sensible, should present use of this extension only for correction rather than for providing a continuous stream, for which &xep0301; can be used instead.</p>
<p>Correction MUST only be used to change the details of a stanza (e.g. the message body) and not to change the nature of the stanza (e.g. correction MUST NOT be used to turn a chat message into a pubsub notification)</p>
<p>While it is possible to use this protocol to correct messages older than the most recent received from a full JID, such use is out of scope for this document and support for this SHOULD NOT be assumed without further negotiation.</p>