[Standards] Move CSI to Last Call ("Proposed")
flo at geekplace.eu
Tue Jul 28 09:13:25 UTC 2015
On 28.07.2015 11:05, Dave Cridland wrote:
> On 28 July 2015 at 10:00, Florian Schmaus <flo at geekplace.eu
> <mailto: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>
> > <mailto: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
> 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.
That's why https://github.com/xsf/xeps/pull/34 adds
"CSI enabled Servers MUST send an <active/> CSI notification after
stream resumption (&xep0198;),"
"The CSI state MUST NOT be keept when a stream is resumed by means of
<cite>Stream Management (XEP-0198) § 5. Resumption</cite>;."
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: OpenPGP digital signature
More information about the Standards