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

Florian Schmaus flo at geekplace.eu
Tue Jul 28 09:00:23 UTC 2015

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

But having such a CSI message notification is a trivial change to CSI,
and provides a huge benefit for this use case.

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

> and do I assume
> that the use of two namespace versions is in error?

Yes assumption is correct.

- 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/0ddd44c2/attachment.sig>

More information about the Standards mailing list