* Dave Cridland <[email protected]> [2015-07-21 12:52]: > However, I expected this to be a (sorely-needed) major edit to XEP-0286, > which I wrote some years ago and has lagged behind the times. For the > record, I'm perfectly happy to completely hand over authorship of that > specification to Sam.
I would also favor merging the two documents, and keeping the 0286 number. > I'd be very interested in hearing any opinions on this one. I would like to see multiple things covered in more depth by the new/merged XEP, especially by providing more specific suggestions to the poor implementors: 1. Compression: The text leaves the reader in a suspended state: some kinds of compression are evil, others are ineffective. If possible, please do some benchmarks of the stream compression with stanza-level flushing and provide the results of that, as well as a strong recommendation how to handle the whole issue. This point might be one for a wider debate, but the results should be placed into this XEP. (I'm not sure if we should have a debate about how far we can compromise security / provide alternative mitigations for the data leakage in order to get more effective stream compression on mobile) 2. LTE vs. 3G: Modern handsets (and most Telcos) roam between different protocols depending on coverage. This can not be detected by the XMPP server, and is probably very hard to detect by the mobile client (some devices provide a protected API). Therefore, implementation advice should not assume an LTE link but also mention the older protocol generations. 3. Ping intervals and timeouts: please provide hard numbers for the ping intervals and ping timeouts to be implemented by servers and clients. From practical experience I would suggest both sides to send a ping after no data was received for 25~29 minutes(*), and to use a ping (response) timeout of at least 60 seconds. I am open for different numbers from other people though. 4. Connection interruptions: LTE handsets without VoLTE downgrade to 3G or 2G on incoming/outgoing phone calls. This can lead to immediate termination of all TCP connections, with no way to cleanly close the XMPP session. XEP-0198 allows for a clean resumption after the phone call has ended, unless the call takes longer than the 0198 session timeout. There is currently no sane workaround for that, but it should be mentioned as something that mobile client developers need to consider in their designs. In the future, we might be able to use XEP-0310 PSA to let the server tell the user's buddies that he's actually gone (0198 zombie state) and keep the 0198 state for a longer time without compromising usability. 5. XEP-0313 and XEP-0357 seem to be good additions to the "Notable Extensions" list. (*) Somebody, some time ago, told a story that a big manufacturer of bitten smartphones convinced mobile telcos to set the CG-NAT timeouts to at least 30 minutes to allow for sensible push service support. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: Digital signature
