On 04.10.2017 09:01, Georg Lukas wrote: > * Florian Schmaus <[email protected]> [2017-09-23 11:22]: >> I think I don't understand the benefits from Georg's suggestion, so >> currently one reason against is that it adds more complexity without any >> gain from my PoV. > > I would argue that it reduces complexity by decreasing the number of > "unique" message IDs attached to a given message from three to two. > > As a client developer, I want to have as few places as possible to look > for a message ID, so stanza-id >> origin-id >> stanza id (*). > > (*) stanza-id = XEP-0359 <stanza-id/> element > stanza id = 'id' attribute of the message stanza
I don't see an alternative "search for <origin-id/> first and fallback to the 'id' attribute of the stanza" to get an ID for de-duplication. >> Plus what you said: The scheme will break as soon as the MUC service, or >> any other service doing some sort of reflection, rewrites the 'id' >> attribute of the stanza (which MUC services are allowed to, and are the >> reason for xep359 existence in the first place). > > There are also MUC implementations (read: transports) that strip away > non-body elements from reflected messages. Of course there are, but with the current wording you have at least no <origin-id/> (or <stanza-id/>) at all. Also it is discoverable if a MUC service will not strip the xep359 extension elements by checking for the xep359 disco#info feature. But if we go with what you suggest, we could end up with a <origin-id> with a different stanza-id than the 'id' attribute of the message stanza, which would violate your rule. I think that causes more confusion and complexity, not less. > Other XEPs, like LMC and References, use the stanza id as a reference. I > assume that MUCs will not rewrite the stanza id in the payload, thus > breaking those XEPs. By enforcing origin-id = stanza id we can at least > fix this particular problem on clients that support both LMC/Reactions > and 0359. I don't follow. How do which XEPs break? Which problem are you talking about? - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
