Merge branch 'master' of athena.jabber.org:xmpp

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>

xep2texml.xsl

@@ -99,6 +99,8 @@
 \newcommand{\XEPNumber}[0]{<xsl:value-of select="/xep/header/number"/>}
 \newcommand{\XEPVersion}[0]{<xsl:value-of select="$maxXEPVersion"/>}
 
+\newcolumntype{L}{>{\raggedright\arraybackslash}X}
+
 \fancyhead[L,L]{\includegraphics[totalheight=10pt]{xmpp.pdf} \slshape \leftmark}
 \fancyfoot[C,C]{\thepage}
 
@@ -225,7 +227,7 @@
 <xsl:template match='table'>
   <TeXML escape="0">
     <env name="center">
-    <env name='tabularx'><parm><cmd name="linewidth" /></parm>
+    <env name='tabularx'><parm><TeXML escape="0">\linewidth</TeXML></parm>
       <parm><xsl:for-each select='tr[1]/th | tr[1]/td'><xsl:if test="position() = 1">l</xsl:if><xsl:if test='position() != last() and position() > 1'>X</xsl:if><xsl:if test='position() = last()'>X</xsl:if></xsl:for-each></parm>
       <xsl:for-each select='tr'>
         <xsl:for-each select='td | th'><xsl:if test='position() > 1'> &amp; </xsl:if><TeXML escape="1"><xsl:value-of select='.'/></TeXML><xsl:if test='position() = last()'> \\</xsl:if></xsl:for-each>