[Standards] Proposed XMPP Extension: XMPP Compliance Suites 2016

Kevin Smith kevin.smith at isode.com
Fri May 13 13:33:00 UTC 2016


> On 13 May 2016, at 14:16, Sam Whited <sam at samwhited.com> wrote:
> 
> As a compromise, perhapse it makes sense to split CSI out into a
> separate "Mobile Compliance" section? This might be something good to
> have in general.
> 
> Thoughts appreciated.

I think that might be reasonable. I certainly have some issue with including it in the generic client list (Matt’s use case seems valid, but is also moderately specialist).

/K

> 
> —Sam
> 
> On Fri, May 13, 2016 at 3:11 AM, Dave Cridland <dave at cridland.net> wrote:
>> 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
>>> _______________________________________________
>> 
>> 
>> 
>> _______________________________________________
>> Standards mailing list
>> Info: http://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
>> _______________________________________________
>> 
> 
> 
> 
> -- 
> Sam Whited
> pub 4096R/54083AE104EA7AD3
> https://blog.samwhited.com
> _______________________________________________
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________



More information about the Standards mailing list