[Standards] LAST CALL: XEP-0308 (Last Message Correction)
markybox at gmail.com
Fri Aug 10 18:31:13 UTC 2012
On Fri, Aug 10, 2012 at 8:56 AM, Kevin Smith <kevin at kismith.co.uk> wrote:
>> A MUC service might rewrite the id attribute, see
>> "Note well that for tracking purposes this service assigns a new 'id' to
>> each message it generates (here using a UUID as defined in RFC 4122)"
>> I bet some services do this... making the id at the recipient unpredictable.
> We should probably fix MUC on this - I hadn't noticed in the examples
> what was going on and read the text to mean "The id sent to the room
> may not be the id you specified" not "Everyone in the room may get a
> different id" - which will break things.
So maybe define what happens if the id is not what you expect.
This should also cover simultaneous login scenarios:
1. Login starts typing a message and sends it.
2. New participant joins
3. Login starts correcting message.
4. New participant receives a <replace> for an id that does not exist.
On the topic of simultaneous logins, don't forget to cover scenario
#2, where full JID is not available:
1. Login starts typing message, sends to MUC.
2. Simultaneous login starts typing message #2, sends to MUC.
3. Login starts doing message correction, it now refers to a message 2
messages ago. (id is valid).
So what you need to do, is essentially specify that unrecognized or
unhandled 'id' should mean <replace> should be ignored and the
re-transmitted message displayed as a brand new message. Probably the
More information about the Standards