[Standards] Proposed XMPP Extension: XMPP Compliance Suites 2016
me at thijsalkema.de
Wed May 11 05:23:16 UTC 2016
> On 11 mei 2016, at 00:09, Matthew Wild <mwild1 at gmail.com> wrote:
> On 10 May 2016 at 20:28, Thijs Alkemade <me at thijsalkema.de> wrote:
>>> On 28 apr. 2016, at 08:35, XMPP Extensions Editor <editor at xmpp.org> wrote:
>>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>> Title: XMPP Compliance Suites 2016
>> I don't really understand the point of CSI being required for Advanced Client.
>> Do non-mobile clients have to implement it and never send <inactive/>? Or do
>> servers have to disable all optimizations because enabling CSI is no longer an
>> implicit "I'm a mobile client with my screen off"?
> I don't think there's anything that makes CSI mobile-only. If I had a
> laptop on battery and tethered, I would care about the resource
> consumption of my desktop client as much as I'd care about a mobile
> client. I would expect it to send <inactive/> when all its windows are
> hidden (e.g. minimized) or if my computer screen is locked, etc.
Lets look at the suggested optimizations from the XEP:
> Suppress presence updates until the client becomes active again. On becoming
> active, push the latest presence from each contact.
This only makes sense if the client has no way to show when someone was last
online and if it doesn't notify of users signing on (even when the screen is
off there might be a sound notification).
In a MUC, you'll miss someone joining and immediately parting. If you are a
moderator that can be a security issue because you won't know their real JID:
someone could join with an offensive nick and as long as they part quickly
enough they can't be banned.
> Discard messages containing only Chat State Notifications (XEP-0085) 
I don't see how this is a good idea either unless you don't implement Chat
State Notifications in the receiving client: if I get a <composing
xmlns='http://jabber.org/protocol/chatstates'/> but not the following
<inactive xmlns='http://jabber.org/protocol/chatstates'/> someone might show
up as "Typing..." for hours. Do I have to reset all chat states when
> Defer or discard unimportant PEP notifications, possibly unsubscribe from
> certain PEP nodes until the client becomes active again.
I'm not familiar enough with PEP to really understand the implications of
this, but this too sounds like something the server should interfere with
without the client knowing exactly what's happening.
I think the XEP would be valuable for every client if it only alled the server
to delay stanzas for a short while and bundling them, but that's not the case.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Standards