* XEP Editor Pipeline <[email protected]> [2020-08-04 18:07]: > 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol?
Yes. > 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? No. > 5. Is the specification accurate and clearly written? Yes. Georg
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
