I think there may be some confusion and we're not even disagreeing about the same things; so, I'll state my thoughts more clearly.
The original sender of a message stanza SHOULD give it id=UUID. Unfortunately, this wasn't a requirement in the RFCs, so now we have various hacks to try to deal with that because we can't just fix the problem while maintaining compatibility. In the case of MUC messages, the original sender IS the MUC, and not the client. The client sends its message to the MUC, and that message SHOULD have its own unique id, but the message which the MUC forwards to participants SHOULD be a new message with its own new unique id. But the client wants to cross-reference the message it sent with the one it receives, and so the MUC SHOULD also insert an origin-id with the client's original message id (only in the message it forwards to that client.) Now, the above SHOULDs are my own preferences for an ideal world where we could have nice things, whereas in reality we maintain compatibility and add 'just one more' id in the hope it solves things. In the above ideal world, MUC message ids can't be spoofed because they are assigned by the MUC itself. The MUC doesn't even need to care what id a client used because it assigns its own new id to any messages it sends - if a client does duplicate one then it only confuses itself in the origin-id (and nobody else sees that.) I understand that is effectively what you're trying to address with stanza-id, and it is a valid solution. What I'm less sure of is the benefit 'by' actually brings in practice. If there are multiple stanza-ids then it obviously serves to differentiate them, but why the need for multiple? The client's id is the origin-id (so it can cross-reference with its archive) and the MUC's id is the stanza-id (so it can be referenced for reactions, etc.) Carbons shouldn't need yet another id.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
