> On 13 May 2016, at 14:16, Sam Whited <[email protected]> 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 <[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] > _______________________________________________ _______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
