XEP-0286: Retab and rewrap

xep-0286.xml

@@ -1,11 +1,11 @@
 <?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>
+  <header>
     <title>Mobile Considerations</title>
     <abstract>
       This document provides background information for XMPP implementors
@@ -50,7 +50,12 @@
       <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>
+      <remark>
+        <p>
+          Include real world compression numbers and additional recommended
+          reading.
+        </p>
+      </remark>
     </revision>
     <revision>
       <version>0.2</version>
@@ -70,84 +75,88 @@
       <initials>dwd</initials>
       <remark><p>First draft. Also John's birthday.</p></remark>
     </revision>
-</header>
+  </header>
-<section1 topic='Introduction' anchor='intro'>
+  <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
+      how XMPP works. As the Internet and protocol design have changed to be
-		accommodating for mobile, so has XMPP.
+      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>
-<section1 topic='Overview' anchor='overview'>
+  <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
+      This XEP mostly focuses on LTE as it already has a very wide deployment
-    will only continue to further replace 3G technologies.
+      and will only continue to further replace 3G technologies.
     </p>
-</section1>
+  </section1>
 
-<section1 topic='Compression' anchor='compression'>
+  <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
+      supports other compression algorithms).
-		stream compression are beyond the scope of this document (See the
+      While the security implications of stream compression are beyond the scope
-		aforementioned RFC or XEP for more info), the author does not recommend
+      of this document (See the aforementioned RFC or XEP for more info), the
-		using TLS compression with XMPP (or in general). If compression must be
+      author does not recommend using TLS compression with XMPP (or in general).
-		used, stream level compression should be implemented instead, and the
+      If compression must be used, stream level compression should be
-		compressed stream should have a full flush performed on stanza boundaries
+      implemented instead, and the compressed stream should have a full flush
-		to help prevent a class of chosen plaintext attacks which can cause data
+      performed on stanza boundaries to help prevent a class of chosen plaintext
-		leakage in compressed streams. While this may mitigate some of the benefits
+      attacks which can cause data leakage in compressed streams.
-		of compression by raising compression ratios, in a large, real world
+      While this may mitigate some of the benefits of compression by raising
-		deployment at HipChat, network traffic was still observed to decrease by a
+      compression ratios, in a large, real world deployment at HipChat, network
-		factor of 0.58 when enabling &xep0138; with ZLIB compression!
+      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
+      However, CPU usage is also not guaranteed to rise due to compression.
-		the aforementioned deployment of stream compression, a <em>decrease</em> in
+      In the aforementioned deployment of stream compression, a
-		CPU utilization by a factor of 0.60 was observed due to the fact that there
+      <em>decrease</em> in CPU utilization by a factor of 0.60 was observed due
-		were fewer packets that needed to be handled by the OS (which also takes
+      to the fact that there were fewer packets that needed to be handled by the
-		CPU time), and, potentially more importantly, less data that needed to be
+      OS (which also takes CPU time), and, potentially more importantly, less
-		TLS-encrypted (which is a much more CPU-expensive operation than
+      data that needed to be TLS-encrypted (which is a much more CPU-expensive
-		compression). Therefore CPU time spent on compression (for ZLIB, at least;
+      operation than compression).
-		other algorithms were not tested) should be considered negligable.
+      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
+      Supporting compression and performming a full flush on stanza boundaries
-    recommended for mobile devices.
+      is recommended for mobile devices.
     </p>
-</section1>
+  </section1>
-<section1 topic='Power Consumption' anchor='power'>
+  <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&#x2013;20% more power
       than their 3G counterparts
       <note>LTE Smartphone measurements &lt;<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>&gt;</note>.
-		On some networks that support the legacy SVLTE (Simultaneous Voice and LTE)
+      On some networks that support the legacy SVLTE (Simultaneous Voice and
-		instead of the more modern VoLTE (Voice Over LTE) standard, or even CSFB
+      LTE) instead of the more modern VoLTE (Voice Over LTE) standard, or even
-		(Circuit-switched fallback) this number would (presumably) be even higher.
+      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
+      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 &lt;<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>&gt;</note>.
@@ -157,12 +166,14 @@
       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
+      perform some task.
-		RRC_IDLE. DRX is supported in both of these power modes. By attempting to
+      LTE radios have two power modes: RRC_CONNECTED and RRC_IDLE.
-		minimize the time which the LTE UE state machine spends in the
+      DRX is supported in both of these power modes.
-		RCC_CONNECTED state, and maximize the time it stays in the DRX state (for
+      By attempting to minimize the time which the LTE UE state machine spends
-		RCC_CONNECTED and RRC_IDLE), we can increase battery life without degrading
+      in the RCC_CONNECTED state, and maximize the time it stays in the DRX
-		the XMPP experience. To do so, the following rules should be observed:
+      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>
@@ -178,28 +189,29 @@
     </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
+        If one is on 3G, transmitting a small amount of data will cause the
-      to enter FACH mode which is significantly cheaper than its high power
+        radio to enter FACH mode which is significantly cheaper than its high
-      mode.
+        power mode.
-      On LTE radios, however, transmitting small amounts of data is vastly more
+        On LTE radios, however, transmitting small amounts of data is vastly
-      expensive per bit due to the higher tail-times (the time it takes for the
+        more expensive per bit due to the higher tail-times (the time it takes
-      radio to change state).
+        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
+        Similarly, when data is being received from the server, the mobile
-      radio is already in a high power state and therefore any data that needs
+        devices radio is already in a high power state and therefore any data
-      to be sent to the server should be transmitted.
+        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.
+        the phones radio is already on therefore you should send any pending
-      Batching data to be sent and sending it all at once will help reduce power
+        data.
-      consumption.
+        Batching data to be sent and sending it all at once will help reduce
+        power consumption.
       </p>
     </section2>
-</section1>
+  </section1>
-<section1 topic='Notable Extensions' anchor='xeps'>
+  <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
@@ -216,8 +228,8 @@
       roster fetch sizes.
     </p>
     <p>
-    &xep0198; allows the client to send and receive smaller keep-alive messages,
+      &xep0198; allows the client to send and receive smaller keep-alive
-    and resume existing sessions without the full handshake.
+      messages, and resume existing sessions without the full handshake.
       This is useful on unstable connections.
     </p>
     <p>
@@ -235,28 +247,28 @@
       &xep0313; lets clients fetch messages which they missed (eg. due to poor
       mobile coverage and a flaky network connection).
     </p>
-</section1>
+  </section1>
-<section1 topic='Acknowledgements' anchor='acks'>
+  <section1 topic='Acknowledgements' anchor='acks'>
     <p>
-		This XEP was originally written by Dave Cridland, and parts of his original
+      This XEP was originally written by Dave Cridland, and parts of his
-    work were used in this rewrite.
+      original work were used in this rewrite.
-    Thanks to Atlassian for allowing me to release hard numbers from their XMPP
+      Thanks to Atlassian for allowing me to release hard numbers from their
-    compression deployment.
+      XMPP compression deployment.
     </p>
-</section1>
+  </section1>
-<section1 topic='Security Considerations' anchor='security'>
+  <section1 topic='Security Considerations' anchor='security'>
     <p>This document introduces no new security considerations.</p>
-</section1>
+  </section1>
-<section1 topic='IANA Considerations' anchor='iana'>
+  <section1 topic='IANA Considerations' anchor='iana'>
     <p>
       This document requires no interaction with the Internet Assigned Numbers
       Authority (IANA).
     </p>
-</section1>
+  </section1>
-<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
+  <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>
 </xep>