On Sat, 2023-02-25 at 11:35 +0100, Florian Schmaus wrote: > What I tried to express is that changing the semantics of the RFC > 'id' > attribute in a new RFC is not a viable solution. Simply because you > still need to operate with older implementations that do not follow > the > newer RFC. Hence I believe adding this via origin-id is better. >
You seem to be under the assumption that messages created by clients following the rule that the id-attribute must be unique are indistinguishable from messages of clients that don't and thus suggest to use <origin-id id=unique-id /> as a distinguishing functionality (although an element <unique-id/> that just signifies that the id in the id-attribute is unique would suffice as well). I would expect that there will be other means to distinguish those. If we do a new XMPP RFC, we might look into revisiting things like having two namespaces (for s2s and c2s) and similar other things. Basically really looking into what other issues we have on the RFC layer of XMPP and also which features we currently have in XEPs should become part of the RFC. And once it's possible to detect an XMPP 2.0 client, you also know that it followed the unique id principle. > That is true. However, this discussion made me realize that origin-id > may be a necessity to reference stanzas in 1:1 chats. Doing so would effectively mean that referencing stanzas from clients without origin-id would not be possible. However, I don't think current popular clients sends origin-id in direct chats and also all current references don't rely on origin-id (they often optionally support using origin-id when present though). Migrating to requiring origin-id would thus not only cause issues with very old legacy clients with non-unique id-attribute behaviors, but rather cause issues with all the clients we use today. Given that we don't see a lot of issues with weird legacy clients in direct chats in production today (while technically relying on them not reusing their id attributes), this seems like a weird move: breaking compatibility with current clients (the majority) under the premise to improve compatibility with old legacy clients without actually solving any real-life issues. Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
