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

Dave Cridland dave at cridland.net
Tue Jul 28 09:58:29 UTC 2015


On 28 July 2015 at 10:13, Florian Schmaus <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>> 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.
>
> ?
>
>
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?

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.


> >     > 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. Now we need to
distinguish '198 resumption replay stanzas from normal stanzas, in order to
avoid the stanzas affecting the client's perception of stream state. Except
now the CSI active non-stanza stanza acts as a sentinel here, meaning that
it's serving double duty. Only we have to track whether the extension was
in use at all in the previous stream in order to know whether to send it or
not.


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

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

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150728/e76facdc/attachment.html>


More information about the Standards mailing list