[Standards] Proposed XMPP Extension: Mobile Considerations
georg at op-co.de
Tue Jul 21 11:41:16 UTC 2015
* Dave Cridland <dave at cridland.net> [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
> 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
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
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
5. XEP-0313 and XEP-0357 seem to be good additions to the "Notable
(*) 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.
|| 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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 811 bytes
Desc: Digital signature
More information about the Standards