Am Do., 6. Juni 2019 um 09:09 Uhr schrieb Georg Lukas <ge...@op-co.de>:
> 1. Tracking of CSNs in the sending clients and suppressing display of > the bounces. That requires additional logic and (potentially persistent) > tracking of ephemeral message IDs, or some other ugly hacks like > encoding the ephemerality into the ID, and it doesn't work over multiple > clients. I never liked the behaviour of some clients that would simply show error messages without any context whatsoever in the chat window. I prefer clients that track actual messages and mark individual messages as failed. You would usually track messages for 'delivery' and 'read' anyway. So failed is just another message state. > > 2. Mandating that the bounce MUST contain the original bounced message > (this is optional as per the RFC), so that the client can suppress the > error in a state-less way. That will also work better if the original > CSN is not carbon-copied to the sender's other devices, but the error > is(*). Regardless of me preferring (1) as a solution in terms of UX bouncing the entire error message can come in handy in some instances. I remember discussions around MUC push. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
