[Standards] Proposed XMPP Extension: XMPP Compliance Suites 2016

Sam Whited sam at samwhited.com
Fri May 13 13:16:42 UTC 2016


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.

—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


More information about the Standards mailing list