On Fri, Aug 10, 2012 at 8:56 AM, Kevin Smith <ke...@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
