Hi Marvin, * Marvin W <x...@larma.de> [2019-07-24 22:02]: > > Referencing messages
I agree with all that you wrote about XEP-0372, and I suppose the only reason it gets referenced so often in these discussion is because it's inadequately titled "Message References". > On the contrary, XEP-0367 does not suffer from any of these issues. That's a great catch. I actually think that 0367 is a perfect match for Reactions, even though I consider it to be too specific for the problem of generic message association - it is not well-suited for: - Delivery Receipts - Last Message Correction (do you attach a correction to the original?) I don't see the Business Rules of 0367 as a problem here - I'm pretty sure they don't interfere with Reactions, and we could change them if they do anyway. > Another alternative that I'd like to propose is to not mix server > processing information ([...]) with client and message information. I think this is opening a can of worms, because as a sender, you end up adding multiple elements with the same semantic meaning (this message belongs to X). A malicious client could start gaming implementations by adding different references to the different elements. > I am happy to work any of these three possibilities into a XEP > (modification) proposal, if there was consensus which is best. I think that the issues inside of 0367 are outside of your scope and should be solved by its authors/the Council, and that it would make very much sense to use the 0367 attach-to element in Reactions. > > Backward compatibility > > That said, I support Florians suggestion to gather some implementation > experience first and decide on a more specific business rule afterwards. Yes, let's go on with that. Nothing I have read so far got me convinced, but this is not a blocker for moving to Experimental. > > Correcting reactions > > There are two main reasons for me to not use XEP-0308. First (according > to its specification) it only can be used for the last outgoing message. You can well supersede that rule in your XEP by saying that LMC can be applied for Reactions without any time / history constraints. That said, I accept your arguments, and I'd be fully OK with LMC only getting used for the backward compatibility part of Reactions. > > Limitation to Emoji > > I think the current specification is open enough to allow future > extension of what a reaction is. My issue is with TR51 being a living standard, which will inevitably cause implementations to disagree on what is valid and what is not. If you want a demonstration of the (arguably worst-case) effect of this, try to join a large public MUC with a nickname of "🤖" (U+1F916 Robot Face), and then send a message there. This is why I had a hard time with this specific statement: | Receiving entities MAY ignore <reaction> elements that do not comply | with this specification. > By having the reaction as a text and not as an attribute, future > versions of the XEP could allow for other elements including XEP-0231 > images inside the <reaction> element. But then you'd want to have a backward-compatible emoji text inside of <reaction> anyway, to accommodate the first generation of Reactions clients ;-) > I hope that, despite the valid discussion points, we can advance with > the standardization process of Reactions as fast as possible. At Dino, > we prefer to not implement any non-standard behavior on the master 😉. None of my points was blocking the acceptance of Reactions as an Experimental standard, but you'll have a hard time convincing me on the backward compatibility issue, if you want to get it into Draft fast. Kind regards, Georg
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
