diff --git a/xep-0286.xml b/xep-0286.xml index 719a7ff4..b04aa74a 100644 --- a/xep-0286.xml +++ b/xep-0286.xml @@ -8,12 +8,12 @@
Mobile Considerations - This document provides background information for XMPP implementors - concerned with mobile devices operating on an LTE cellular network. + This document provides background information for XMPP implementors + concerned with mobile devices operating on an LTE cellular network. &LEGALNOTICE; 0286 - Deferred + Experimental Informational Standards Council @@ -35,6 +35,17 @@ sam@samwhited.com sam@samwhited.com + + 0.4.0 + 2017-01-17 + ssw + +
    +
  • Attempt to fix some confusing paragraphs.
    • +
  • Add Client State Indication to Notable Extensions.
    • +
+ + 0.3 2015-07-24 @@ -76,13 +87,13 @@

- 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 - should therefore still be considered. This XEP mostly focuses on LTE as it - already has a very wide deployment and will only continue to further - replace 3G technologies. + 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.

@@ -118,8 +129,8 @@ other algorithms were not tested) should be considered negligable.

- Supporting compression and flushing on stanza boundaries is highly - recommended. + Supporting compression and performming a full flush on stanza boundaries is + recommended for mobile devices.

@@ -156,39 +167,43 @@

Whenever possible, data that is not strictly needed should not be - transmitted (by the server or client). Supporting &xep0352; is highly - 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. + 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.

- 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 significantly higher tail-times - (the time it takes for the radio to change state). On LTE radios, one - should transmit as much data as possible when the radio is already on - (eg. by placing messages in a send queue and executing the queue as a - batch). Similarly, when data is being received the radio is already in a - high power state and therefore any data that needs to be sent should be. + 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.

- These rules also apply to server operators: If you receive data, the - phones radio is already on therefore you should send anything you have. - Otherwise, batching data to be sent and sending it all at once (and as - much as possible) will help reduce power consumption. + 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.

- This section provides pointers to other documents which may be of interest - to those developing mobile clients, or considering support for them in - servers. + 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.

&xep0138; provides stream level compression.

&xep0322; allows XMPP streams to use the EXI XML format.

@@ -201,15 +216,20 @@ roster fetch sizes.

- &xep0198; allows the client to send and receive smaller keep-alive - messages, and resume existing sessions without the full handshake. Useful - on unstable connections. + &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.

+

+ &xep0352; allows clients to indicate to the server that they are inactive, + allowing the server to optimize and reduce unnecessary traffic. +

&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). + battery. + Push notifications also allow delivery of notifications to mobile clients + that are currently offline (eg. in an XEP-0198 "zombie" state).

&xep0313; lets clients fetch messages which they missed (eg. due to poor @@ -219,8 +239,9 @@

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. + work were used in this rewrite. + Thanks to Atlassian for allowing me to release hard numbers from their XMPP + compression deployment.