|Summary:||XMPP Compliance Suite 2016|
|Component:||gabble||Assignee:||Telepathy bugs list <telepathy-bugs>|
|Status:||NEW ---||QA Contact:||Telepathy bugs list <telepathy-bugs>|
|Priority:||medium||CC:||daniel.scharon, nickbroon, sam, scott|
|i915 platform:||i915 features:|
|Bug Depends on:||36804, 46700, 74990, 78093, 90838|
Description diane 2016-07-13 20:21:16 UTC
The XMPP foundation published http://xmpp.org/extensions/xep-0375.html listing what the recommended extensions a client should support are for 2016. * 2016 Core * I think we probably support Core client for 2016. As for advanced client we have the core needed to support PEP (XEP-0163), but I think we only have support for the Location PEP (XEP-0080) protocol. It might be nice to have some kind of plug-in system to provide protocol and UI support for more protocols built on PEP. * 2016 Web * [Core] RFC 7395 (XMPP over websocket) https://bugs.freedesktop.org/show_bug.cgi?id=94239 [ ] BOSH (XEP-0124) https://bugs.freedesktop.org/show_bug.cgi?id=30911 [ ] XMPP Over BOSH (XEP-0206) I'm a bit surprised people want to use web protocols from a desktop client, but apparently some do. * 2016 IM Compliance * Here's where we're lacking, we have RFC 6121 and Multi-User Chat but that's it. We still need: [Core] Message Carbons (XEP-0280) https://bugs.freedesktop.org/show_bug.cgi?id=78093 [Adv ] Blocking Command (XEP-0191) https://bugs.freedesktop.org/show_bug.cgi?id=36804 [Adv ] Bookmark Storage (XEP-0048) https://bugs.freedesktop.org/buglist.cgi?quicksearch=xep-0048&list_id=586053 [Adv ] Stream Management (XEP-0198) https://bugs.freedesktop.org/show_bug.cgi?id=46700 [Adv ] Message Archive Management (XEP-0313) https://bugs.freedesktop.org/show_bug.cgi?id=90838 I think message carbons, blocking command, and stream management can be implement with the current telepathy spec. I'm less sure about bookmark storage and I think message archive management needs improvements to the spec. * 2016 Mobile Compliance [Core] Stream Management (XEP-0198) https://bugs.freedesktop.org/show_bug.cgi?id=46700 [Core] Client State Indication (XEP-0352) [no bugs yet] [Adv ] Push Notifications (XEP-0357) [no bugs yet] Telepathy has been used in a mobile context with Jolla, Plasma Mobile, and maybe Ubuntu Mobile, so it's probably worth trying to implement at least mobile core. I'd like to see pretty much all of the 2016 IM advanced client implemented.
Comment 1 diane 2016-07-13 20:27:58 UTC
I add "depends on" for all of the IM advanced client bugs. The most important mobile XEP (0198) is in the IM advanced client recommendation anyway. Also I copied the wrong URL for it should be Bookmark Storage (XEP-0048) https://bugs.freedesktop.org/show_bug.cgi?id=74990
Comment 2 George Kiagiadakis 2016-07-14 04:44:14 UTC
Thanks for summing it up. I'm raising the severity, as I think that modern XMPP compliance has a big impact on the userbase and we need more users to stay active and relevant
Comment 3 diane 2016-07-14 07:24:50 UTC
Also for staying relevant we probably also want to work on having some kind of end-to-end encryption implemented. I know KTP has OTR support through a clever dbus proxy, it might be possible to get Empathy to take advantage of it. Though theres a social issue with the OTR proxy in that it's in ktp-common-internals so depends on Qt and thus some Glib / GNOME people might not want to install it. There's OpenPGP (XEP-0373, XEP-0374) and OMEMO (Conversations proposed XEP) which are more XMPP specific, but as encryption wasn't listed in the 2016 XMPP Compliance XEP, I didn't add them to this bug. Also I think ad-hoc commands and a jabber forms UI for things like ad-hoc commands and muc configuration would also be a nice thing to have.
Comment 4 ruff 2016-12-30 12:05:45 UTC
I'm sure XEP-0357 will also be very handy for mobile clients. It's also very simple to implement on client side (literally just add a call which triggers csi message - nothing more). All the job is done on the server side - suppress/discard/defer while inactive - and redeliver when state flips back. Delivery will then be driven by client's power-management cycle which would resemble server push mechanics. The rationale - to prevent TCP being dropped (timeout) or waking up the handheld unnecessarily. Dropped TCP may partially be mitigated by XEP-0198 and connection resumption - but that one is much harder to implement on both client and server side (need to preserve state and recover it for new connection).
Comment 5 ruff 2016-12-30 12:33:20 UTC
sorry, XEP-0352 (Client State Indication) of course