[Standards] LAST CALL: XEP-0352 (Client State Indication)

Georg Lukas georg at op-co.de
Mon Aug 10 13:38:45 UTC 2020

* XEP Editor Pipeline <xep-editor-pipeline at zombofant.net> [2020-08-04 18:07]:
> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?


> 2. Does the specification solve the problem stated in the introduction
> and requirements?

Partially. The XEP omits explicit requirements on how a server should
optimize traffic, so an implementation that just consumes the CSI
commands would be perfectly conforming.

The lack of guidance has led to the creation of some tribal knowledge
of what can and what shouldn't be optimized. For one widely-used server
implementation there are multiple extension modules that implement
slightly different optimization techniques, resulting in inconsistencies
of behavior. Also, somebody who wants to implement this specification is
in for a rough ride, learning the hard way that e.g. you can suppress
presence updates to an inactive client, but you shouldn't suppress the
join presence for the client joining a MUC, or the join would timeout.

I see significant value in formalizing this tribal knowledge, even with
non-mandatory language, ideally inside of this XEP (or in an addenum
XEP, for lack of a better vehicle).

> 3. Do you plan to implement this specification in your code? If not,
> why not?

Implemented it in yaxim back in 2014 (using legacy google:queue
signaling), and switched to CSI in 2018.

> 4. Do you have any security concerns related to this specification?


> 5. Is the specification accurate and clearly written?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200810/cee1b482/attachment.sig>

More information about the Standards mailing list