[Standards] Proposed XMPP Extension: XMPP Compliance Suites 2016

Matthew Wild mwild1 at gmail.com
Wed May 11 10:40:21 UTC 2016

On 11 May 2016 at 06:23, Thijs Alkemade <me at thijsalkema.de> wrote:
> 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).

I find those sound notifications for the several hundred people on my
roster quite annoying :)

If you permanently want to be connected with the latest status of your
contacts, then sure, you're never going to want to mark yourself as
inactive with CSI.

> 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.

If the server discards presence, and in particular MUC presence. This
isn't dictated by CSI.

>> Discard messages containing only Chat State Notifications (XEP-0085) [2]
>> payloads.
> 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
> deactivating CSI?

No, I don't think the client should have to make any such changes as a
result of implementing and using CSI. It's up to the server to
maintain protocol consistency if it performs such optimisations.

>> 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.

Again, it's up to the server to be sensible here. I don't think there
would be any problem in filtering e.g. the constant flow of User Tune
notifications while I have my client closed, for example.

> 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.

I feel bad arguing these specific points with you, because I
originally didn't want the XEP to mention them at all. However that
made people feel too uncomfortable ("the server could do anything!").
As far as I'm concerned, CSI is about a mechanism for the client to
inform the server that the client is not "active" (which means
different things on different computing platforms).

What the server does with that information is up to the server. If it
does things that break the protocol and break the client, it's a
broken server.


More information about the Standards mailing list