> It sounded to me like this would be a new distinct namespace > older-than-previous-message corrections, a namespace bump may be more > contentious in a draft XEP.
That was my original expectation too, but Kev suggested the bump would be preferable. > As I see it, the *worst* thing that will happen if we allow > Last-Message-Correction to affect also the last-but-N messages, is: > Clients which implement the LMC spec strictly will display the update as a > new message, instead of as a correction of the old one. I did mention it already, but I'm not sure this is completely true. The protocol itself functionally supports Recent Message Correction (RMC) without modification, but without a way to differentiate between the two, LMC clients may silently drop RMC messages, rather than blindly append them as new messages. Upon receiving an RMC message, an LMC client would check whether the ID matches its last message and see that it doesn't -- the first business rule suggests that means it is a correction to a message directed to another resource, and so this client would quietly eat the message (because the correction is for another resource.) So, assuming I'm understanding that correctly, it needs cleaning up and the bump is necessary to avoid silently dropping messages.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
