XEP-0286: Fix some confusing paragraphs.

Add reference to CSI in Notable Extensions
Undefer

xep-0286.xml

@@ -13,7 +13,7 @@
 	</abstract>
   &LEGALNOTICE;
   <number>0286</number>
-  <status>Deferred</status>
+  <status>Experimental</status>
   <type>Informational</type>
   <sig>Standards</sig>
   <approver>Council</approver>
@@ -35,6 +35,17 @@
     <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>
@@ -76,13 +87,13 @@
 </section1>
 <section1 topic='Overview' anchor='overview'>
 	<p>
-		The two major constraints on mobile devices are power and bandwidth. With
+    The two major constraints on mobile devices are power and bandwidth.
-		the wide spread proliferation of 3G and LTE technologies, mobile bandwidth
+    With the wide spread proliferation of 3G and LTE technologies, mobile
-		and speeds have become broadly comparable to broadband. However, they are
+    bandwidth and speeds have become broadly comparable to broadband.
-		still relatively expensive compared to traditional wired networks, and
+    However, they are still relatively expensive compared to traditional wired
-		should therefore still be considered. This XEP mostly focuses on LTE as it
+    networks, and therefore conserving them is still desirable.
-		already has a very wide deployment and will only continue to further
+    This XEP mostly focuses on LTE as it already has a very wide deployment and
-		replace 3G technologies.
+    will only continue to further replace 3G technologies.
 	</p>
 </section1>
 
@@ -118,8 +129,8 @@
 		other algorithms were not tested) should be considered negligable.
 	</p>
 	<p>
-		Supporting compression and flushing on stanza boundaries is highly
+    Supporting compression and performming a full flush on stanza boundaries is
-		recommended.
+    recommended for mobile devices.
 	</p>
 </section1>
 <section1 topic='Power Consumption' anchor='power'>
@@ -156,39 +167,43 @@
 	<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 highly
+      transmitted (by the server or client).
-			recommended.  Most importantly, XMPP pings should be kept as far apart as
+      Supporting &xep0352; is recommended.
-			possible and only used when necessary. Server operators are encouraged to
+      Most importantly, XMPP pings should be kept as far apart as possible and
-			set high ping timeouts, and client implementors are advised to only send
+      only used when necessary.
-			pings when absolutely necessary to prevent the server from closing the
+      Server operators are encouraged to set high ping timeouts, and client
-			socket.
+      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
+      mode.
-			vastly more expensive per bit due to the significantly higher tail-times
+      On LTE radios, however, transmitting small amounts of data is vastly more
-			(the time it takes for the radio to change state). On LTE radios, one
+      expensive per bit due to the higher tail-times (the time it takes for the
-			should transmit as much data as possible when the radio is already on
+      radio to change state).
-			(eg. by placing messages in a send queue and executing the queue as a
+      On LTE radios, one should transmit as much data from the client as
-			batch). Similarly, when data is being received the radio is already in a
+      possible when the radio is already on (eg. by placing messages in a send
-			high power state and therefore any data that needs to be sent should be.
+      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 you receive data, the
+      These rules also apply to server operators: If the server receives data,
-			phones radio is already on therefore you should send anything you have.
+      the phones radio is already on therefore you should send any pending data.
-			Otherwise, batching data to be sent and sending it all at once (and as
+      Batching data to be sent and sending it all at once will help reduce power
-			much as possible) will help reduce power consumption.
+      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 support for them in
+    to those developing mobile clients, or considering implementing
-		servers.
+    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>
@@ -201,15 +216,20 @@
 		roster fetch sizes.
 	</p>
 	<p>
-		&xep0198; allows the client to send and receive smaller keep-alive
+    &xep0198; allows the client to send and receive smaller keep-alive messages,
-		messages, and resume existing sessions without the full handshake. Useful
+    and resume existing sessions without the full handshake.
-		on unstable connections.
+    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
+    battery.
-		clients that are currently offline (eg. in an XEP-0198 "zombie" state).
+    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
@@ -219,8 +239,9 @@
 <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
+    work were used in this rewrite.
-		release hard numbers from their XMPP compression deployment.
+    Thanks to Atlassian for allowing me to release hard numbers from their XMPP
+    compression deployment.
 	</p>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>