* Dave Cridland <dave@cridland.net> [2026-08-30 18:34]:
I would strongly advise to also add a XEP-0313 LMC element to the retraction message:
But I think you mean XEP-0308.
Indeed, I meant '308. Seems like I had too many XEP tabs open at the same time in my head.
Adding LMC would have two benefits: [...]
That seems reasonable, though Retraction has no "Last" constraint. LMC probably should be AMC, or at least PMC.
Yes, and every implementation has a different understanding of "last", but a receiving client refusing to apply the fallback LMC for an unsupported retraction would be merely a cosmetic issue.
The "must" is in contradiction with the "SHOULD" quoted above from §3, and with the next paragraph which describes what you MAY do if you CAN'T do what you MUST do:
Yes, this does seem to stray from RFC 2119 to RFC 6919, doesn't it?
While my wording was indeed HUMOROUS, the wording in '424 should be corrected.
There is a certain latency between sending the original message and receiving the reflection that contains the <stanza-id> element required for a retraction. For a groupchat message sent over a bad network link or right before leaving network coverage, the user might be blocked from retracting for many minutes.
Understood, however unless the user knows they're losing network coverage, they're not going to be able to retract for several minutes anyway.
Well, I'd like to allow the user to preform the retraction even when currently offline, and the client would have to cache the respective stanza in its '198 queue, except it can't generate the retraction before receiving the reflection. So the client would have to store a meta-retraction in some other buffer.
Unless you can send a stanza without any network coverage at all, and if you know how, please tell me as it's very germane to my current research...
Aside of RFC 1149, it makes sense for a client to let the user write messages, correct them, and even retract them, while offline. Georg