[Standards] Proposed XMPP Extension: XMPP Compliance Suites 2016

Dave Cridland dave at cridland.net
Fri May 13 08:11:36 UTC 2016

I think most of these are highlighting issues with CSI, rather than issues
with including CSI within the Suite. Mostly, I think CSI is right - my
biggest gripe was always that it didn't include an <enhance/> element - but
it's clear to me that there's a few edge-cases and clarifications needed.

On 11 May 2016 at 11:40, Matthew Wild <mwild1 at gmail.com> wrote:

> 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.
Indeed - I think if you want to have a client that shows the last online
state, you want to show that instead of tracking presence stanzas
continuously, and if you really want all the traffic, then don't use 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.
This case in particular is a general shortcoming in MUC - we cannot access
historical joins and leaves. It's been addressed in MIX, I think, already.

> >> 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.
I cannot find such a requirement in XEP-0352. I think it's absolutely the
right requirement - if you're planning on discarding stanzas, you need to
ensure you know the client's view for the state it affects, and the current
state, and ensure that such stanzas are replayed in order to update the
client to the right state.

Loosely, it means I agree with both Thijs and Matt, but not the spec.

> >> 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 suspect it'd be useful to have a way to mark stanzas (a XEP-0344 hint?)
such that they're either discardable or deferrable explicitly - or maybe
discardable and non-deferrable. Certainly not all PubSub nodes can be
deferred or discarded, and I'm not even sure all PEP ones can be.

> > 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).
I think that's right.

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

I think this is right, but under-specified in the XEP currently.

> Regards,
> Matthew
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160513/c447e8c9/attachment.html>

More information about the Standards mailing list