After carefully reading the current text again, I noticed that there is conflicting use of requirement keywords: - In section 3, "It's RECOMMENDED that you include fallback text in the <body/>, so that servers will archive the retraction and non-supporting clients can still indicate that there was an intent to retract." - In section 6.1, "senders MUST set fallback text that describes the retraction" I guess the intent of 6.1 is to disallow fallback text that does anything else than describing the retraction, aka. "senders MUST NOT set fallback text that describes anything beyond the retraction". That said, this doesn't make sense in security considerations: recipients can't base their security assumptions on the fact that something is forbidden for the sender through specification. I also am conflicted about the RECOMMENDED in section 3. or clarification, RECOMMENDED is the same as SHOULD, meaning there may exist valid reasons in particular circumstances to ignore this requirement. I would rather think the other way: there may exist valid reason to have a fallback in particular circumstances (e.g. in closed environments or when for some reason you know about the recipients setup, you can have a message "Upgrade to version x.y to correctly process messages in this chat"), but the default should be to not do it, especially if you consider a far future where every client implements this specification and thus no client would be using that fallback. Making a fallback a SHOULD is IMO inherently wrong. The fallbacks I have seen (and the one in the example) are telling the recipient that the sender intended to retract some message (without specifying which one) but that it didn't work because the client is not supported. Often this message is sent without encryption in an encrypted chat (causing the recipient to display a warning) and in English language (which may not be a language the recipient can understand). For the recipient user, this message is completely useless: It doesn't tell them the intended action of the sender in a sufficient way and it doesn't tell them how they can fix the situation of things not working. In practice, the only use of these fallback is to make people unhappy. [1] Dino current implementation does not send a fallback, no matter the circumstances. There seem to be absolutely no negative implications. We are considering to add a fallback body (in the realm of just "*Message deleted*") if, and only if, the deleted message is the very last message in the chat, and then we would also add a matching <replace />. This gives a good fallback UX for recipients that support XEP-0308 and a less useless fallback UX for those that support neither. Marvin [1] Anecdotal evidence from just a few days ago, in German: https://friendica.sokoll.com/display/74fe3dc8-336a-9c7e-a1dc-e0e344732034 On Fri, 2026-08-28 at 12:31 +0200, Marvin W. via Standards wrote:
On Fri, 2026-07-03 at 12:15 +0000, Daniel Gultsch wrote:
This message constitutes notice of a Last Call for comments on XEP-0424.
Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted.
URL: https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on 2026-07-20.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Yes. The intent and semantics of retracting is clearly different from message edit/correction and receiving entities might be willing to handle them differently.
2. Does the specification solve the problem stated in the introduction and requirements?
Yes.
3. Do you plan to implement this specification in your code? If not, why not?
Yes, already implemented in non-release version of Dino.
4. Do you have any security concerns related to this specification?
No. (except what is made very explicit in the specification already)
5. Is the specification accurate and clearly written?
Yes. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org