[Standards] LAST CALL: XEP-0308 (Last Message Correction)
markybox at gmail.com
Mon Aug 13 18:46:02 UTC 2012
On Mon, Aug 13, 2012 at 12:22 PM, Kevin Smith <kevin at kismith.co.uk> wrote:
>> Anyways, if there's no particularly strong reason to have the "last" message restriction, I think it should be removed.
> The spec originally allowed previous non-last correction, and the
> community cried foul so I removed it.
> I can add it back in if the community has now changed its mind!
It's useful for real-time text situations -- it goes hand-in-hand with
transcription/caption corrections, when using instant messaging as a
conduit of transmitting transcriptions, and needing to retroactively
fix transcription errors, or manually editing voice-recognition
errors. It is a niche case, but certainly a legitimate one.
However, please bring the original people who cried foul, back into
this discussion. I'd like to see if they now agree with the use
The only thing is that you need to either:
1. Define the bounds of corrections (e.g. X messages ago)
2. Define what to do if 'id' points to a non-existent message
(i.e. refers to a message that no longer exists on recipient's client
-- this can happen in multiple login situations, reconnect situations,
MUC situations with new participants joining after a message is
For simplicity you may want to go for scenario (2) for now. Treat
unrecognized id's as a new stanza.
The only problem is that we don't really know "how many messages ago
it was" -- for example, we don't know if it was 2 or 3 messages ago --
or 6 messages ago. So corrections done in a random-access manner, and
out-of-order transmission, will show potential jumbling of order.
But that's acceptable, and potentially a client implementation could
automatically sort the 'id' parameter alphabetically, since the 'id'
is often always incrementing (either numerically or alphabetically),
though that's not always reliable.
More information about the Standards