1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00

XEP-0308: relax from-full-JID requirement

This commit is contained in:
Georg Lukas 2019-04-17 07:35:10 +02:00
parent 3ea8b92714
commit fe8a1ad143

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 are received from the same full-JID.</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>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>