From 171db7f20dc4415cf3286eec2fb4f0b96c36315a Mon Sep 17 00:00:00 2001 From: Georg Lukas Date: Wed, 24 Apr 2019 07:16:19 +0200 Subject: [PATCH] XEP-0308: incorporate Council feedback, remove dep on #736 --- xep-0308.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0308.xml b/xep-0308.xml index b84c455f..711a7276 100644 --- a/xep-0308.xml +++ b/xep-0308.xml @@ -96,7 +96,7 @@

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.

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.

A single message may be corrected multiple times by subsequent edits.

-

A correction MUST only be allowed when both the original message and correction originate from the same senderIn 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..

+

A correction MUST only be allowed when both the original message and correction originate from the same senderIn 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..

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.

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)

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.