* Matthew A. Miller <linuxw...@outer-planes.net> [2017-02-16 18:31]: > About the only argument I'm aware of for keeping it is existing > implementations. If the namespace version bumps, that kind of > "solves" that problem.
I really don't like bumping, but as this is a privacy-sensitive matter, I think we really need to do it here. And while we are at it, I'd also love to introduce some more changes regarding MUC-PMs, namely how clients and servers should handle them. https://mail.jabber.org/pipermail/standards/2017-January/032048.html has the details, but the TL;DR is: - servers/MUC services must tag all MUC-related messages - clients must tag outgoing MUC-PMs as such - clients must ignore carbons of MUC-PMs from channels they are not joined to - servers must send Carbons for a specific subset of MUC-related messages (invitations, 'sent' PMs, not 'received' PMs) Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: Digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
