30 Aug
2026
30 Aug
'26
12:54 p.m.
* Dave Cridland <dave(a)cridland.net> [2026-08-30 18:34]:
Indeed, I meant '308. Seems like I had too many XEP tabs open at the
same time in my head.
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.
While my wording was indeed HUMOROUS, the wording in '424 should be
corrected.
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.
I would
strongly advise to also add a XEP-0313 LMC element to the
retraction message:
But I think you mean XEP-0308. Adding LMC
would have two benefits: [...]
That seems reasonable, though Retraction has no "Last" constraint. LMC
probably should be AMC, or at least PMC. 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? 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. 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