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

Florian Schmaus flo at geekplace.eu
Tue Jul 28 10:48:24 UTC 2015

On 28.07.2015 11:58, Dave Cridland wrote:
> On 28 July 2015 at 10:13, Florian Schmaus <flo at geekplace.eu
> <mailto:flo at geekplace.eu>> wrote:
>     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>
>     > <mailto: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>>
>     >     > <mailto: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.
>     ?
> Either a XEP-0199 request or a XEP-0198 <r/> would typically flush the
> queue, in as much as the server is likely to flush it anyway, in the
> rare case you want to have up-to-date presence information immediately
> after switching to <active/>. Is this really every time, in every case?

The problem is not flushing the the queue, but knowing when the last
flushed stanza was received, i.e. when the stream has returned to 'active'.

> But your PR doesn't actually compel the server to flush presence state
> and have this extra non-stanza stanza act as a sentinel indicating the
> other stanzas which are not sentinels have all been sent.

Not sure what you are trying to say here. Nothing in CSI even compels
the server to queue presence for inactive clients. But it's obvious that
if a server does so, and a client switches to 'active', then the server
needs to flush the stanzas.

>     >     > 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;),"
> What does "after stream resumption" mean? You'd need to ensure it was
> sent after the replayed messages, and the client would still receive the
> <inactive/> notification message stanza. So when the client receives it,
> it needs to know to ignore it because this is only a replay.

Correct, it needs to be after <resumed/> and all replayed stanzas have
been send. Which means in the worst case, the client gets an arbitary
sequence of CSI (in)active Nonzas, followed by a final CSI active Nonza
that fixes the client's view on the CSI state after <resumed/>.

>     and
>     "The CSI state MUST NOT be keept when a stream is resumed by means of
>     <cite>Stream Management (XEP-0198) § 5. Resumption</cite>;."
> So in order to remove a special case you're adding more special cases.

Which special case do I remove? This merely tries to solve an issue with
CSI in it's current state: Either we say that CSI state is kept after SM
resumption, but then you run into the issue that you will end up in an
inconsistent way, because CSI uses Nonzas. Which means if we want to
keep the CSI state after <resumed/>, CSI needs to use Stanzas.

Or we say that the CSI state is not kept across resumption, but then we
need to specify the CSI state after resumption. Which is what I do here.

> You're also changing a Draft spec by the back door, which doesn't appeal
> to me.

Which draft XEP? xep198? Where do I change it in which way?

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

More information about the Standards mailing list