mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 08:45:04 -05:00
XEP-0286: Retab and rewrap
This commit is contained in:
Sam Whited
parent
09627a4ef6
commit
4ba979c91f
520
xep-0286.xml
520
xep-0286.xml
@ -1,262 +1,274 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Mobile Considerations</title>
|
||||
<abstract>
|
||||
This document provides background information for XMPP implementors
|
||||
concerned with mobile devices operating on an LTE cellular network.
|
||||
</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0286</number>
|
||||
<status>Experimental</status>
|
||||
<type>Informational</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>NOT_YET_ASSIGNED</shortname>
|
||||
<author>
|
||||
<firstname>Dave</firstname>
|
||||
<surname>Cridland</surname>
|
||||
<email>dave.cridland@isode.com</email>
|
||||
<jid>dave.cridland@isode.com</jid>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Sam</firstname>
|
||||
<surname>Whited</surname>
|
||||
<email>sam@samwhited.com</email>
|
||||
<jid>sam@samwhited.com</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.4.0</version>
|
||||
<date>2017-01-17</date>
|
||||
<initials>ssw</initials>
|
||||
<remark>
|
||||
<ul>
|
||||
<li>Attempt to fix some confusing paragraphs.</li>
|
||||
<li>Add Client State Indication to Notable Extensions.</li>
|
||||
</ul>
|
||||
</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.3</version>
|
||||
<date>2015-07-24</date>
|
||||
<initials>ssw</initials>
|
||||
<remark><p>Include real world compression numbers and additional recommended reading.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.2</version>
|
||||
<date>2015-07-22</date>
|
||||
<initials>ssw</initials>
|
||||
<remark><p>Overhaul to include LTE.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2010-09-15</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Initial published version.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2010-07-13</date>
|
||||
<initials>dwd</initials>
|
||||
<remark><p>First draft. Also John's birthday.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>
|
||||
XMPP as a protocol was designed before the wide spread adoption of mobile
|
||||
devices, and is often cited as not being very mobile friendly as a result.
|
||||
However, this mostly stems from undocumented lore and outdated notions of
|
||||
how XMPP works. As the Internet and protocol design have changed to be more
|
||||
accommodating for mobile, so has XMPP.
|
||||
</p>
|
||||
<p>
|
||||
This XEP aims to provide useful background knowledge of mobile handset
|
||||
behavior, and those considerations that client and server designers can
|
||||
take to ensure that bandwidth and battery are used efficiently.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Overview' anchor='overview'>
|
||||
<p>
|
||||
The two major constraints on mobile devices are power and bandwidth.
|
||||
With the wide spread proliferation of 3G and LTE technologies, mobile
|
||||
bandwidth and speeds have become broadly comparable to broadband.
|
||||
However, they are still relatively expensive compared to traditional wired
|
||||
networks, and therefore conserving them is still desirable.
|
||||
This XEP mostly focuses on LTE as it already has a very wide deployment and
|
||||
will only continue to further replace 3G technologies.
|
||||
</p>
|
||||
</section1>
|
||||
<header>
|
||||
<title>Mobile Considerations</title>
|
||||
<abstract>
|
||||
This document provides background information for XMPP implementors
|
||||
concerned with mobile devices operating on an LTE cellular network.
|
||||
</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0286</number>
|
||||
<status>Experimental</status>
|
||||
<type>Informational</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>NOT_YET_ASSIGNED</shortname>
|
||||
<author>
|
||||
<firstname>Dave</firstname>
|
||||
<surname>Cridland</surname>
|
||||
<email>dave.cridland@isode.com</email>
|
||||
<jid>dave.cridland@isode.com</jid>
|
||||
</author>
|
||||
<author>
|
||||
<firstname>Sam</firstname>
|
||||
<surname>Whited</surname>
|
||||
<email>sam@samwhited.com</email>
|
||||
<jid>sam@samwhited.com</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.4.0</version>
|
||||
<date>2017-01-17</date>
|
||||
<initials>ssw</initials>
|
||||
<remark>
|
||||
<ul>
|
||||
<li>Attempt to fix some confusing paragraphs.</li>
|
||||
<li>Add Client State Indication to Notable Extensions.</li>
|
||||
</ul>
|
||||
</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.3</version>
|
||||
<date>2015-07-24</date>
|
||||
<initials>ssw</initials>
|
||||
<remark>
|
||||
<p>
|
||||
Include real world compression numbers and additional recommended
|
||||
reading.
|
||||
</p>
|
||||
</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.2</version>
|
||||
<date>2015-07-22</date>
|
||||
<initials>ssw</initials>
|
||||
<remark><p>Overhaul to include LTE.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2010-09-15</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Initial published version.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2010-07-13</date>
|
||||
<initials>dwd</initials>
|
||||
<remark><p>First draft. Also John's birthday.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>
|
||||
XMPP as a protocol was designed before the wide spread adoption of mobile
|
||||
devices, and is often cited as not being very mobile friendly as a result.
|
||||
However, this mostly stems from undocumented lore and outdated notions of
|
||||
how XMPP works. As the Internet and protocol design have changed to be
|
||||
more accommodating for mobile, so has XMPP.
|
||||
</p>
|
||||
<p>
|
||||
This XEP aims to provide useful background knowledge of mobile handset
|
||||
behavior, and those considerations that client and server designers can
|
||||
take to ensure that bandwidth and battery are used efficiently.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Overview' anchor='overview'>
|
||||
<p>
|
||||
The two major constraints on mobile devices are power and bandwidth.
|
||||
With the wide spread proliferation of 3G and LTE technologies, mobile
|
||||
bandwidth and speeds have become broadly comparable to broadband.
|
||||
However, they are still relatively expensive compared to traditional wired
|
||||
networks, and therefore conserving them is still desirable.
|
||||
This XEP mostly focuses on LTE as it already has a very wide deployment
|
||||
and will only continue to further replace 3G technologies.
|
||||
</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Compression' anchor='compression'>
|
||||
<p>
|
||||
XML, and by extension XMPP, is known to be highly compressible.
|
||||
Compression of XMPP data can be achieved with the DEFLATE algorithm
|
||||
(&rfc1951;) via TLS compression (&rfc3749;) or &xep0138; (which also
|
||||
supports other compression algorithms). While the security implications of
|
||||
stream compression are beyond the scope of this document (See the
|
||||
aforementioned RFC or XEP for more info), the author does not recommend
|
||||
using TLS compression with XMPP (or in general). If compression must be
|
||||
used, stream level compression should be implemented instead, and the
|
||||
compressed stream should have a full flush performed on stanza boundaries
|
||||
to help prevent a class of chosen plaintext attacks which can cause data
|
||||
leakage in compressed streams. While this may mitigate some of the benefits
|
||||
of compression by raising compression ratios, in a large, real world
|
||||
deployment at HipChat, network traffic was still observed to decrease by a
|
||||
factor of 0.58 when enabling &xep0138; with ZLIB compression!
|
||||
</p>
|
||||
<p>
|
||||
While the CPU cost of compression may directly translate to higher power
|
||||
usage, it is vastly outweighed by the benefits of reduced network
|
||||
utilization, especially on modern LTE networks which use a great deal more
|
||||
power per bit than 3G networks as will be seen later in this document.
|
||||
However, CPU usage is also not guaranteed to rise due to compression. In
|
||||
the aforementioned deployment of stream compression, a <em>decrease</em> in
|
||||
CPU utilization by a factor of 0.60 was observed due to the fact that there
|
||||
were fewer packets that needed to be handled by the OS (which also takes
|
||||
CPU time), and, potentially more importantly, less data that needed to be
|
||||
TLS-encrypted (which is a much more CPU-expensive operation than
|
||||
compression). Therefore CPU time spent on compression (for ZLIB, at least;
|
||||
other algorithms were not tested) should be considered negligable.
|
||||
</p>
|
||||
<p>
|
||||
Supporting compression and performming a full flush on stanza boundaries is
|
||||
recommended for mobile devices.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Power Consumption' anchor='power'>
|
||||
<p>
|
||||
While the wide spread adoption of LTE has dramatically increased available
|
||||
bandwidth on mobile devices, it has also increased power consumption.
|
||||
According to one study, early LTE devices consumed 5–20% more power
|
||||
than their 3G counterparts
|
||||
<note>LTE Smartphone measurements <<link url='http://networks.nokia.com/system/files/document/lte_measurements_final.pdf'>http://networks.nokia.com/system/files/document/lte_measurements_final.pdf</link>></note>.
|
||||
On some networks that support the legacy SVLTE (Simultaneous Voice and LTE)
|
||||
instead of the more modern VoLTE (Voice Over LTE) standard, or even CSFB
|
||||
(Circuit-switched fallback) this number would (presumably) be even higher.
|
||||
</p>
|
||||
<p>
|
||||
XMPP server and client implementers, bearing this increased power usage in
|
||||
mind, and knowing a bit about how LTE radios work, can optimize their
|
||||
traffic to minimize network usage. For the downlink, LTE user equipment
|
||||
(UE) utilizes Orthogonal Frequency Division Multiplexing (OFDM), which is
|
||||
somewhat inefficient
|
||||
<note>A Close Examination of Performance and Power Characteristics of 4G LTE Networks <<link url='http://www.cs.columbia.edu/~lierranli/coms6998-7Spring2014/papers/rrclte_mobisys2012.pdf'>http://www.cs.columbia.edu/~lierranli/coms6998-7Spring2014/papers/rrclte_mobisys2012.pdf</link>></note>.
|
||||
On the uplink side a different technology, Single-carrier frequency
|
||||
division multiple access (SC-FDMA) is used, which is slightly more
|
||||
efficient than traditional (non linearly-precoded) OFDM, slightly
|
||||
offsetting the fact that broadcasting requires more power than receiving.
|
||||
LTE UE also implements a Discontinuous reception (DRX) mode in which the
|
||||
hardware can sleep until it is woken by a paging message or is needed to
|
||||
perform some task. LTE radios have two power modes: RRC_CONNECTED and
|
||||
RRC_IDLE. DRX is supported in both of these power modes. By attempting to
|
||||
minimize the time which the LTE UE state machine spends in the
|
||||
RCC_CONNECTED state, and maximize the time it stays in the DRX state (for
|
||||
RCC_CONNECTED and RRC_IDLE), we can increase battery life without degrading
|
||||
the XMPP experience. To do so, the following rules should be observed:
|
||||
</p>
|
||||
<section2 topic='Transmit no data'>
|
||||
<p>
|
||||
Whenever possible, data that is not strictly needed should not be
|
||||
transmitted (by the server or client).
|
||||
Supporting &xep0352; is recommended.
|
||||
Most importantly, XMPP pings should be kept as far apart as possible and
|
||||
only used when necessary.
|
||||
Server operators are encouraged to set high ping timeouts, and client
|
||||
implementors are advised to only send pings when absolutely necessary to
|
||||
prevent the server from closing the socket.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Transmit as much data as you can at once'>
|
||||
<p>
|
||||
If one is on 3G, transmitting a small amount of data will cause the radio
|
||||
to enter FACH mode which is significantly cheaper than its high power
|
||||
mode.
|
||||
On LTE radios, however, transmitting small amounts of data is vastly more
|
||||
expensive per bit due to the higher tail-times (the time it takes for the
|
||||
radio to change state).
|
||||
On LTE radios, one should transmit as much data from the client as
|
||||
possible when the radio is already on (eg. by placing messages in a send
|
||||
queue and executing the queue as a batch when the radio is on).
|
||||
Similarly, when data is being received from the server, the mobile devices
|
||||
radio is already in a high power state and therefore any data that needs
|
||||
to be sent to the server should be transmitted.
|
||||
</p>
|
||||
<p>
|
||||
These rules also apply to server operators: If the server receives data,
|
||||
the phones radio is already on therefore you should send any pending data.
|
||||
Batching data to be sent and sending it all at once will help reduce power
|
||||
consumption.
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Notable Extensions' anchor='xeps'>
|
||||
<p>
|
||||
This section provides pointers to other documents which may be of interest
|
||||
to those developing mobile clients, or considering implementing
|
||||
optimizations for them in servers.
|
||||
</p>
|
||||
<p>&xep0138; provides stream level compression.</p>
|
||||
<p>&xep0322; allows XMPP streams to use the EXI XML format.</p>
|
||||
<p>
|
||||
&xep0115; provides a mechanism for caching, and hence eliding, the
|
||||
disco#info requests needed to negotiate optional features.
|
||||
</p>
|
||||
<p>
|
||||
&xep0237; provides a relatively widely deployed extension for reducing
|
||||
roster fetch sizes.
|
||||
</p>
|
||||
<p>
|
||||
&xep0198; allows the client to send and receive smaller keep-alive messages,
|
||||
and resume existing sessions without the full handshake.
|
||||
This is useful on unstable connections.
|
||||
</p>
|
||||
<p>
|
||||
&xep0352; allows clients to indicate to the server that they are inactive,
|
||||
allowing the server to optimize and reduce unnecessary traffic.
|
||||
</p>
|
||||
<p>
|
||||
&xep0357; implements push notifications (third party message delivery),
|
||||
which are often used on mobile devices and highly optimized to conserve
|
||||
battery.
|
||||
Push notifications also allow delivery of notifications to mobile clients
|
||||
that are currently offline (eg. in an XEP-0198 "zombie" state).
|
||||
</p>
|
||||
<p>
|
||||
&xep0313; lets clients fetch messages which they missed (eg. due to poor
|
||||
mobile coverage and a flaky network connection).
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='acks'>
|
||||
<p>
|
||||
This XEP was originally written by Dave Cridland, and parts of his original
|
||||
work were used in this rewrite.
|
||||
Thanks to Atlassian for allowing me to release hard numbers from their XMPP
|
||||
compression deployment.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>This document introduces no new security considerations.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>
|
||||
This document requires no interaction with the Internet Assigned Numbers
|
||||
Authority (IANA).
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>
|
||||
No namespaces or parameters need to be registered with the XMPP Registrar
|
||||
as a result of this document.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Compression' anchor='compression'>
|
||||
<p>
|
||||
XML, and by extension XMPP, is known to be highly compressible.
|
||||
Compression of XMPP data can be achieved with the DEFLATE algorithm
|
||||
(&rfc1951;) via TLS compression (&rfc3749;) or &xep0138; (which also
|
||||
supports other compression algorithms).
|
||||
While the security implications of stream compression are beyond the scope
|
||||
of this document (See the aforementioned RFC or XEP for more info), the
|
||||
author does not recommend using TLS compression with XMPP (or in general).
|
||||
If compression must be used, stream level compression should be
|
||||
implemented instead, and the compressed stream should have a full flush
|
||||
performed on stanza boundaries to help prevent a class of chosen plaintext
|
||||
attacks which can cause data leakage in compressed streams.
|
||||
While this may mitigate some of the benefits of compression by raising
|
||||
compression ratios, in a large, real world deployment at HipChat, network
|
||||
traffic was still observed to decrease by a factor of 0.58 when enabling
|
||||
&xep0138; with ZLIB compression!
|
||||
</p>
|
||||
<p>
|
||||
While the CPU cost of compression may directly translate to higher power
|
||||
usage, it is vastly outweighed by the benefits of reduced network
|
||||
utilization, especially on modern LTE networks which use a great deal more
|
||||
power per bit than 3G networks as will be seen later in this document.
|
||||
However, CPU usage is also not guaranteed to rise due to compression.
|
||||
In the aforementioned deployment of stream compression, a
|
||||
<em>decrease</em> in CPU utilization by a factor of 0.60 was observed due
|
||||
to the fact that there were fewer packets that needed to be handled by the
|
||||
OS (which also takes CPU time), and, potentially more importantly, less
|
||||
data that needed to be TLS-encrypted (which is a much more CPU-expensive
|
||||
operation than compression).
|
||||
Therefore CPU time spent on compression (for ZLIB, at least; other
|
||||
algorithms were not tested) should be considered negligable.
|
||||
</p>
|
||||
<p>
|
||||
Supporting compression and performming a full flush on stanza boundaries
|
||||
is recommended for mobile devices.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Power Consumption' anchor='power'>
|
||||
<p>
|
||||
While the wide spread adoption of LTE has dramatically increased available
|
||||
bandwidth on mobile devices, it has also increased power consumption.
|
||||
According to one study, early LTE devices consumed 5–20% more power
|
||||
than their 3G counterparts
|
||||
<note>LTE Smartphone measurements <<link url='http://networks.nokia.com/system/files/document/lte_measurements_final.pdf'>http://networks.nokia.com/system/files/document/lte_measurements_final.pdf</link>></note>.
|
||||
On some networks that support the legacy SVLTE (Simultaneous Voice and
|
||||
LTE) instead of the more modern VoLTE (Voice Over LTE) standard, or even
|
||||
CSFB (Circuit-switched fallback) this number would (presumably) be even
|
||||
higher.
|
||||
</p>
|
||||
<p>
|
||||
XMPP server and client implementers, bearing this increased power usage in
|
||||
mind, and knowing a bit about how LTE radios work, can optimize their
|
||||
traffic to minimize network usage.
|
||||
For the downlink, LTE user equipment
|
||||
(UE) utilizes Orthogonal Frequency Division Multiplexing (OFDM), which is
|
||||
somewhat inefficient
|
||||
<note>A Close Examination of Performance and Power Characteristics of 4G LTE Networks <<link url='http://www.cs.columbia.edu/~lierranli/coms6998-7Spring2014/papers/rrclte_mobisys2012.pdf'>http://www.cs.columbia.edu/~lierranli/coms6998-7Spring2014/papers/rrclte_mobisys2012.pdf</link>></note>.
|
||||
On the uplink side a different technology, Single-carrier frequency
|
||||
division multiple access (SC-FDMA) is used, which is slightly more
|
||||
efficient than traditional (non linearly-precoded) OFDM, slightly
|
||||
offsetting the fact that broadcasting requires more power than receiving.
|
||||
LTE UE also implements a Discontinuous reception (DRX) mode in which the
|
||||
hardware can sleep until it is woken by a paging message or is needed to
|
||||
perform some task.
|
||||
LTE radios have two power modes: RRC_CONNECTED and RRC_IDLE.
|
||||
DRX is supported in both of these power modes.
|
||||
By attempting to minimize the time which the LTE UE state machine spends
|
||||
in the RCC_CONNECTED state, and maximize the time it stays in the DRX
|
||||
state (for RCC_CONNECTED and RRC_IDLE), we can increase battery life
|
||||
without degrading the XMPP experience.
|
||||
To do so, the following rules should be observed:
|
||||
</p>
|
||||
<section2 topic='Transmit no data'>
|
||||
<p>
|
||||
Whenever possible, data that is not strictly needed should not be
|
||||
transmitted (by the server or client).
|
||||
Supporting &xep0352; is recommended.
|
||||
Most importantly, XMPP pings should be kept as far apart as possible and
|
||||
only used when necessary.
|
||||
Server operators are encouraged to set high ping timeouts, and client
|
||||
implementors are advised to only send pings when absolutely necessary to
|
||||
prevent the server from closing the socket.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Transmit as much data as you can at once'>
|
||||
<p>
|
||||
If one is on 3G, transmitting a small amount of data will cause the
|
||||
radio to enter FACH mode which is significantly cheaper than its high
|
||||
power mode.
|
||||
On LTE radios, however, transmitting small amounts of data is vastly
|
||||
more expensive per bit due to the higher tail-times (the time it takes
|
||||
for the radio to change state).
|
||||
On LTE radios, one should transmit as much data from the client as
|
||||
possible when the radio is already on (eg. by placing messages in a send
|
||||
queue and executing the queue as a batch when the radio is on).
|
||||
Similarly, when data is being received from the server, the mobile
|
||||
devices radio is already in a high power state and therefore any data
|
||||
that needs to be sent to the server should be transmitted.
|
||||
</p>
|
||||
<p>
|
||||
These rules also apply to server operators: If the server receives data,
|
||||
the phones radio is already on therefore you should send any pending
|
||||
data.
|
||||
Batching data to be sent and sending it all at once will help reduce
|
||||
power consumption.
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Notable Extensions' anchor='xeps'>
|
||||
<p>
|
||||
This section provides pointers to other documents which may be of interest
|
||||
to those developing mobile clients, or considering implementing
|
||||
optimizations for them in servers.
|
||||
</p>
|
||||
<p>&xep0138; provides stream level compression.</p>
|
||||
<p>&xep0322; allows XMPP streams to use the EXI XML format.</p>
|
||||
<p>
|
||||
&xep0115; provides a mechanism for caching, and hence eliding, the
|
||||
disco#info requests needed to negotiate optional features.
|
||||
</p>
|
||||
<p>
|
||||
&xep0237; provides a relatively widely deployed extension for reducing
|
||||
roster fetch sizes.
|
||||
</p>
|
||||
<p>
|
||||
&xep0198; allows the client to send and receive smaller keep-alive
|
||||
messages, and resume existing sessions without the full handshake.
|
||||
This is useful on unstable connections.
|
||||
</p>
|
||||
<p>
|
||||
&xep0352; allows clients to indicate to the server that they are inactive,
|
||||
allowing the server to optimize and reduce unnecessary traffic.
|
||||
</p>
|
||||
<p>
|
||||
&xep0357; implements push notifications (third party message delivery),
|
||||
which are often used on mobile devices and highly optimized to conserve
|
||||
battery.
|
||||
Push notifications also allow delivery of notifications to mobile clients
|
||||
that are currently offline (eg. in an XEP-0198 "zombie" state).
|
||||
</p>
|
||||
<p>
|
||||
&xep0313; lets clients fetch messages which they missed (eg. due to poor
|
||||
mobile coverage and a flaky network connection).
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='acks'>
|
||||
<p>
|
||||
This XEP was originally written by Dave Cridland, and parts of his
|
||||
original work were used in this rewrite.
|
||||
Thanks to Atlassian for allowing me to release hard numbers from their
|
||||
XMPP compression deployment.
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>This document introduces no new security considerations.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>
|
||||
This document requires no interaction with the Internet Assigned Numbers
|
||||
Authority (IANA).
|
||||
</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>
|
||||
No namespaces or parameters need to be registered with the XMPP Registrar
|
||||
as a result of this document.
|
||||
</p>
|
||||
</section1>
|
||||
</xep>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user