Am So., 25. Nov. 2018 um 23:47 Uhr schrieb Florian Schmaus <f...@geekplace.eu>: > > On 22.11.18 18:07, Daniel Gultsch wrote: > > Am Mi., 14. Nov. 2018 um 19:52 Uhr schrieb Georg Lukas <ge...@op-co.de>: > >> * Jonas Schäfer <jo...@wielicki.name> [2018-10-20 13:55]: > >> > >> A point that I brought up back then, and that I think needs to be added > >> in §2.2 is this: > >> > >> | The message sender MUST set the stanza's @id to the same value as the > >> | origin-id. > >> > >> The example should be changed accordingly. > >> > >> There is really no drawback in specifying that (as a MUST, or at least a > >> SHOULD), and there is a huge amount of pain and madness later down the > >> road if we don't mandate it. In my eyes, this is the only reasonable way > >> to move forward. > >> > >> Therefore I change my vote to -1 unless the above statement is added > >> with either a SHOULD or (preferrably) a MUST. > > > > I raised the some concerns multiple times on I’m also -1 on that > > before this addressed. > > Especially since I don’t see a reason for *not* doing this even if > > some people thing it is not needed. > > > Thanks Daniel and Georg for you feedback. > > The requests to require both values to be equal have always been very > vague: No actual arguments were given why that would be beneficial. > Maybe I missed them, and I'm sorry if that is the case. I looked into my > notes, which I keep for every XEP I care about or I am personally > involved in, but could not find any records regarding the potential > upsides of doing so. Also, a quick search for the previous discussion of > this topic yielded no results (*Summoning Zash* because I could bet > there was such a discussion). > > On the other hand, there are reasons against: > - origin-id is entirely unrelated to the stanza id attribute > - it adds another rule to the XEP, hence increasing its complexity > - even if we would mandate it, you are not guaranteed that you will > receive stanzas where origin-id is the same value as the stanza id > attribute because - of MUC id rewrite (yes I know of the latest changes > to XEP-0045) > - because there may be XEP-0359 implementations which do not do it > (unless you want a namespace bump) > > I am happy to be convinced that your suggestion improves the XEP and the > XMPP ecosystem as a whole. But I also hope that it is understandable > that it is hard for me to become convinced of a change without providing > any arguments in favour of the particular change. Arguments that could > put weight in against the counterarguments.
If origin id and message id are the same and I react to it (message correction, read marker, delivery receipt) then I can use the origin id in my reaction and don’t care that a muc serice or who ever has rewritten the message id and you’ll still be able to know what message I’m refering to. By setting origin-id==message-id you do not introduce ambiguity into which of those ids should be used for #whatever. Also if I’m storing the origin id/message id for de duplication purposes I don’t have to store two ids In Conversations code I only track on ID for reactions, dedubbing purposes. (origin-id trumps message-id) I believe that what ever purpose you thought out for the origin-id is better served if message-id==origin-id unless it doesn’t serve a purpose at all - Or I’m not understanding the purpose of the origin-id. That might be the crux here by the way. What is the purpose of the origin-id? cheers Daniel _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
