[Standards] LAST CALL: XEP-0308 (Last Message Correction)

Mark Rejhon 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
>> http://xmpp.org/extensions/xep-0045.html#message
>> "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
simplest solution.

Thanks,
Mark Rejhon



More information about the Standards mailing list