[Standards] Move CSI to Last Call ("Proposed")

Dave Cridland dave at cridland.net
Tue Jul 28 09:05:51 UTC 2015


On 28 July 2015 at 10:00, Florian Schmaus <flo at geekplace.eu> wrote:

> On 28.07.2015 10:20, Dave Cridland wrote:
> >
> >
> > On 28 July 2015 at 08:22, Florian Schmaus <flo at geekplace.eu
> > <mailto:flo at geekplace.eu>> wrote:
> >
> >     On 27.07.2015 23:29, Sam Whited wrote:
> >     > Hi all,
> >     >
> >     > I'd like to propose that the Council vote to move XEP-0452: Client
> >     > State Indication into last call (the "Proposed State"), and then
> >     > hopefully into draft afterwards.
> >     >
> >     > The XEP has been sitting dormant since it was last updated almost a
> >     > year ago (2014-08-28).
> >
> >     I've talked to Matt at the Summit this year about a message
> notification
> >     send by the server to the client indicating a successful CSI state
> >     change. We agreed on the change and I sent a patch to Matt a while
> ago.
> >     But the patch was not applied since then. I've created a PR now:
> >     https://github.com/xsf/xeps/pull/34
> >
> >
> > What? Why? What can a client do in response to the information?
>
> The client knows for example that the roster presence information is
> up-to date. Basically I've an use case of a client using CSI which needs
> to take a decision based on the current presence state of the roster
> items. Imagine the following scenario: Client is in CSI inactive state,
> an external event triggers the client so that he needs to make an
> decision based on the presence state of the roster items. In order to
> get the latest presence information, the client switches to CSI active
> and waits for the queued presence stanzas to arrive. Without the CSI
> state change message notification, the client can't decide when the last
> queued presence stanza has arrived.
>
> And yes, I know that presence information can be always considered as
> outdated. Because even if you don't use CSI, the client's view of the
> presences could not reflect the state the client's roster items actually
> have.
>
> But having such a CSI message notification is a trivial change to CSI,
> and provides a huge benefit for this use case.
>
>
So switch mode and ping.


> > Also, why wrap the server notification in a message,
>
> And not using a Nonza? Because most libraries provide a mechanism for
> callbacks matching a given filter only for Stanzas. It's my impression
> as as XMPP client library developer, that we don't want Nonzas to
> trigger callbacks on the client side, as it would increase the
> complexity of XMPP client software stacks.
>
>
It's very wrong.

Consider a case where the client goes active, then switches to inactive but
loses connection and recovers via '198. The response - which is tightly
bound to the session - would indicate that the client was inactive, but
would arrive on a subsequent connection which is not inactive.


> > and do I assume
> > that the use of two namespace versions is in error?
>
> Yes assumption is correct.
>
> - Florian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150728/27503242/attachment.html>


More information about the Standards mailing list