Fix use of definition lists.

xep-0286.xml

@@ -113,27 +113,45 @@
 <section1 topic='Conclusions'>
   <p>As with anything, there are no hard and fast rules. If there were, they might look like these. First, for devices:</p>
   <dl>
+    <di>
     <dt>Transmit no data.</dt>
       <dd>Transmitting costs significant power, and moreover raises the radio state. Not transmitting will allow it to maximize the time spent in the low-cost Idle state.</dd>
+    </di>
+    <di>
     <dt>If you must transmit, then transmit only a small volume.</dt>
       <dd>If there is only a small amount of data transmitted - less than 128 octets typically - the radio will only raise to FACH, which is significantly cheaper than DCH.</dd>
+    </di>
+    <di>
     <dt>If you must transmit, then compress as hard as possible.</dt>
       <dd>Since individual octets have an associate power - and often financial - cost, it's worth maximizing the compression algorithm, even if the volume of traffic will raise to DCH.</dd>
+    </di>
+    <di>
     <dt>If you have transmit a lot, then do a lot</dt>
       <dd>If the radio is raised to DCH anyway, then you may as well go fetch that avatar you were missing, since you're chewing through power anyway.</dd>
+    </di>
+    <di>
     <dt>If you receive, then transmit</dt>
       <dd>If your peer raises the radio state, you may as well use it.</dd>
+    </di>
   </dl>
   <p>And for servers, similar rules apply:</p>
   <dl>
+    <di>
     <dt>Send no data.</dt>
       <dd>Sending data will cause the handset to be raised out of Idle. This immediately costs massively higher power.</dd>
+    </di>
+    <di>
     <dt>If you must send, send tiny bits.</dt>
       <dd>Sending small enough data maximizes the likelyhood that the devices radio will only be raised to FACH levels.</dd>
+    </di>
+    <di>
     <dt>If you receive, then send anything you have.</dt>
       <dd>Receiving data indicates that the radio is active - it'll stay active for some time, so sending data doesn't incur the overhead of raising the radio state, and won't increase power drain on the handset.</dd>
+    </di>
+    <di>
     <dt>If you must send when not receiving, send plenty.</dt>
       <dd>Sending data will raise the radio's state - unless you can tell this will only raise it to FACH, it's worth sending as much as possible.</dd>
+    </di>
   </dl>
   <p>Finally, protocol designers should aim to minimize any responses required from the handset, and ensure keepalive traffic, if any, fits inside FACH wherever possible.</p>
 </section1>