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

Florian Schmaus 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
>     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.

That's why https://github.com/xsf/xeps/pull/34 adds

"CSI enabled Servers MUST send an <active/> CSI notification after
stream resumption (&xep0198;),"

and

"The CSI state MUST NOT be keept when a stream is resumed by means of
<cite>Stream Management (XEP-0198) § 5. Resumption</cite>;."

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150728/d37890d3/attachment.sig>


More information about the Standards mailing list