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 <[email protected]> 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 <[email protected]> wrote: >> >> On 11 May 2016 at 06:23, Thijs Alkemade <[email protected]> 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: [email protected] >> _______________________________________________ > > > > _______________________________________________ > Standards mailing list > Info: http://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > -- Sam Whited pub 4096R/54083AE104EA7AD3 https://blog.samwhited.com _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
