XEP-0204–XEP-0298: DTD fixes

xep-0204.xml

@@ -571,10 +571,10 @@ A CDO client can query the server to determine the specific state of a particula
      </query>
 </iq>
 ]]></example>
-Note an event type of info. This requires all attributes for the data-sync element and items be present
+<p>Note an event type of info. This requires all attributes for the data-sync element and items be present</p>
 </section2>
     <section2 topic="Query an endpoint for a list of CDOs" anchor="cdolist">
-In some cases a client may be interested in the state of all CDOs belonging to a specific endpoint - for example a chat room.
+      <p>In some cases a client may be interested in the state of all CDOs belonging to a specific endpoint - for example a chat room.</p>
 <example caption="Client A constructs an IQ get and sends it to Server X wishing to obtain the current state of all CDOs belonging to the CDO users chatroom"><![CDATA[
 <iq type='get' from='joe@mitre.org/Desktop' to='cdo_users@mitre.org' id='cdo_state_2>
     <query xmlns='http://www.xmpp.org/extensions/xep-0204.html#ns-state'>
@@ -595,18 +595,17 @@ In some cases a client may be interested in the state of all CDOs belonging to a
           type="cdo:Location" 
           event="info" 
           xmlns="http://www.xmpp.org/extensions/xep-0204.html#ns"/>
-        ... 
-          
+        ...
      </query>
 </iq>
 ]]></example>
-Note the value of the uuid for the cdo tag above uses an asterisk (*) to indicate all CDOs
+<p>Note the value of the uuid for the cdo tag above uses an asterisk (*) to indicate all CDOs</p>
 <p>
 If desired, Client A can then query the Server for the details on the state of a specific CDO using the protocol described earlier.
 </p>
     </section2>
     <section2 topic="Create a new CDO" anchor="cdocreate">
-When two endpoints (client A and client B) wish to create a new CDO. Each client and server MUST follow this algorithm:
+      <p>When two endpoints (client A and client B) wish to create a new CDO. Each client and server MUST follow this algorithm:</p>
 <example caption="Client A creates a new CDO and sends it to client B"><![CDATA[
 <message
     to='joe@mitre.org/Desktop'
@@ -625,7 +624,7 @@ When two endpoints (client A and client B) wish to create a new CDO. Each client
    </data-sync>
 </message>
 ]]></example>
-Here client A, has created a packetID and set event=create in both &lt;data-sync&gt; and &lt;item&gt;. The version MUST be set to zero
+<p>Here client A, has created a packetID and set event=create in both &lt;data-sync&gt; and &lt;item&gt;. The version MUST be set to zero</p>
 <p>
 Next, the message is intercepted by Server X. Server X is the IM server that both clients are connected to. When the server receives 
 the message, it MUST increment the version number and assign a uuid for both the &lt;data-sync&gt; and &lt;item&gt;. Once processed
@@ -675,10 +674,10 @@ Server X MUST send a copy of the message back to client A as a receipt that the
    </data-sync>
 </message>
 ]]></example>
-Once this is completed, both clients have a synchronized CDO message with a uuid and a version number assigned by the server.
+<p>Once this is completed, both clients have a synchronized CDO message with a uuid and a version number assigned by the server.</p>
 </section2>
     <section2 topic="Create a new Item on an existing CDO" anchor="cdoitemcreate">
-When client A wishes to create a new Item on an existing CDO, he sends the following information to client B
+      <p>When client A wishes to create a new Item on an existing CDO, he sends the following information to client B</p>
 <example caption="Client A creates a new item on an existing CDO and sends it to client B"><![CDATA[
 <message
     to='joe@mitre.org/Desktop'
@@ -741,10 +740,10 @@ Next, Server X MUST send a copy of the message back to client A as a receipt tha
    </data-sync>
 </message>
 ]]></example>
-Once this is completed, both clients have a synchronized CDO message with a new item. The new item has been assigned a uuid and a version number by the server.
+<p>Once this is completed, both clients have a synchronized CDO message with a new item. The new item has been assigned a uuid and a version number by the server.</p>
 </section2>
     <section2 topic="Update an Item on an existing CDO" anchor="cdoitemupdate">
-When client A wishes to update an item on an existing CDO, he sends the following information to client B
+      <p>When client A wishes to update an item on an existing CDO, he sends the following information to client B</p>
 <example caption="Client A updates an item on an existing CDO and sends it to client B"><![CDATA[
 <message
     to='joe@mitre.org/Desktop'
@@ -819,7 +818,7 @@ Next, Server X MUST send a copy of the message back to client A as a receipt tha
    </data-sync>
 </message>
 ]]></example>
-Once this is completed, both clients have a synchronized CDO message with an updated item. The updated item has the version number incremented.
+<p>Once this is completed, both clients have a synchronized CDO message with an updated item. The updated item has the version number incremented.</p>
   <section3 topic="Update Styles">
         <p>
        There are two types of behaviors associated with an item update: inclusive and exclusive. For an inclusive update, the content of the item element 
@@ -832,35 +831,35 @@ Once this is completed, both clients have a synchronized CDO message with an upd
      Assume that client A has created a CDO cdo_1. This CDO has an item item_1 with the attribute named attr_1 set. If A wants to update item_1 with a value 
      for the attribute named attr_2 without destroying the previously set value for attr_1, the following data synchronization packets are equivalent:
      </p>
-        <pre><![CDATA[
-<data-sync protocol="1.0" uuid="cdo_1"  packetID="0003" 
+        <code><![CDATA[
+<data-sync protocol="1.0" uuid="cdo_1"  packetID="0003"
            event="update" xmlns="http://www.xmpp.org/extensions/xep-0204.html#ns">
-  <item type="field" 
-           uuid="item_1" 
-           event="update" 
-           version="1" 
+  <item type="field"
+           uuid="item_1"
+           event="update"
+           version="1"
            updateStyle="inclusive">
     <attribute name="attr_1">old value</attribute>
     <attribute name="attr_2">new value</attribute>
   </item>
 </data-sync>
-     ]]></pre>
-        <pre><![CDATA[
-<data-sync protocol="1.0" uuid="cdo_1"  packetID="0003" 
+]]></code>
+        <code><![CDATA[
+<data-sync protocol="1.0" uuid="cdo_1"  packetID="0003"
            event="update" xmlns="http://www.xmpp.org/extensions/xep-0204.html#ns">
-  <item type="field" 
-           uuid="item_1" 
-           event="update" 
-           version="1" 
+  <item type="field"
+           uuid="item_1"
+           event="update"
+           version="1"
            updateStyle="exclusive">
        <attribute name="attr_2">new value</attribute>
-  </item> 
+  </item>
 </data-sync>
-     ]]></pre>
+]]></code>
       </section3>
     </section2>
     <section2 topic="Delete an Item on an existing CDO" anchor="cdoitemdelete">
-When client A wishes to delete an item on an existing CDO, he sends the following information to client B
+      <p>When client A wishes to delete an item on an existing CDO, he sends the following information to client B</p>
 <example caption="Client A deletes an item on an existing CDO and sends it to client B"><![CDATA[
 <message
     to='joe@mitre.org/Desktop'
@@ -929,7 +928,7 @@ back to client A as a receipt that the message has been processed by Server X an
    </data-sync>
 </message>
 ]]></example>
-Once this is completed, both clients have a synchronized CDO message with a deleted item.
+<p>Once this is completed, both clients have a synchronized CDO message with a deleted item.</p>
 </section2>
     <section2 topic="Retire an existing CDO" anchor="cdoretire">
       <p>
@@ -990,7 +989,7 @@ message back to client A as a receipt that the message has been processed by Ser
    </data-sync>
 </message>
 ]]></example>
-Once this is completed, both clients have retired (deleted) the CDO.
+<p>Once this is completed, both clients have retired (deleted) the CDO.</p>
 </section2>
   </section1>
   <section1 topic="Errors" anchor="errors">
@@ -1590,12 +1589,12 @@ containing at least one overlapping item. When this occurs, the first packet to
 reported back to the client of the second packet MAY be extended to describe the notional conflict. This additional error information is meant to facilitate 
 collaboration between the clients.
 </p>
-The additional error information provide includes:
+<p>The additional error information provide includes:</p>
 <ul>
-        <li>The resource identifier of the client originating the data sync packet with which this error conflicts.</li>
-        <li>The timestamp of when the originating data sync packet was executed.</li>
-        <li>The item element of the originating data sync packet with which this error conflicts.</li>
-      </ul>
+  <li>The resource identifier of the client originating the data sync packet with which this error conflicts.</li>
+  <li>The timestamp of when the originating data sync packet was executed.</li>
+  <li>The item element of the originating data sync packet with which this error conflicts.</li>
+</ul>
       <example caption=""><![CDATA[
 <cdo:item-version-outdated identifier='I' version='V'>
    <cdo:conflict resource-identifier='R' execution-timestamp='T'>

xep-0209.xml

@@ -54,11 +54,11 @@
   </ul>
 </section1>
 <section1 topic='Overview' anchor='overview'>
-  The metacontact storage is achieved through the use of private data storage. In order to achieve the resilience described above, the private storage of each account is used to store the metacontact membership of Jids in the roster of that account. The metacontacts are stored within private data storage of each account simply as an unordered collection of meta tags.
+  <p>The metacontact storage is achieved through the use of private data storage. In order to achieve the resilience described above, the private storage of each account is used to store the metacontact membership of Jids in the roster of that account. The metacontacts are stored within private data storage of each account simply as an unordered collection of meta tags.</p>
   <example caption='A metacontact tag'><![CDATA[
 <meta jid='romeo@montague.net' tag='d93nov' order='0'>
 ]]></example>
-    In this example, the 'jid' specifies that the roster entry 'romeo@montague.net' is a member of a metacontact. The 'tag' provides a key for a metacontact; in this example all metacontacts with a tag of 'd93nov' (across all accounts) refer to the same entity. The 'order' denotes the priority of this Jid over other Jids within the metacontact, with it being preferable to use Jids with higher priority (this is roughly analogous to the 'priority' on presence stanzas when a Jid has multiple online resources in XMPP). 
+    <p>In this example, the 'jid' specifies that the roster entry 'romeo@montague.net' is a member of a metacontact. The 'tag' provides a key for a metacontact; in this example all metacontacts with a tag of 'd93nov' (across all accounts) refer to the same entity. The 'order' denotes the priority of this Jid over other Jids within the metacontact, with it being preferable to use Jids with higher priority (this is roughly analogous to the 'priority' on presence stanzas when a Jid has multiple online resources in XMPP).</p>
 </section1>
 <section1 topic='Use Cases' anchor='usecases'>
   <p>Below are example of setting and retrieving metacontacts for an account. When using metacontacts across multiple accounts, the steps are identical and the 'tag' attributes and used across accounts (that is: when the same tag is used for multiple contacts, all entries with the tag are merged into a single metacontact whether they reside on the same of different accounts).</p>
@@ -114,7 +114,6 @@
 <!--As metacontacts are especially useful when used across multiple accounts, examples are also provided for actions across two accounts.
   <section2 topic='Retrieving metacontact data (account 1)' anchor='dualaccount-get1'>
      <example caption=''><![CDATA[
-      
       ]]></example>
   </section2>-->
 </section1>
@@ -122,10 +121,10 @@
 <section1 topic='Implementation Notes' anchor='impl'>
   <!--<p>Optional.</p>-->
   <section2 topic='Creating a metacontact' anchor='creating'>
-    Creation of a metacontact is uncomplicated; the simple addition of meta tag with a common tag results in a new metacontact.
+    <p>Creation of a metacontact is uncomplicated; the simple addition of meta tag with a common tag results in a new metacontact.</p>
   </section2>
   <section2 topic='Removing a metacontact' anchor='removing'>
-    Similarly, to remove a metacontact all that is required is to remove the meta tags which contribute to the metacontact.
+    <p>Similarly, to remove a metacontact all that is required is to remove the meta tags which contribute to the metacontact.</p>
   </section2>
   <section2 topic='Uniqueness of order within a metacontact' anchor='uniqueness'>
 		<p>Although it is unavoidable that multiple contacts within a metacontact MAY have the same order (due to potentially unavailable information from other accounts), clients SHOULD NOT apply the same order to multiple members of the same metacontact where it is possible to avoid it. If multiple members of a metacontact have the same order, the behaviour is dependent upon the client; it MAY apply rules itself to determine which member to communicate with (based upon presence, recent activity or other methods) it MAY present the user with the option to sort the members such that the orders are again unique, or it MAY employ another appropriate action.</p>

xep-0214.xml

@@ -12,7 +12,7 @@
   <number>0214</number>
   <status>Deferred</status>
   <type>Standards Track</type>
-  <jig>Standards JIG</jig>
+  <sig>Standards</sig>
   <approver>Council</approver>
   <dependencies>
     <spec>XMPP Core</spec>
@@ -98,16 +98,11 @@
   </table>
 </section1>
 <section1 topic='Use Cases' anchor='usecases'>
-    
     <p>The following use cases describe tasks which are already covered by &xep0060; in a more generic context. These tasks are again being provided here in order to demonstrate the functionality provided by this protocol and convey the structure and syntax of the file listing. As a result of this close relationship, many details of PubSub are omitted here for brevity. Consult &xep0060; and &xep0248; for the full specification of node and user management commands as well as their server responses.</p>
-  
   <section2 topic='File Listing' anchor='list'>
-    
     <section3 topic='Publication' anchor='list-publication'>
-      
       <p>Juliet wishes to make her sonnets available for retrieval by the public. She creates a Root Pubsub Collection Node which will contain her file listing:</p>
-      
-      <example caption='Creating a New File Listing'><code><![CDATA[<iq type='set'
+      <example caption='Creating a New File Listing'><![CDATA[<iq type='set'
     from='juliet@capulet.com/balcony'
     to='pubsub.shakespeare.lit'
     id='create3'>
@@ -140,11 +135,9 @@
     </configure>
   </pubsub>
 </iq>
-        ]]></code></example>
-      
+]]></example>
       <p>Juliet also wishes to add a subsection for her sonnets about Romeo. She creates another PubSub Collection Node under the Root Node:</p>
-      
-      <example caption='Adding a Subsection to the Listing'><code><![CDATA[<iq type='set'
+      <example caption='Adding a Subsection to the Listing'><![CDATA[<iq type='set'
     from='juliet@capulet.com/balcony'
     to='pubsub.shakespeare.lit'
     id='create3'>
@@ -178,14 +171,11 @@
     </configure>
   </pubsub>
 </iq>
-        ]]></code></example>
-      
+]]></example>
     </section3>
     <section3 topic='Subscription' anchor='list-subscription'>
-      
       <p>Romeo wishes to view all of Juliet's shared sonnets. To do this, Romeo subscribes to the Root Collection Node:</p>
-      
-      <example caption='Subscription to entire File Listing'><code><![CDATA[<iq type='set'
+      <example caption='Subscription to entire File Listing'><![CDATA[<iq type='set'
     from='romeo@montague.net/orchard'
     to='pubsub.shakespeare.lit'
     id='collsub2'>
@@ -202,14 +192,11 @@
     </options>
   </pubsub>
 </iq>
-          ]]></code></example>
-      
+]]></example>
     </section3>
     <section3 topic='Addition' anchor='list-addition'>
-      
       <p>Juliet has just finished a new sonnet and wishes to announce its availability on her File Listing. She adds the sonnet as a new PubSub Node stored in her Collection Node, then inserts a first revision of her sonnet as an Item within that Node:</p>
-      
-      <example caption='Adding a new File'><code><![CDATA[<iq type='set'
+      <example caption='Adding a new File'><![CDATA[<iq type='set'
     from='juliet@capulet.com/balcony'
     to='pubsub.shakespeare.lit'
     id='create4'>
@@ -311,8 +298,7 @@
     </publish>
   </pubsub>
 </iq>
-]]></code></example>
-      
+]]></example>
       <p>The Item ID is set to 1, signifying the first revision for this file. Subsequent revisions/items will have incremented ID values, like one would see in a versioning system such as CVS or SVN. Implementations MAY follow this convention, but are not required to do so. For example, a given implementation may instead mark revisions using version numbers ("Beta 1", "6.2", etc) or use other arbitrary strings. However, no two revisions of a given file may share the same ID.</p>
       <p>Node IDs MAY take the form of "path/to/file.ext", rather than the randomized string "a6190c5d38e22452041d1c5798eff3f5" provided in the above use case. For example, Juliet's sonnet MAY instead use a Node ID of "juliets_sonnets/sonnet.txt", as long as this ID is unique within the PubSub server. Randomized strings are used in this document to illustrate that Node IDs SHOULD NOT be used for providing information about files.</p> 
       <p>Here is a listing of the possible metadata in a file revision (Item), each field is OPTIONAL:</p>
@@ -326,8 +312,7 @@
         <tr><th>Mirrors</th><td>A list of mirrors; their properties are defined below. If no downloads are available, MAY be left empty or removed entirely.</td></tr>
       </table>
       <p>Because Romeo is now subscribed, he receives notice of Juliet's addition:</p>
-      
-      <example caption='Notification of Addition'><code><![CDATA[<message from='pubsub.shakespeare.lit' to='romeo@montague.net' id='create4'>
+      <example caption='Notification of Addition'><![CDATA[<message from='pubsub.shakespeare.lit' to='romeo@montague.net' id='create4'>
   <event xmlns='http://jabber.org/protocol/pubsub#event'>
     <collection>
       <node id='a6190c5d38e22452041d1c5798eff3f5'>
@@ -374,16 +359,14 @@
     </items>
   </event>
 </message>
-]]></code></example>
-      
+]]></example>
       <p>The above examples give a listing of several possible file transfer protocols in example configurations. Only the sipub mirror type is REQUIRED; the other types are OPTIONAL. Here is a full listing of those protocols and their available settings:</p>
-      
       <table caption="Mirror Types And Their Settings">
         <tr><th>Protocol</th>
           <th>Description</th><th>Ref</th>
           <th>Address</th><th>Port (default)</th>
           <th>User</th><th>Pass</th></tr>
-        <tr><th><link url='#file-requests'>sipub (REQUIRED)</link></th>
+        <tr><th>sipub (REQUIRED)</th>
           <td>OPTIONAL</td><td>N/A</td>
           <td>N/A</td><td>N/A</td>
           <td>N/A</td><td>N/A</td></tr>
@@ -419,7 +402,7 @@
       
       <p>Juliet has revised her sonnet and wishes to publish the new version, while still leaving the original copy available for retrieval. To do this, she inserts a new Item, representing her new revision, into the file's Node:</p>
       
-      <example caption='Adding a new Revision'><code><![CDATA[<iq type='set'
+      <example caption='Adding a new Revision'><![CDATA[<iq type='set'
     from='juliet@capulet.com/balcony'
     to='pubsub.shakespeare.lit'
     id='publish1'>
@@ -458,14 +441,11 @@
     </publish>
   </pubsub>
 </iq>
-          ]]></code></example>
-      
+]]></example>
     </section3>
     <section3 topic='Modification/Deletion' anchor='list-deletion'>
-      
       <p>Juliet has uploaded a copy of her revised sonnet to a new mirror, and wishes to let her subscribers know about this secondary source. She is able to do this by modifying the revision in question to include a reference to her website, overwriting the existing mirrors in the Item with an updated list:</p>
-      
-      <example caption='Modifying a Revision'><code><![CDATA[<iq type='set'
+      <example caption='Modifying a Revision'><![CDATA[<iq type='set'
     from='juliet@capulet.com/balcony'
     to='pubsub.shakespeare.lit'
     id='publish1'>
@@ -501,11 +481,10 @@
     </publish>
   </pubsub>
 </iq>
-          ]]></code></example>
+          ]]></example>
 
       <p>Juliet now wishes to allow others to contribute to her sonnet collection. She gives owner access for the entire Listing to Romeo, and publisher access to her nurse:</p>
-      
-      <example caption='Modifying Users'><code><![CDATA[<iq type='set'
+      <example caption='Modifying Users'><![CDATA[<iq type='set'
     from='juliet@capulet.com/balcony'
     to='pubsub.shakespeare.lit'
     id='ent3'>
@@ -516,11 +495,11 @@
     </affiliations>
   </pubsub>
 </iq>
-          ]]></code></example>
+]]></example>
 
       <p>Romeo uses his owner access to remove the older revision of Juliet's sonnet:</p>
 
-      <example caption='Deleting a Revision'><code><![CDATA[<iq type='set'
+      <example caption='Deleting a Revision'><![CDATA[<iq type='set'
     from='romeo@montague.net/orchard'
     to='pubsub.shakespeare.lit'
     id='retract1'>
@@ -530,18 +509,17 @@
     </retract>
   </pubsub>
 </iq>
-          ]]></code></example>
+]]></example>
 
       <p>Other deletion, modification, and user management operations are available as described in &xep0060; and &xep0248;.</p>
 
     </section3>
   </section2>
-  
   <section2 topic='File Requests' anchor='file-requests'>
 
     <p>Romeo is interested in seeing what files Juliet has made available. To do this, Romeo sends a request to Juliet for repositories which she is associated with:</p>
 
-    <example caption='Request for File Repository listing'><code><![CDATA[<iq type='get'
+    <example caption='Request for File Repository listing'><![CDATA[<iq type='get'
     from='romeo@montague.net/orchard'
     to='juliet@capulet.com'
     id='repolistreq'>
@@ -549,11 +527,11 @@
     <list/>
   </fileshare>
 </iq>
-        ]]></code></example>
+]]></example>
 
     <p>Juliet responds with a list of PubSub nodes where she has published files or which she believes would be interesting to Romeo. If no such locations exist, Juliet SHOULD respond with an empty list.</p>
 
-    <example caption='File Repository listing'><code><![CDATA[<iq type='get'
+    <example caption='File Repository listing'><![CDATA[<iq type='get'
     from='romeo@montague.net/orchard'
     to='juliet@capulet.com'
     id='repolist'>
@@ -564,18 +542,17 @@
     </list>
   </fileshare>
 </iq>
-        ]]></code></example>    
+]]></example>
 
     <p>After browsing Juliet's repository, Romeo has chosen to download her sonnet. The most recent revision of this file contains a listing of available mirrors, and Romeo sees that one of them is an SI stream. Romeo sends an SI request to that mirror:</p>
-    
-    <example caption='Request that a file be sent'><code><![CDATA[<iq type='get'
+    <example caption='Request that a file be sent'><![CDATA[<iq type='get'
     id='sipub-request-0'
     from='romeo@montague.net/orchard'
     to='fileserver@capulet.com'>
   <start xmlns='http://jabber.org/protocol/sipub'
          id='publish-sonnet2.txt'/>
 </iq>
-        ]]></code></example>
+        ]]></example>
 
     <p>The rest of the negotiation and file transfer occurs as described in &xep0137;.</p>
   </section2>

xep-0220.xml

@@ -52,20 +52,20 @@
   </revision>
   <revision>
     <version>0.15</version>
-    <initials>psa/ph</initials>
     <date>2013-08-27</date>
+    <initials>psa/ph</initials>
     <remark><p>Addressed Last Call feedback and made editorial improvements.</p></remark>
   </revision>
   <revision>
     <version>0.14</version>
-    <initials>ph</initials>
     <date>2012-08-21</date>
+    <initials>ph</initials>
     <remark><p>Updated the Security Considerations to describe the 'Unsolicited Dialback Attack' and added recommendations to avoid this attack.</p></remark>
   </revision>
   <revision>
     <version>0.13</version>
-    <initials>ph/psa</initials>
     <date>2012-08-08</date>
+    <initials>ph/psa</initials>
     <remark>
       <ul>
         <li>Allowed same SRV target in multiplexing business</li>

xep-0224.xml

@@ -91,15 +91,14 @@
   ]]></example>
 </section1>
 <section1 topic='Business Rules' anchor='rules'>
-  <p>The following rules apply to generating and processing of the attention extension.
-    <ol>
-      <li>Before sending an attention message stanza, the client SHOULD confirm support for it in the other client as described under <link url='#disco'>Determining Support</link>.</li>
-      <li>The message stanza containing the attention extension MAY contain a body and/or other extensions, which is to be displayed along with executing the attention event.</li>
-      <li>In message stanzas containing either &xep0203; data, attention extensions MUST be ignored, since the attention request is an instant event which SHOULD NOT be replayed after a delay.</li>
-      <li>Messages containing an attention extension SHOULD use the headline message type to avoid offline storage.</li>
-      <li>The attention extension MUST NOT be sent in &IQ; stanzas, since use of this feature is part of a messaging conversation.</li>
-    </ol>
-  </p>
+  <p>The following rules apply to generating and processing of the attention extension.</p>
+  <ol>
+    <li>Before sending an attention message stanza, the client SHOULD confirm support for it in the other client as described under <link url='#disco'>Determining Support</link>.</li>
+    <li>The message stanza containing the attention extension MAY contain a body and/or other extensions, which is to be displayed along with executing the attention event.</li>
+    <li>In message stanzas containing either &xep0203; data, attention extensions MUST be ignored, since the attention request is an instant event which SHOULD NOT be replayed after a delay.</li>
+    <li>Messages containing an attention extension SHOULD use the headline message type to avoid offline storage.</li>
+    <li>The attention extension MUST NOT be sent in &IQ; stanzas, since use of this feature is part of a messaging conversation.</li>
+  </ol>
 </section1>
 <section1 topic='Determining Support' anchor='disco'>
   <p>If an entity wishes to receive the attention extension, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:attention:0":</p>

xep-0226.xml

@@ -20,7 +20,6 @@
   <shortname>profiles</shortname>
   &infiniti;
   &stpeter;
-  <registry/>
   <revision>
     <version>0.3</version>
     <date>2008-11-05</date>

xep-0244.xml

@@ -181,16 +181,14 @@ if (function instanceof IoDataFunction) {
 ]]></code>
 	
 	<section2 topic='Transaction Types' anchor='trans'>
-		<table border="1" caption='IO Data Transaction Types allowed for client to service stanzas'>
-			<thead>
-	    		<tr>
-					<th>Transaction Type</th>
-					<th>Purpose</th>
-					<th>Associated Ad-Hoc Command</th>
-					<th>REQUIRED for generic XEP compatibility</th>
-					<th>Contained Elements</th>
-				</tr>
-			</thead>
+		<table caption='IO Data Transaction Types allowed for client to service stanzas'>
+      <tr>
+        <th>Transaction Type</th>
+        <th>Purpose</th>
+        <th>Associated Ad-Hoc Command</th>
+        <th>REQUIRED for generic XEP compatibility</th>
+        <th>Contained Elements</th>
+      </tr>
 	 		<tr>
 				<th>io-schemata-get</th>
 				<th>To request the schemata of input and output.</th>
@@ -221,16 +219,14 @@ if (function instanceof IoDataFunction) {
 			</tr>
 		</table>
 		
-		<table border="1" caption='IO Data Transaction Types allowed for service to client stanzas'>
-			<thead>
-	    		<tr>
-					<th>Transaction Type</th>
-					<th>Purpose</th>
-					<th>Associated Ad-Hoc Command status value</th>
-					<th>REQUIRED for generic XEP compatibility</th>
-					<th>Contained Elements</th>
-				</tr>
-			</thead>
+		<table caption='IO Data Transaction Types allowed for service to client stanzas'>
+      <tr>
+        <th>Transaction Type</th>
+        <th>Purpose</th>
+        <th>Associated Ad-Hoc Command status value</th>
+        <th>REQUIRED for generic XEP compatibility</th>
+        <th>Contained Elements</th>
+      </tr>
 			<tr>
 				<th>io-schemata-result</th>
 				<th>To return the schemata of input and output.</th>
@@ -281,16 +277,14 @@ if (function instanceof IoDataFunction) {
 <section1 topic='Implementation Notes' anchor='impl'>
 	<p>Commands (= remote procedures) executed with Ad-Hoc Commands and IO Data SHOULD NOT keep the requester in an uncertain state. This means the responder SHOULD respond to the requester always as fast as possible. Thereby the requester acquires the sessionid. (As some remote procedures/calculations are cost-intensive and/or time-consuming the requester MUST "save" this sessionid for the case a network problem occurs.)</p>
 	<p>The Ad-Hoc Command logic applied for the IO Data data container should be associated with the following rules and keywords:</p>
-		<table border="1" caption='Subsequently allowed Ad-Hoc Commands are depending on the state of the service'>
-			<thead>
-	    		<tr>
-					<th>Ad-Hoc Command</th>
-					<th>Keyword</th>
-					<th>Associated Transaction Type</th>
-					<th>Subsequently allowed commands</th>
-					<th>Status description</th>
-				</tr>
-			</thead>
+		<table caption='Subsequently allowed Ad-Hoc Commands are depending on the state of the service'>
+      <tr>
+        <th>Ad-Hoc Command</th>
+        <th>Keyword</th>
+        <th>Associated Transaction Type</th>
+        <th>Subsequently allowed commands</th>
+        <th>Status description</th>
+      </tr>
 	 		<tr>
 				<th>execute</th>
 				<th>Get Schemata</th>

xep-0245.xml

@@ -68,7 +68,7 @@
   ]]></example>
   <p>Each recipient's client would then show the message with a special presentation, such as:</p>
   <example caption="Presentation of /me Command">
-<span style='margin-left: 5%; font-style: italic; color: green;'>* Atlas shrugs in disgust</span>
+* Atlas shrugs in disgust
   </example>
   <p>If the receiving client does not find a match on the string "/me " in the first four characters of the message body, it SHOULD NOT present the text in a special way. For example, the following message bodies do not match:</p>
   <example caption="Some Non-Commands"><![CDATA[
@@ -110,7 +110,7 @@
 <section1 topic='Security Considerations' anchor='security'>
   <p>&xep0045; rooms send XMPP presence stanzas when people leave and join the room, and receiving clients typically show these presence changes as the equivalent of in-room messages, such as the following transformation of a presence stanza of type unavailable:</p>
   <example caption="Presentation of In-Room Presence Notification">
-<span style='margin-left: 5%; font-style: italic; color: green;'>*** Atlas has left the room</span>
+*** Atlas has left the room
   </example>
   <p>A sender could attempt to spoof such a leave message by sending an XMPP groupchat message stanza whose body text is "/me has left the room". Although the presentation of presence joins and leaves is determined by the receiving client and therefore such a notification cannot be universally spoofed for all receivers, a client SHOULD differentiate between presence notifications and /me commands (e.g., with different colors and different prepended characters, such as several asterisks for presence notifications and one asterisk for /me commands).</p>
 </section1>

xep-0248.xml

@@ -77,19 +77,29 @@
       <di>
         <dt>Collection Node</dt>
         <dd>A type of node that contains other nodes but no published items (<em>c.f.</em> Leaf Node).</dd>
+      </di>
 
+      <di>
         <dt>Leaf Node</dt>
         <dd>A type of node that contains published items but no other nodes (<em>c.f.</em> Collection Node).</dd>
+      </di>
 
+      <di>
         <dt>Node Graph</dt>
         <dd>The network of nodes emitting from a given node which contains all its descendants.</dd>
+      </di>
 
+      <di>
         <dt>Root Node</dt>
         <dd>An anonymous collection node used as the <em>de facto</em> beginning of a service's node graph.</dd>
+      </di>
 
+      <di>
         <dt>Subscription Depth</dt>
         <dd>How deep the collection node graph will be traversed when determining whether notifications will be sent. May be any integer, 0 or greater, or "all".</dd>
+      </di>
 
+      <di>
         <dt>Subscription Type</dt>
         <dd>The type of notification, either "nodes", "items", or "all" which the subscriber is interested in.</dd>
       </di>

xep-0252.xml

@@ -101,23 +101,23 @@ Content-Length: 0
   </section2>
   <section2 topic='Changes to the Response Syntax' anchor='script-response'>
     <p>Connection managers MUST make the following changes to convert their responses to Script Syntax:</p>
-    <ol>
-      <li><p>Certain characters within the &lt;body/&gt; element MUST be replaced according to the rules for escaping characters within strings defined by <cite>ECMAScript</cite>. The necessary substitutions are summarised in the table below.</p>
-        <table caption='Character Substitutions'>
-          <tr><th>Character</th><th>Unicode Code Point Value</th><th>Escape sequence</th></tr>
-          <tr><td>"</td><td>U+0022</td><td>\"</td></tr>
-          <tr><td>Line Feed (New Line)</td><td>U+000A</td><td>\n</td></tr>
-          <tr><td>Carriage Return</td><td>U+000D</td><td>\r</td></tr>
-          <tr><td>Line Separator</td><td>U+2028</td><td>\u2028</td></tr>
-          <tr><td>Paragraph Separator</td><td>U+2029</td><td>\u2029</td></tr>
-          <tr><td>\</td><td>U+005C</td><td>\\</td></tr>
-        </table>
-        <p>Each Unicode format-control character (i.e., the characters in category "Cf" in the Unicode Character Database, e.g., LEFT-TO-RIGHT MARK or RIGHT-TO-LEFT MARK) MUST also be substituted by its Unicode escape sequence (e.g. \u200e or \u200f).</p></li>
-      <li><p>The following eight characters MUST be prepended to the &lt;body/&gt; element: <code>_BOSH_("</code></p></li>
-      <li><p>The following two characters MUST be appended to the &lt;body/&gt; element: <code>")</code></p></li>
-      <li><p>If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be either "text/javascript; charset=utf-8" or "application/x-javascript; charset=utf-8".</p></li>
-      <li><p>Include extra HTTP headers to prevent caching or storage by any intermediary.</p></li>
-    </ol>
+    <p>1. Certain characters within the &lt;body/&gt; element MUST be replaced according to the rules for escaping characters within strings defined by <cite>ECMAScript</cite>. The necessary substitutions are summarised in the table below.</p>
+    <table caption='Character Substitutions'>
+      <tr><th>Character</th><th>Unicode Code Point Value</th><th>Escape sequence</th></tr>
+      <tr><td>"</td><td>U+0022</td><td>\"</td></tr>
+      <tr><td>Line Feed (New Line)</td><td>U+000A</td><td>\n</td></tr>
+      <tr><td>Carriage Return</td><td>U+000D</td><td>\r</td></tr>
+      <tr><td>Line Separator</td><td>U+2028</td><td>\u2028</td></tr>
+      <tr><td>Paragraph Separator</td><td>U+2029</td><td>\u2029</td></tr>
+      <tr><td>\</td><td>U+005C</td><td>\\</td></tr>
+    </table>
+    <p>Each Unicode format-control character (i.e., the characters in category "Cf" in the Unicode Character Database, e.g., LEFT-TO-RIGHT MARK or RIGHT-TO-LEFT MARK) MUST also be substituted by its Unicode escape sequence (e.g. \u200e or \u200f).</p>
+    <p>2. The following eight characters MUST be prepended to the &lt;body/&gt; element:</p>
+    <code>_BOSH_("</code>
+    <p>3. The following two characters MUST be appended to the &lt;body/&gt; element:</p>
+    <code>")</code>
+    <p>4. If the client request does not possess a 'content' attribute, then the HTTP Content-Type header of responses MUST be either "text/javascript; charset=utf-8" or "application/x-javascript; charset=utf-8".</p>
+    <p>5. Include extra HTTP headers to prevent caching or storage by any intermediary.</p>
     <p>Note: All line breaks in the bodies of the HTTP responses in the following two examples are included only to improve readability. In practice there MUST be no line breaks.</p>
     <example caption="Session creation response in Script Syntax">
 <![CDATA[HTTP/1.1 200 OK

xep-0255.xml

@@ -395,32 +395,31 @@
 </section1>
 
 <section1 topic='Data Format' anchor='format'>
-  <p>Information about location references in the entity's surrounding, and, if available, the entity's own geodetic coordinates, are provided by the entity and propagated on the network by the entity's associated application (usually a client). The information is structured by means of a &lt;locationquery/&gt; element that is qualified by the 'urn:xmpp:locationquery:0' namespace and nested with in a &lt;iq&gt; element with type set to <i>get</i>.  The location result is provided by the location server and returned to the client in a &lt;iq&gt; element with type set to <i>result</i>.  The location result is structured by means of a &lt;geoloc/&gt; element that is qualified by  the 'http://jabber.org/protocol/geoloc' namespace (see <a href="../xep-0080.html">XEP-0080</a>).</p>
+  <p>Information about location references in the entity's surrounding, and, if available, the entity's own geodetic coordinates, are provided by the entity and propagated on the network by the entity's associated application (usually a client). The information is structured by means of a &lt;locationquery/&gt; element that is qualified by the 'urn:xmpp:locationquery:0' namespace and nested with in a &lt;iq&gt; element with type set to <em>get</em>.  The location result is provided by the location server and returned to the client in a &lt;iq&gt; element with type set to <em>result</em>.  The location result is structured by means of a &lt;geoloc/&gt; element that is qualified by  the 'http://jabber.org/protocol/geoloc' namespace (see <link url="xep-0080.html">XEP-0080</link>).</p>
 
     <table caption='Location Query Child Elements'>
-      <tr class="body">
+      <tr>
          <th>Element Name</th>
          <th>Datatype</th>
          <th>Definition</th>
          <th>Example</th>
-
          <th>Notes</th>
       </tr>
-      <tr class="body">
+      <tr>
          <td>timestamp</td>
          <td>xs:datetime</td>
          <td>UTC time-stamp (MUST conform to the DateTime profile of &xep0082;). </td>
          <td>2004-02-19T21:12Z</td>
          <td>Optional. If individual location references contain own timing information, this time-stamp shall represent GPS time only, otherwise it shall represent all provided info in the query. If not set, the server may assume current time.</td>
       </tr>
-      <tr class="body">
+      <tr>
          <td>publish</td>
          <td>xs:boolean</td>
          <td>A flag specifying whether or not the server should publish the location result to subscribers of the submitting user's XEP-0080 compatible geoloc pub-sub node instead of returning it directly to the submitting user.</td>
          <td>true</td>
          <td>Optional. If present and "true", the server shall publish the entity's location details whenever it changes (suitable for periodic queries) and respond to the query with an empty &lt;iq&gt; stanza with type set to "result". If not specified or "false" the server shall return the location results to the submitting user in the form of a geoloc stanza (XEP-0080) embedded in a &lt;iq&gt; with type set to "result". Default is "false"</td>
       </tr>
-      <tr class="body">
+      <tr>
          <td>lat</td>
          <td>xs:decimal</td>
          <td>Latitude in decimal degrees
@@ -428,14 +427,14 @@
          <td>39.75</td>
          <td>Required if no location references present, otherwise optional. If present, this shall also be present in the result stanza.  If not present, the location server SHOULD estimate a value based on submitted reference data and return with result stanza. The location server is free to decide if the value of this field should be piped directly through to result, or if it should be modified based on reference data or time history information. For instance: if the entity is indoors, the GPS signal will be inaccurate and unstable over time. If wifi references are submitted, the location server may decide that the entity is inside a known building, and return the latitude of this instead.</td>
       </tr>
-      <tr class="body">
+      <tr>
          <td>lon</td>
          <td>xs:decimal</td>
          <td>Longitude in decimal degrees East</td>
          <td>-104.99</td>
-         <td>See notes for <i>lat</i></td>
+         <td>See notes for <em>lat</em></td>
       </tr>
-      <tr class="body">
+      <tr>
          <td>alt</td>
          <td>xs:decimal</td>
          <td>Altitude in meters above or below sea level</td>
@@ -443,48 +442,48 @@
          <td>Optional. If present, this shall also be present in the result stanza with identical value.</td>
       </tr>
 
-      <tr class="body">
+      <tr>
          <td>bearing</td>
          <td>xs:decimal</td>
          <td>GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north</td>
          <td> </td>
-         <td>See notes for <i>alt</i></td>
+         <td>See notes for <em>alt</em></td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>datum</td>
          <td>xs:string</td>
          <td>GPS datum (See XEP-0080)</td>
          <td> </td>
-         <td>See notes for <i>alt</i></td>
+         <td>See notes for <em>alt</em></td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>accuracy</td>
          <td>xs:decimal</td>
          <td>Horizontal GPS accuracy in meters</td>
          <td>10</td>
-         <td>See notes for <i>lat</i></td>
+         <td>See notes for <em>lat</em></td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>speed</td>
          <td>xs:decimal</td>
          <td>The speed at which the entity is moving, in meters per second</td>
          <td>52.69</td>
-         <td>See notes for <i>alt</i></td>
+         <td>See notes for <em>alt</em></td>
       </tr>
-      <tr class="body">
+      <tr>
          <td>references</td>
          <td>locationquery:reference</td>
          <td>A list of identifiable location references observed by the entity</td>
          <td> </td>
-         <td>Required if no <i>lat</i> and <i>lon</i> values specified, otherwise optional. See Table 2 for type definition.</td>
+         <td>Required if no <em>lat</em> and <em>lon</em> values specified, otherwise optional. See Table 2 for type definition.</td>
       </tr>
     </table>
 
     <table caption='Reference Child Elements'>
-      <tr class="body">
+      <tr>
          <th>Element Name</th>
          <th>Datatype</th>
          <th>Definition</th>
@@ -492,28 +491,28 @@
          <th>Notes</th>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>id</td>
          <td>xs:string</td>
-         <td>A world-wide unique reference identifier. This SHALL be composed as follows: <br/><br/>For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code <note>Values of Mobile Country Codes (MCC) are specified by <link url="http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212A-2007-PDF-E.pdf">Annex to ITU Operational Bulletin No. 897 – 1.XII.2007</link>.</note>), MNC is the network carrier code, LAC is the area code and CID is the cell ID.<br/><br/>For wireless access points and Bluetooth devices: The device MAC address.<br/><br/>For IP addresses: the IP address itself (either IPv4 or IPv6).</td>
+         <td>A world-wide unique reference identifier. This SHALL be composed as follows: For cell towers: "MCC:MNC:LAC:CID" where MCC is the mobile country code <note>Values of Mobile Country Codes (MCC) are specified by <link url="http://www.itu.int/dms_pub/itu-t/opb/sp/T-SP-E.212A-2007-PDF-E.pdf">Annex to ITU Operational Bulletin No. 897 – 1.XII.2007</link>.</note>), MNC is the network carrier code, LAC is the area code and CID is the cell ID. For wireless access points and Bluetooth devices: The device MAC address. For IP addresses: the IP address itself (either IPv4 or IPv6).</td>
          <td>207:02:12643:78596</td>
          <td>Required</td>
       </tr>
-      <tr class="body">
+      <tr>
          <td>type</td>
          <td>xs:string</td>
          <td>Reference type as maintained in the registry specified under <link url='#registrar-reftypes'>Reference Types Registry</link></td>
          <td>"cell"</td>
          <td>Required.</td>
       </tr>
-      <tr class="body">
+      <tr>
          <td>signalstrength</td>
          <td>xs:int</td>
          <td>Reference signal strength in dBM. Only appliccable to actively transmitting references (cell towers, wifi access points, Bluetooth devices)</td>
          <td>-64</td>
          <td>Optional.</td>
       </tr>
-      <tr class="body">
+      <tr>
          <td>timestamp</td>
          <td>xs:datetime</td>
          <td>UTC time-stamp (MUST conform to the DateTime profile of &xep0082;). </td>
@@ -523,22 +522,22 @@
     </table>
 
     <table caption='Location Result Child Elements (Copied from XEP-0080 with notes added)'>
-      <tr class="body">
+      <tr>
          <th>Element Name</th>
          <th>Datatype</th>
          <th>Definition</th>
          <th>Example</th>
          <th>Notes</th>
       </tr>
-      <tr class="body">
+      <tr>
          <td>alt</td>
          <td>xs:decimal</td>
          <td>Altitude in meters above or below sea level</td>
          <td>1609</td>
-         <td>Piped directly through from query <i>alt</i> field if set.</td>
+         <td>Piped directly through from query <em>alt</em> field if set.</td>
       </tr>
 
-      <tr class="body">
+      <tr>
          <td>area</td>
          <td>xs:string</td>
          <td>A named area such as a campus or neighborhood</td>
@@ -546,15 +545,15 @@
          <td> </td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>bearing</td>
          <td>xs:decimal</td>
          <td>GPS bearing (direction in which the entity is heading to reach its next waypoint), measured in decimal degrees relative to true north</td>
          <td> </td>
-         <td>Piped directly through from query <i>bearing</i> field if set.</td>
+         <td>Piped directly through from query <em>bearing</em> field if set.</td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>building</td>
          <td>xs:string</td>
          <td>A specific building on a street or in an area</td>
@@ -562,7 +561,7 @@
          <td> </td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>country</td>
          <td>xs:string</td>
          <td>The nation where the user is located</td>
@@ -570,14 +569,14 @@
          <td> </td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>datum</td>
          <td>xs:string</td>
          <td>GPS datum (See notes for XEP-0080)</td>
          <td></td>
-         <td>Piped directly through from query <i>datum</i> field if set.</td>
+         <td>Piped directly through from query <em>datum</em> field if set.</td>
       </tr>
-      <tr class="body">
+      <tr>
          <td>description</td>
          <td>xs:string</td>
          <td>A natural-language name for or description of the location</td>
@@ -585,15 +584,15 @@
          <td>If location is mapped to a place in a place oriented service, this should hold the place description.</td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>accuracy</td>
          <td>xs:decimal</td>
          <td>Horizontal GPS accuracy in meters</td>
          <td>10</td>
-         <td>Piped directly through from query <i>accuracy</i> field or estimated by location server using based on the other information in query and, if possible, differences between several queries over time.</td>
+         <td>Piped directly through from query <em>accuracy</em> field or estimated by location server using based on the other information in query and, if possible, differences between several queries over time.</td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>floor</td>
          <td>xs:string</td>
          <td>A particular floor in a building</td>
@@ -601,16 +600,16 @@
          <td> </td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>lat</td>
          <td>xs:decimal</td>
          <td>Latitude in decimal degrees
          North</td>
          <td>39.75</td>
-         <td>Piped directly through from query <i>lat</i> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
+         <td>Piped directly through from query <em>lat</em> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>locality</td>
          <td>xs:string</td>
          <td>A locality within the administrative region, such as a town or city</td>
@@ -618,15 +617,15 @@
          <td> </td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>lon</td>
          <td>xs:decimal</td>
          <td>Longitude in decimal degrees East</td>
          <td>-104.99</td>
-         <td>Piped directly through from query <i>lon</i> or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
+         <td>Piped directly through from query <em>lon</em> or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>postalcode</td>
          <td>xs:string</td>
          <td>A code used for postal delivery</td>
@@ -634,7 +633,7 @@
          <td> </td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>region</td>
          <td>xs:string</td>
          <td>An administrative region of the nation, such as a state or province</td>
@@ -642,7 +641,7 @@
          <td> </td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>room</td>
          <td>xs:string</td>
          <td>A particular room in a building</td>
@@ -650,15 +649,15 @@
          <td> </td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>speed</td>
          <td>The speed at which the entity is moving, in meters per second</td>
          <td>52.69</td>
          <td>xs:decimal</td>
-         <td>Piped directly through from query <i>speed</i> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
+         <td>Piped directly through from query <em>speed</em> field or estimated by location server based on the other information in query and, if possible, differences between several queries over time.</td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>street</td>
          <td>xs:string</td>
          <td>A thoroughfare within the locality, or a crossing of two thoroughfares</td>
@@ -666,7 +665,7 @@
          <td> </td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>text</td>
          <td>xs:string</td>
          <td>A catch-all element that captures any other information about the location</td>
@@ -674,15 +673,15 @@
          <td>Best practice tip: This field can be used by the server to combine several fields in a natural language style, suitable for simple one-line location presence text. Example: "Near Bob's place" (description + accuracy), "On the road in New York" (locality + speed)</td>
 
       </tr>
-      <tr class="body">
+      <tr>
          <td>timestamp</td>
          <td>xs:datetime</td>
          <td>UTC timestamp specifying the moment when the reading was taken (MUST conform to the DateTime profile of <cite>XEP-0082</cite>)</td>
          <td>2004-02-19T21:12Z</td>
 
-         <td>Piped directly through from query <i>timestamp</i> field.</td>
+         <td>Piped directly through from query <em>timestamp</em> field.</td>
       </tr>
-      <tr class="body">
+      <tr>
          <td>uri</td>
          <td>A URI or URL pointing to
          information about the location</td>
@@ -694,7 +693,7 @@
     </table>
 
     <p>NOTE: The datatypes specified above are defined in &w3xmlschema2;.</p>
-   
+
 </section1>
 
 <section1 topic='Recommended Transport' anchor='transport'>
@@ -714,7 +713,7 @@
   </section2>
 
   <section2 topic='Client Implementation Notes' anchor='client_impl'>
-    <p>For the reasons mentioned above, it is recommended that the client supply both GPS coordinates as well as nearby location references when possible. Also it is recommended that the client submit queries frequently enough to allow the server to analyze changes over time (or lack thereof) to obtain a better result. When possible, the client should include wifi access points in the queries, as these yield much more precise results than cell towers alone (due to the much more limited range). This must however all be weighted against the increased power consumption resulting from keeping network sockets open, scanning for access points and driving a GPS receiver.<br/><br/> For optimal results, clients SHOULD post a location query any time when the set of observed location references change (e.g. a new cell tower is seen or an old one is not seen any more)</p>
+    <p>For the reasons mentioned above, it is recommended that the client supply both GPS coordinates as well as nearby location references when possible. Also it is recommended that the client submit queries frequently enough to allow the server to analyze changes over time (or lack thereof) to obtain a better result. When possible, the client should include wifi access points in the queries, as these yield much more precise results than cell towers alone (due to the much more limited range). This must however all be weighted against the increased power consumption resulting from keeping network sockets open, scanning for access points and driving a GPS receiver. For optimal results, clients SHOULD post a location query any time when the set of observed location references change (e.g. a new cell tower is seen or an old one is not seen any more)</p>
   </section2>
 </section1>
 
@@ -729,7 +728,7 @@
 </section1>
 
 <section1 topic='IANA Considerations' anchor='iana'>
-  <p>This document requires no interaction with the <span class="ref" style=""><a href="http://www.iana.org/">Internet Assigned Numbers Authority (IANA)</a></span> [<a href="notes_iana">7</a>].</p>
+  <p>This document requires no interaction with the &IANA;.</p>
 
 </section1>
 

xep-0258.xml

@@ -198,14 +198,16 @@
         <p>The document details when security label meta-data should or should not be provided, and
             how this meta-data is to be processed.</p>
 
-        <p>This document does not provide: <ul>
-                <li>any mechanism for a client to discover the security policy in force at its home
-                    server, or any other server;</li>
-                <li>any mechanism for a client to discover the user's clearance, or the clearance of
-                    associated with any resource; nor</li>
-                <li>any administrative mechanism for a client to configure configure policy,
-                    clearance, and labels of any resource.</li>
-            </ul> Such mechanisms may be introduced in subsequent documents.</p>
+          <p>This document does not provide:</p>
+          <ul>
+            <li>any mechanism for a client to discover the security policy in force at its home
+              server, or any other server;</li>
+            <li>any mechanism for a client to discover the user's clearance, or the clearance of
+              associated with any resource; nor</li>
+            <li>any administrative mechanism for a client to configure configure policy,
+              clearance, and labels of any resource.</li>
+          </ul>
+          <p>Such mechanisms may be introduced in subsequent documents.</p>
 
         <p>This document does not discuss how one might securely bind a security label to a stanza.
             It is expected a subsequent document will tackle this topic.</p>
@@ -320,10 +322,10 @@
             (based upon the user's authorization) in a particular context (such as in chat room). A
             catalog may not include the complete set of labels available for the use by the client
             in the context.</p>
-        <blockquote>Note: the single catalog per context approach used here is likely inadequate in
+          <p><em>Note:</em> the single catalog per context approach used here is likely inadequate in
             environments where there are a large number of labels in use. It is expected that a more
             sophisticated approach will be introduced in a subsequent revision of this
-            specification.</blockquote>
+            specification.</p>
         <p>As each service domain may have different support for security labels, servers should
             advertise and clients should perform appropriate discovery lookups on a per service
             basis.</p>
@@ -334,17 +336,14 @@
             attribute represents the item's placement in a hierarchical organization of the items.
             If one item has a <tt>selector=</tt> attribute, all items should have a
                 <tt>selector=</tt> attribute. The value of the <tt>selector=</tt> attribute conforms
-            to the <tt>selector-value</tt> ABNF production: <blockquote><tt>
-                <![CDATA[
-selector-value = (<item>"|")*<item>
-]]>
-            </tt></blockquote>
+                to the <tt>selector-value</tt> ABNF production:
         </p>
+        <code><![CDATA[selector-value = (<item>"|")*<item>]]></code>
         <p>where &ITEM; is a sequence of characters not including "|".</p>
         <p>A value of "X|Y|Z" indicates that this item is "Z" in the the "Y" subset of the "X"
             subset of items. This information may be used, for instance, in generating label
             selection menus in graphical user interfaces.</p>
-        <blockquote>Note: use of unnecessarily deep hierarchies should be avoided.</blockquote>
+        <p><em>Note:</em> use of unnecessarily deep hierarchies should be avoided.</p>
         <example caption="Label Catalog Feature Discovery request"><![CDATA[
 <iq type='get'
     to='example.com'
@@ -648,7 +647,6 @@ selector-value = (<item>"|")*<item>
     </section1>
     <section1 topic="XML Schemas" anchor="schema">
         <section2 topic="Extension Schema" anchor="schema-sl">
-            <p>
                 <code><![CDATA[
 <?xml version='1.0' encoding='UTF-8'?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:0"
@@ -748,12 +746,12 @@ selector-value = (<item>"|")*<item>
         </xs:complexType>
     </xs:element>
 </xs:schema>
-    ]]></code> A copy of this schema is available at <link
-                    url="http://xmpp.org/schemas/sec-label.xsd">
-                    http://xmpp.org/schemas/sec-label.xsd</link>. </p>
+]]></code>
+<p>A copy of this schema is available at <link
+    url="http://xmpp.org/schemas/sec-label.xsd">
+    http://xmpp.org/schemas/sec-label.xsd</link>.</p>
         </section2>
         <section2 topic="&lt;catalog/&gt; schema" anchor="schema-catalog">
-            <p>
                 <code><![CDATA[
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:sl="urn:xmpp:sec-label:0"
@@ -850,12 +848,12 @@ selector-value = (<item>"|")*<item>
         </xs:complexType>
     </xs:element>
 </xs:schema>
-    ]]></code> A copy of this schema is available at <link
-                    url="http://xmpp.org/schemas/sec-label-catalog.xsd">
-                    http://xmpp.org/schemas/sec-label-catalog.xsd</link>. </p>
+]]></code>
+<p>A copy of this schema is available at <link
+    url="http://xmpp.org/schemas/sec-label-catalog.xsd">
+    http://xmpp.org/schemas/sec-label-catalog.xsd</link>.</p>
         </section2>
         <section2 topic="&lt;esssecuritylabel/&gt; schema" anchor="schema-ess">
-            <p>
                 <code><![CDATA[
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:ess:0"
@@ -876,9 +874,10 @@ selector-value = (<item>"|")*<item>
         </xs:annotation>
     </xs:element>
 </xs:schema>
-    ]]></code> A copy of this schema is available at <link
-                    url="http://xmpp.org/schemas/sec-label-ess.xsd">
-                    http://xmpp.org/schemas/sec-label-ess.xsd</link>. </p>
+]]></code>
+<p>A copy of this schema is available at <link
+    url="http://xmpp.org/schemas/sec-label-ess.xsd">
+    http://xmpp.org/schemas/sec-label-ess.xsd</link>.</p>
         </section2>
     </section1>
 </xep>

xep-0260.xml

@@ -127,7 +127,7 @@
 </section1>
 
 <section1 topic='Protocol' anchor='protocol'>
-  <para>The basic flow is as follows.</para>
+  <p>The basic flow is as follows.</p>
   <code><![CDATA[
 Initiator                        Responder 
   |                                  |

xep-0272.xml

@@ -52,79 +52,89 @@
 </header>
 
 <section1 topic='Introduction' anchor='intro'>
-&xep0166; is used to negotiate peer to peer media sessions.
-Muji (short for Multiparty Jingle) is a way to coordinate Jingle sessions between a group of people.
-Muji conferences are held in &xep0045; rooms.
+  <p>
+    &xep0166; is used to negotiate peer to peer media sessions.
+    Muji (short for Multiparty Jingle) is a way to coordinate Jingle sessions
+    between a group of people.
+    Muji conferences are held in &xep0045; rooms.
+  </p>
 </section1>
 
 <section1 topic="How it Works" anchor="howitworks">
 
-A Muji conference has a number of contents, each of which has unique name.
-content type, and an encoding. Each participant may provide a stream for each
-content, and communicates which contents they are willing to provide streams
-for, along with encoding information, in their MUC presence. This serves two
-purposes. Firstly, so that each participant knows which contents every other
-participant provides. Secondly, so that there is a global payload type (PT)
-mapping for the various contents, so that clients only need to encode and
-payload each content that they provide once.
+  <p>
+    A Muji conference has a number of contents, each of which has unique name,
+    content type, and an encoding.
+    Each participant may provide a stream for each content, and communicates
+    which contents they are willing to provide streams for, along with encoding
+    information, in their MUC presence.
+    This serves two purposes. Firstly, so that each participant knows which
+    contents every other participant provides.
+    Secondly, so that there is a global payload type (PT) mapping for the
+    various contents, so that clients only need to encode and payload each
+    content that they provide once.
+  </p>
+
+  <p>
+    Participants are not required to participate all the contents that are
+    available.
+    For example, a Muji client might choose to only request audio streams.
+  </p>
 
-Participants are not required to participate all the contents that are
-available. For example, a Muji client might choose to only request audio
-streams.
 </section1>
 
 <section1 topic='Joining a Conference' anchor='joining'>
   <p>
-  Joining a conference is done in two stages. The first step is to
-  declare that preparations are being done to either join or start a muji
-  session inside the MUC. This is indicated by the client sending a presence
-  stanza to the MUC with a preparing element in muji section.
+    Joining a conference is done in two stages. The first step is to
+    declare that preparations are being done to either join or start a muji
+    session inside the MUC. This is indicated by the client sending a presence
+    stanza to the MUC with a preparing element in muji section.
+  </p>
 
   <code><![CDATA[
-    <presence from='wiccarocks@shakespeare.lit/laptop'
-      to='darkcave@chat.shakespeare.lit/oldhag'>
-      <c xmlns="http://jabber.org/protocol/caps"
-        node="http://telepathy.freedesktop.org/wiki/Muji"
-        ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
-        hash="sha-1" />
-      <muji xmlns='http://telepathy.freedesktop.org/muji'>
-        <preparing />
-      </muji>
-    </presence>
-  ]]></code>
-
-  The client MUST then wait until the MUC rebroadcasts its presence message,
-  after which it MUST wait for all other participants that had a preparing
-  element in their presence to finish preparation. Afterwards it should finish
-  it's own preparation by updating its presence with the contents it wants to
-  take part in.
+<presence from='wiccarocks@shakespeare.lit/laptop'
+  to='darkcave@chat.shakespeare.lit/oldhag'>
+  <c xmlns="http://jabber.org/protocol/caps"
+    node="http://telepathy.freedesktop.org/wiki/Muji"
+    ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
+    hash="sha-1" />
+  <muji xmlns='http://telepathy.freedesktop.org/muji'>
+    <preparing />
+  </muji>
+</presence>
+]]></code>
 
-  <code><![CDATA[
-    <presence from='wiccarocks@shakespeare.lit/laptop'
-      to='darkcave@chat.shakespeare.lit/oldhag'>
-      <c xmlns="http://jabber.org/protocol/caps"
-        node="http://telepathy.freedesktop.org/wiki/Muji"
-        ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
-        hash="sha-1" />
-      <muji xmlns='http://telepathy.freedesktop.org/muji'>
-        <content name='video'>
-          <description xmlns='urn:xmpp:jingle:apps:rtp:0' media='video'>
-            <payload-type id='97' name='theora' clockrate='90000'/>
-          </description>
-        </content>
-        <content creator='initiator' name='voice'>
-          <description xmlns='urn:xmpp:jingle:apps:rtp:0' media='audio'>
-            <payload-type id='97' name='speex' clockrate='8000'/>
-            <payload-type id='18' name='G729'/>
-         </description>
-       </content>
-       </muji>
-    </presence>
-  ]]></code>
+  <p>
+    The client MUST then wait until the MUC rebroadcasts its presence message,
+    after which it MUST wait for all other participants that had a preparing
+    element in their presence to finish preparation. Afterwards it should finish
+    it's own preparation by updating its presence with the contents it wants to
+    take part in.
   </p>
+  <code><![CDATA[
+<presence from='wiccarocks@shakespeare.lit/laptop'
+  to='darkcave@chat.shakespeare.lit/oldhag'>
+  <c xmlns="http://jabber.org/protocol/caps"
+    node="http://telepathy.freedesktop.org/wiki/Muji"
+    ver="48QdBuXRCJFb8qIzgy1FOHSGO0U="
+    hash="sha-1" />
+  <muji xmlns='http://telepathy.freedesktop.org/muji'>
+    <content name='video'>
+      <description xmlns='urn:xmpp:jingle:apps:rtp:0' media='video'>
+        <payload-type id='97' name='theora' clockrate='90000'/>
+      </description>
+    </content>
+    <content creator='initiator' name='voice'>
+      <description xmlns='urn:xmpp:jingle:apps:rtp:0' media='audio'>
+        <payload-type id='97' name='speex' clockrate='8000'/>
+        <payload-type id='18' name='G729'/>
+     </description>
+   </content>
+   </muji>
+</presence>
+]]></code>
 
   <p>
-
   When a client adds a payload ID to a content description, it MUST have the
   same codec name and receiving parameters as the corresponding entries in
   other participants' payload maps for that content. For instance, if Alice
@@ -171,9 +181,10 @@ streams.
 
 <section1 topic='Adding a Content Type' anchor='addcontent'>
   <p>
-  Adding a stream follows a process similar to the joining a conference. As a
-  first step an updated presence stanza MUST be send which contains a preparing
-  element as part of the Muji section.
+    Adding a stream follows a process similar to the joining a conference. As a
+    first step an updated presence stanza MUST be send which contains a
+    preparing element as part of the Muji section.
+  </p>
 
   <code><![CDATA[
     <presence from='wiccarocks@shakespeare.lit/laptop'
@@ -194,13 +205,17 @@ streams.
     </presence>
   ]]></code>
 
-  The client MUST then wait until the MUC rebroadcasts its presence message,
-  after which it MUST wait for all other participants that had a preparing
-  element in their presence to finish their changes.
+  <p>
+    The client MUST then wait until the MUC rebroadcasts its presence message,
+    after which it MUST wait for all other participants that had a preparing
+    element in their presence to finish their changes.
+  </p>
 
-  Afterwards the client should add the new content to the muji section of its
-  presence and add the content to all the Jingle sessions it had with
-  participants it shared the content with.
+  <p>
+    Afterwards the client should add the new content to the muji section of its
+    presence and add the content to all the Jingle sessions it had with
+    participants it shared the content with.
+  </p>
 
   <code><![CDATA[
     <presence from='wiccarocks@shakespeare.lit/laptop'
@@ -224,7 +239,6 @@ streams.
        </muji>
     </presence>
   ]]></code>
-  </p>
 </section1>
 
 <section1 topic='Removing a Content Type' anchor='removecontent'>

xep-0273.xml

@@ -186,10 +186,16 @@
         <di>
           <dt>urn:xmpp:sift:stanzas:iq</dt>
           <dd>The server enables the client to sift all &IQ; stanzas or ones that match the specified criteria.</dd>
+        </di>
+        <di>
           <dt>urn:xmpp:sift:stanzas:message</dt>
           <dd>The server enables the client to sift all &MESSAGE; stanzas or ones that match the specified criteria.</dd>
+        </di>
+        <di>
           <dt>urn:xmpp:sift:stanzas:presence</dt>
           <dd>The server enables the client to sift all &PRESENCE; notifications (i.e., presence stanzas with no 'type' or with a type of "unavailable") or ones that match the specified criteria.</dd>
+        </di>
+        <di>
           <dt>urn:xmpp:sift:stanzas:sub</dt>
           <dd>The server enables the client to sift all subscription-related &PRESENCE; stanzas (i.e., presence stanzas with a type of "subscribe", "subscribed", "unsubscribe", or "unsubscribed") or ones that match the specified criteria.</dd>
         </di>
@@ -201,12 +207,20 @@
         <di>
           <dt>urn:xmpp:sift:senders:all</dt>
           <dd>The server shall sift this kind of stanza no matter who the sender is. This is the <strong>default</strong>.</dd>
+        </di>
+        <di>
           <dt>urn:xmpp:sift:senders:local</dt>
           <dd>The server shall sift this kind of stanza only from entities associated with the same local domain as the user itself (not from remote domains).</dd>
+        </di>
+        <di>
           <dt>urn:xmpp:sift:senders:others</dt>
           <dd>The server shall sift this kind of stanza only from other entities (not from the user itself).</dd>
+        </di>
+        <di>
           <dt>urn:xmpp:sift:senders:remote</dt>
           <dd>The server shall sift this kind of stanza only from entities associated with remote domains (not from the same local domain as the user itself).</dd>
+        </di>
+        <di>
           <dt>urn:xmpp:sift:senders:self</dt>
           <dd>The server shall sift this kind of stanza only from the user itself (not from other entities).</dd>
         </di>
@@ -219,8 +233,12 @@
         <di>
           <dt>urn:xmpp:sift:recipients:all</dt>
           <dd>The server shall sift this kind of stanza if the recipient is the bare JID &LOCALBARE; of the user or the full JID &LOCALFULL; of the particular resource. This is the <strong>default</strong>.</dd>
+        </di>
+        <di>
           <dt>urn:xmpp:sift:recipients:bare</dt>
           <dd>The server shall sift this kind of stanza only if the recipient is the bare JID &LOCALBARE; of the user.</dd>
+        </di>
+        <di>
           <dt>urn:xmpp:sift:recipients:full</dt>
           <dd>The server shall sift this kind of stanza only if the recipient is the full JID &LOCALFULL; of the particular resource.</dd>
         </di>

xep-0276.xml

@@ -173,15 +173,18 @@
   <p>To signal the type of communication that is desired, the entity that first shares session presence MAY include a 'reason' attribute on the &lt;decloak/&gt; element. The following values for the 'reason' attribute are defined:</p>
 
   <dl>
-    <dt>media</dt>
-    <dd>Presence is requested for a voice and/or video call, e.g. via &xep0167;.</dd>
-
-    <dt>text</dt>
-
-    <dd>Presence is requested for a textual conversation using an extension that requires capabilities to be disclosed, such as &xep0071;, &xep0085;, &xep0301;, or end-to-end encryption.</dd>
-
-    <dt>file</dt>
-    <dd>Presence is requested for one or more file transfers, e.g. via &xep0234; or &xep0095;.</dd>
+    <di>
+      <dt>media</dt>
+      <dd>Presence is requested for a voice and/or video call, e.g. via &xep0167;.</dd>
+    </di>
+    <di>
+      <dt>text</dt>
+      <dd>Presence is requested for a textual conversation using an extension that requires capabilities to be disclosed, such as &xep0071;, &xep0085;, &xep0301;, or end-to-end encryption.</dd>
+    </di>
+    <di>
+      <dt>file</dt>
+      <dd>Presence is requested for one or more file transfers, e.g. via &xep0234; or &xep0095;.</dd>
+    </di>
   </dl>
 
   <p>Inclusion of the 'reason' attribute can be interpreted by the receiving client as a signal that communication is about to start; for instance, a call accept/reject dialog could double as a UI for accepting or rejecting a session presence request.</p>
@@ -191,7 +194,6 @@
 <section1 topic='Business Rules' anchor='bizrules'>
 
   <p>To limit the extent of the presence leak, the receiving entity SHOULD send only bare presence without the XMPP &PRIORITY;, &SHOW;, or &STATUS; element. Unfortunately, this has two implications:</p>
-  
   <ol>
     <li><p>The initiating entity cannot know which of the receiving entity's resources is more likely to engage in communication. This might imply that the initiating entity will need to send a session initiation request or other communication to more than one of the receiving entity's resources (and then retract the session initiation requests that are not answered by the receiving entity). Solutions to that problem are out of scope for this specification.</p></li>
     <li><p>Establishment of a session might be delayed (e.g., because in Jingle it is desirable to start negotiating candidates as soon as possible but a user interface that prompts the receiving entity to explicitly approve of divulging presence will tend to a delay in call setup). As a result, it may be advantageous to have a way to configure unconditional sharing of session presence in certain deployments, at least within the same trust domain.</p></li>

xep-0278.xml

@@ -118,8 +118,8 @@ All signalling, request, response and publishing is done via XMPP, not requiring
     <stun policy='public' address='200.111.111.111' port='3857' protocol='udp'/>
  </services>
  </iq> ]]></example>
-<em>In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.</em>
-    </section2>        
+ <p><em>In this example 'montague.lit' XMPP Domain a Relay Service and a Tracker Service. The Relay Service can be contacted in order to retrieve Relay Channels. The Tracker Service can be contacted in order to retrieve its known services.</em></p>
+    </section2>
 <section2 topic="Jingle Client Searches for Services on a Retrieved Tracker Service" anchor="clientcheckownserver">
       <p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on the known Tracker Services.</p>
        <example caption="Service List Request"><![CDATA[
@@ -137,8 +137,8 @@ All signalling, request, response and publishing is done via XMPP, not requiring
     type='result'>
  <services xmlns='http://jabber.org/protocol/jinglenodes'/>
  </iq> ]]></example>
-<em>In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.</em>
-    </section2>        
+ <p><em>In this example 'capulet.lit' returned an empty service list, meaning that it does NOT known ANY Relay or Tracker Services.</em></p>
+    </section2>
 <section2 topic="Jingle Client Searches for Services on online Roster Entries" anchor="clientcheckownserver">
       <p>A Jingle Client MAY NOT be satisfied with only one Relay Service entry found. So it keeps the search on his Roster Items until find the desired amount of Relay Services, or while it does NOT exceed a search depth or ANY other Client implementation policy. The Client SHOULD keep a list of visited Tracker Services in order to avoid searching twice in same Service Entity.</p>
        <example caption="Service List Request"><![CDATA[
@@ -157,10 +157,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
  <services xmlns='http://jabber.org/protocol/jinglenodes'>
     <relay policy='roster' address='juliet@capulet.lit/balcony' protocol='udp'/>
  </services>
- </iq> ]]></example>
+ </iq>]]></example>
 <p>In this example 'juliet@capulet.lit/balcony' returned a Relay Service entry that is restricted to its roster. This Service is usable as the requester has 'juliet@capulet.lit/balcony' on its roster. Although, services with policy 'roster' MUST NOT be listed in Tracker Responses expects in Tracker Responses that comes from the Service Entity itself, in this case 'juliet@capulet.lit/balcony'.</p>
-<em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em>
-    </section2>        
+<p><em>In the presented example 'romeo@montague.lit/orchard' knows that 'juliet@capulet.lit/balcony' provides Relay Service, but if another entity requests 'romeo@montague.lit/orchard' its known services, it MUST NOT include 'juliet@capulet.lit/balcony' as it is a roster restricted entry.</em></p>
+    </section2>
     <section2 topic="Jingle Client Consuming the Relay Service" anchor="clientconsumingrelay">
       <p>A Jingle Client with Internet connectivity wheter with direct access to a public IP or not, can potentially provide the Relay Service becaming itself a Jingle Relay Node. The service can intend to provide a public service, or a restricted services based on user preferences, like buddylist, whitelist, blacklist, domain, etc...</p>
       <p>
@@ -188,7 +188,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
  maxkbps='120'
  expire='60'/>
  </iq> ]]></example>
-<em><p>After receiving the &CHANNEL; the requester MUST send his stream to 'host' and 'localport' pair and send a &CANDIDATE; containing the 'host' and 'remoteport' values.</p></em>
+<p><em>After receiving the &CHANNEL; the requester MUST send his stream to 'host' and 'localport' pair and send a &CANDIDATE; containing the 'host' and 'remoteport' values.</em></p>
     </section2>
   </section1>
     <section1 topic="Services Definitions" anchor="servicesdefinition">
@@ -234,30 +234,30 @@ All signalling, request, response and publishing is done via XMPP, not requiring
         <td>id</td>
         <td>A random candidate identifier generated by the Relay Service, which effectively maps to the created Channel; this SHOULD match the XML Nmtoken production <note>See &lt;<link url='http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken'>http://www.w3.org/TR/2000/WD-xml-2e-20000814#NT-Nmtoken</link>&gt;</note> so that XML character escaping is not needed for characters such as '&amp;'. In some situations the Jingle session identifier might have security implications. See &rfc4086; regarding requirements for randomness.</td>
         <td>REQUIRED on response, NOT RECOMMENDED on requests</td>
-      </tr>      
+      </tr>
       <tr>
         <td>host</td>
-        <td>The IP address or Host address of the Relay Channel.</td> 
+        <td>The IP address or Host address of the Relay Channel.</td>
         <td>REQUIRED on response</td>
       </tr>
       <tr>
         <td>localport</td>
-        <td>The port number to be used by the channel requester.</td> 
+        <td>The port number to be used by the channel requester.</td>
         <td>REQUIRED on response</td>
       </tr>
       <tr>
         <td>remoteport</td>
-        <td>The port number to be offered to the remote party.</td> 
+        <td>The port number to be offered to the remote party.</td>
         <td>REQUIRED on response</td>
       </tr>
       <tr>
         <td>protocol</td>
-        <td>The protocol supported by the retrieved channel.</td> 
+        <td>The protocol supported by the retrieved channel.</td>
         <td>REQUIRED on response</td>
       </tr>
       <tr>
         <td>maxkbps</td>
-        <td>The maximum bandwidth supported by the channel.</td> 
+        <td>The maximum bandwidth supported by the channel.</td>
         <td>OPTIONAL on response, NOT RECOMMENDED on requests.</td>
       </tr>
       <tr>
@@ -277,10 +277,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
   <section3 topic='Remoteport Attribute' anchor='def-remoteport'>
     <p>The value of the 'remoteport' attribute MUST be a valid IP Port number. This port MUST be used as media traffic destination port of the other party. Channel requester MUST use this port value in the candidate offer in combination with the 'host' attribute. Channel requester MUST NOT send any media stream to this port.</p>
     <p>For transparent compatibility with major RTP Proxy Deployments, an RCTP Port is allocated and defined by default at Remoteport Attribute Value plus one. (Localport + 1)</p>
-  </section3>  
+  </section3>
   <section3 topic='Protocol Attribute' anchor='def-protocol'>
     <p>The value of the 'protocol' attribute MUST be a valid protocol value: 'udp' or 'tcp' as also defined in the <link url='#schema'>XML Schema</link></p>
-  </section3>  
+  </section3>
     <section3 topic='Maxkbps Attribute' anchor='def-maxkbps'>
     <p>The value of the 'maxkbps' attribute MUST be a valid integer value representing the maximum kilobits per seconds the channel supports. This attribute is optional and MAY be used in Relay Channel with bandwidth limitation.</p>
   </section3>
@@ -375,15 +375,10 @@ All signalling, request, response and publishing is done via XMPP, not requiring
           <p>Relay Channels auto expires MUST expire on traffic inactivity. The inactivity timeout recommended is 60 seconds.</p>
     <p>It is heavily recommended that the Super Node implements throttle:</p>
     <ul>
-      <p>
         <li>Based on JID, allowing the control of how many concurrent channels an specific JID can have.</li>
-      </p>
-      <p>
         <li>Based on JID, allowing the control of how many channel requests an specific JID can request in a time period.</li>
-      </p>
-      <p>
         <li>Based on Bandwidth, allowing the control of how much bandwidth a channel can use. The maximum bandwidth SHOULD be included on the candidate element provided by a Super Node on the attribute maxkbps. If no attribute is present, it means that it has no bandwidth control.</li>
-      </p>
+    </ul>
       <example caption="Channel Returned by a Node with bandwidth throttle (stub)"><![CDATA[
 <channel component='1'
  id='el0747fg11'
@@ -392,8 +387,7 @@ All signalling, request, response and publishing is done via XMPP, not requiring
  remoteport='35802'
  protocol='udp'
  maxkbps='120'/>
-  ]]></example>
-    </ul>
+]]></example>
   </section1>
   <section1 topic='XML Schema' anchor='schema'>
   <code><![CDATA[

xep-0280.xml

@@ -248,15 +248,14 @@
 
 <section1 topic='Messages Eligible for Carbons Delivery' anchor='which-messages'>
     <p>The focus of this specification is instant messaging applications and so those (and only those) &MESSAGE; stanzas used for instant messaging SHOULD be delivered as Carbons. Defining precisely which messages are used for instant messaging and which are not is difficult, as future specifications may add additional payloads used for, or not used for, instant messaging; as such, the rules for which messages are eligible for carbons delivery is left as an implementation detail for servers. The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules:</p>
-    <p>Possible delivery rules:
-        <ul>
-            <li>A &MESSAGE; is eligible for carbons delivery if it is of type "chat".</li>
-            <li>A &MESSAGE; is eligible for carbons delivery if it is of type "normal" and it contains a &lt;body&gt; element.</li>
-            <li>A &MESSAGE; is eligible for carbons delivery if it is of type "error" and sent in response to a &MESSAGE; that was itself eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).</li>
-	    <li>A &MESSAGE; is not eligible for carbons delivery if it is determined to have been sent by a MUC room or service, even if it would be otherwise eligible (this also includes private messages from MUC participants).</li>
-            <li>A &MESSAGE; is not eligible for carbons delivery if it does not meet any of these criteria.</li>
-        </ul>
-    </p>
+    <p>Possible delivery rules:</p>
+    <ul>
+      <li>A &MESSAGE; is eligible for carbons delivery if it is of type "chat".</li>
+      <li>A &MESSAGE; is eligible for carbons delivery if it is of type "normal" and it contains a &lt;body&gt; element.</li>
+      <li>A &MESSAGE; is eligible for carbons delivery if it is of type "error" and sent in response to a &MESSAGE; that was itself eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).</li>
+      <li>A &MESSAGE; is not eligible for carbons delivery if it is determined to have been sent by a MUC room or service, even if it would be otherwise eligible (this also includes private messages from MUC participants).</li>
+      <li>A &MESSAGE; is not eligible for carbons delivery if it does not meet any of these criteria.</li>
+    </ul>
     <p>As this is a implementation detail of servers, clients MUST NOT rely on the server implementing a particular set of rules for which messages are eligible for Carbons delivery.</p>
     <p>Future specifications may have more precise requirements on which messages need to be eligible for carbons delivery; such future specifications will provide their own discovery and negotiation mechanisms, such that a client negotiating Carbons using the protocol defined in this specification will cause the server to consider messages eligible for Carbons delivery based on the requirements described herein.</p>
     <p>Note: previous versions of this specification limited eligible messages to those of type "chat" - however, this was generally found to be inadequate due to the proliferation of type "normal" messages used in instant messaging.</p>

xep-0281.xml

@@ -51,7 +51,7 @@
 
 <section1 topic='Introduction' anchor='intro'>
 
-  <p class='box'><em>Note: This document has been retracted by the author in favor of &xep0289;.</em></p>
+  <p><em>Note: This document has been retracted by the author in favor of &xep0289;.</em></p>
 
   <section2 topic='Motivation' anchor='motivation'>
     <p>&xep0045; defines a full-featured technology for multi-user text conferencing in XMPP. By design, <cite>XEP-0045</cite> assumes that a conference room is hosted at a single service, which can be accessed from any point on the network. However, this assumption introduces a single point of failure for the conference room, since if occupants at a using domain lose connectivity to the hosting domain then they also lose connectivity to the room. In some deployment scenarios (and even on the open Internet) this behavior is suboptimal. Therefore, this document attempts to define a technology for distributing MUC rooms across multiple services.</p>
@@ -459,7 +459,7 @@
 </section1>
 
 <section1 topic='Determining Support' anchor='support'>
-    <p>If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" &NSVER; in response to service discovery information requests.</p>
+  <p>If a MUC service supports distributed rooms, it MUST return a feature of "urn:xmpp:dmuc:0" in response to service discovery information requests.</p>
 </section1>
 
 <section1 topic='Security Considerations' anchor='security'>

xep-0283.xml

@@ -110,18 +110,22 @@
 
 <section1 topic='The Move'>
   <p>In this scenario user@example.com moves to user2@example2.com. 
-  Both the user@example.com and user2@example2.com accounts have been
-  created and still exist. The roster for user@example2.com is empty
-  and the user wants to populate it with their entries from 
-  user@example.com.</p>
+    Both the user@example.com and user2@example2.com accounts have been
+    created and still exist. The roster for user@example2.com is empty
+    and the user wants to populate it with their entries from 
+    user@example.com.</p>
 
   <dl>
-  <dt><strong>original JID</strong></dt>
-  <dd>user@example.com</dd>
-  <dt><strong>new JID</strong></dt>
-  <dd>user2@example2.com</dd>
+    <di>
+      <dt>original JID</dt>
+      <dd>user@example.com</dd>
+    </di>
+    <di>
+      <dt>new JID</dt>
+      <dd>user2@example2.com</dd>
+    </di>
   </dl>
-  
+
   <section2 topic='Unsubscribing the original JID from outbound subscriptions'
             anchor='unsubscribe'>
     <p>Because the original JID is no longer going to be used, the user SHOULD 
@@ -140,14 +144,12 @@
     JID to the user. See the Security Considerations section for 
     details.</p>
 
-    <example caption='Client unsubscribes outbound subscriptions from original JID'>
-<![CDATA[
+    <example caption='Client unsubscribes outbound subscriptions from original JID'><![CDATA[
 <presence from='user@example.com' to='contact@example.com' type='unsubscribe'>
     <status>I've changed JIDs from user@example.com to user2@example2.com</status>
     <moved xmlns='urn:xmpp:moved:0' new='user2@example2.com'/>
 </presence>
-]]>
-    </example>
+]]></example>
 
   </section2>
 

xep-0284.xml

@@ -12,6 +12,7 @@
   <number>0284</number>
   <status>Deferred</status>
   <type>Standards Track</type>
+  <sig>Standards</sig>
   <approver>Council</approver>
   <dependencies>
     <spec>XMPP Core</spec>

xep-0287.xml

@@ -42,15 +42,14 @@
   </revision>
 </header>
 <section1 topic='Introduction' anchor='intro'>
-  <p>There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough:
-    <ul>
-      <li>&xep0016; and &xep0191; define blocking mechanism only which is not always appropriate.</li>
-      <li>&xep0158; interacts badly with automated software such as gateways.</li>
-      <li>&xep0268; implies trusted network of servers.</li>
-      <li>&xep0275; concentrates on ranking only.</li>
-    </ul>
-    Service administrators might want to deploy server-based spim recognition software to fill in the gaps. However, every automated spim recognition suffers from <em>false positives</em> - situations where a stanza incorrectly qualified as spim. To avoid them, a spim filter doesn't block suspicious stanza, but marks it and sends to a client in a regular manner. A client software doesn't need to interrupt a user when processing such marked stanzas: for example, it may put them silently in "SPAM" folder, so a user can look through them at any time later. Furthermore, a spim filter may take user's experience into account. When a user receives an unsolicited stanza, he or she can mark it as spim. In this case a client software sends an automatic complaint to a server-based spim filter. This specification deals with both cases. Thus, in contrast to &xep0159;, it doesn't introduce any spim blocking techniques. Also, the various spim recognition procedures that may be employed by the server are beyond the scope of this document.
-  </p>
+  <p>There are various spim protection methods exist in XMPP: &xep0016;, &xep0158;, &xep0191;, &xep0268; and &xep0275;. But they may not be sufficient enough:</p>
+  <ul>
+    <li>&xep0016; and &xep0191; define blocking mechanism only which is not always appropriate.</li>
+    <li>&xep0158; interacts badly with automated software such as gateways.</li>
+    <li>&xep0268; implies trusted network of servers.</li>
+    <li>&xep0275; concentrates on ranking only.</li>
+  </ul>
+  <p>Service administrators might want to deploy server-based spim recognition software to fill in the gaps. However, every automated spim recognition suffers from <em>false positives</em> - situations where a stanza incorrectly qualified as spim. To avoid them, a spim filter doesn't block suspicious stanza, but marks it and sends to a client in a regular manner. A client software doesn't need to interrupt a user when processing such marked stanzas: for example, it may put them silently in "SPAM" folder, so a user can look through them at any time later. Furthermore, a spim filter may take user's experience into account. When a user receives an unsolicited stanza, he or she can mark it as spim. In this case a client software sends an automatic complaint to a server-based spim filter. This specification deals with both cases. Thus, in contrast to &xep0159;, it doesn't introduce any spim blocking techniques. Also, the various spim recognition procedures that may be employed by the server are beyond the scope of this document.</p>
 </section1>
 <section1 topic='Requirements' anchor='reqs'>
   <p>An implementation compliant with this document MUST support spim markers as described in <link url='#spim-marker'>Spim Marker</link> use case. Support for spim reports, as described in <link url='#spim-report'>Spim Report</link> use case, is RECOMMENDED.</p>
@@ -142,13 +141,12 @@
 </section1>
 <section1 topic='Business Rules' anchor='rules'>
   <p>A filtering entity SHOULD only add &lt;mark/&gt; or &lt;report/&gt; elements and a receiving entity SHOULD only process those elements if the corresponding stanza envolves an interaction with a human user: subscription requests, messages, conference invites, voice calls, etc. For example, it doesn't make a lot of sense to mark &xep0232; stanzas.</p>
-  <p>To avoid obvious false positives and user confusions, a filtering entity SHOULD NOT add &lt;mark/&gt; or &lt;report/&gt; elements to a stanza and a receiving entity SHOULD ignore &lt;mark/&gt; and &lt;report/&gt; elements of a stanza if:
-    <ul>
-      <li>The receiving entity has the sender's subscription information of the type "both", "from" or "to".</li>
-      <li>The receiving entity has pending subscription to the sender, i.e. subscription of type "none" and ask='subscribe'.</li>
-      <li>The receiving entity has sent direct presence to the sender.</li>
-    </ul>
-  </p>
+  <p>To avoid obvious false positives and user confusions, a filtering entity SHOULD NOT add &lt;mark/&gt; or &lt;report/&gt; elements to a stanza and a receiving entity SHOULD ignore &lt;mark/&gt; and &lt;report/&gt; elements of a stanza if:</p>
+  <ul>
+    <li>The receiving entity has the sender's subscription information of the type "both", "from" or "to".</li>
+    <li>The receiving entity has pending subscription to the sender, i.e. subscription of type "none" and ask='subscribe'.</li>
+    <li>The receiving entity has sent direct presence to the sender.</li>
+  </ul>
 </section1>
 <section1 topic='Determining Support' anchor='support'>
   <p>If an entity supports the spim markers, it MUST report that by including a service discovery feature of "urn:xmpp:spim-marker:0" in response to a &xep0030; information request. If an entity supports the spim reports, it MUST report that by including a service discovery feature of "urn:xmpp:spim-report:0" in response to a &xep0030; information request:</p>

xep-0289.xml

@@ -81,14 +81,12 @@
     <li>alice@wonderland.lit - User on wonderland.lit</li>
     <li>hatter@wonderland.lit - User on wonderland.lit</li>
     <li>rabbithole@rooms.wonderland.lit - MUC room / FMUC node.</li>
-    <br/>
     <li>denmark.lit - service, likely connected to wonderland.lit over constrained link</li>
     <li>talk.denmark.lit - MUC service on denmark.lit.</li>
     <li>hamlet@denmark.lit - User on denmark.lit</li>
     <li>ophelia@denmark.lit - User on denmark.lit</li>
     <li>elsinore@talk.denmark.lit - MUC room / FMUC node.</li>
   </ul>
-  <p></p>
 </section1>
 
 <section1 topic='Use Cases' anchor='usecases'>
@@ -371,8 +369,6 @@
 
 
 <section1 topic='Business Rules' anchor='rules'>
-  <ul>
-  </ul>
 </section1>
 <!--<section1 topic='Implementation Notes' anchor='impl'>
   <p>OPTIONAL.</p>

xep-0292.xml

@@ -16,8 +16,8 @@
   <approver>Council</approver>
   <dependencies>
     <spec>XMPP Core</spec>
-    <spec><cite>RFC 6350</cite></spec>
-    <spec><cite>RFC 6351</cite></spec>
+    <spec>RFC 6350</spec>
+    <spec>RFC 6351</spec>
   </dependencies>
   <supersedes>
     <spec>XEP-0054</spec>
@@ -289,19 +289,17 @@
     </section3>
 
   </section2>
-  
   <section2 topic='Event Notifications' anchor='self-pubsub'>
     <p>&xep0060; provides a way to subscribe to events, and &xep0163; defines a pubsub profile for events associated with instant messaging (IM) accounts. If PEP is supported by an IM server, it can be used to automatically generate event notifications when a user's vCard is modified.</p>
     <section3 topic='Location' anchor='self-pubsub-location'>
       <p>The canonical location for notifications regarding a user's vCard is a pubsub node whose name is "urn:xmpp:vcard4".</p>
     </section3>
     <section3 topic='Subscribing to vCard Notifications' anchor='self-pubsub-subscribe'>
-      <p>Let us imagine that Juliet wishes to receive the updates that Romeo publishes to his vCard. She has two options:
+      <p>Let us imagine that Juliet wishes to receive the updates that Romeo publishes to his vCard. She has two options:</p>
       <ol>
         <li>Implicitly subscribe by advertising support for "urn:xmpp:vcard4+notify" in her &xep0115; data. Romeo's PEP service then automatically sends vCard updates to her when it receives presence from her, until and unless she sends presence of type unavailable or stops advertising an interest in vCard updates. This is in accordance with XEP-0060, section 6.1.</li>
         <li>Explicitly subscribe by sending a formal subscription request to the "urn:xmpp:vcard4" node at Romeo's JabberID. Romeo's PEP service might send her all vCard updates even if she is offline at the time (depending on service policies regarding presence integration).</li>
       </ol>
-    </p>
     </section3>
     <section3 topic='Receiving a vCard Notification'>
       <p>Because Juliet has sent presence to Romeo including Entity Capabilities data that includes the "urn:xmpp:vcard4+notify" feature, Romeo's XMPP server will send a PEP notification to Juliet. The notification can include an XMPP message body for backward-compatibility with XMPP clients that are not pubsub-capable. This is in accordance with XEP-0060, second 6.1.7.</p>

xep-0293.xml

@@ -21,16 +21,19 @@
     <spec>XEP-0167</spec>
     <spec>RFC 4585</spec>
   </dependencies>
+  <supersedes/>
+  <supersededby/>
+  <shortname>NOT_YET_ASSIGNED</shortname>
   <schemaloc>
     <url>http://xmpp.org/schemas/jingle-apps-rtp-rtcp-fb.xsd</url>
   </schemaloc>
+  <discuss>jingle</discuss>
   <author>
     <firstname>Olivier</firstname>
     <surname>Crête</surname>
     <email>olivier.crete@collabora.co.uk</email>
     <jid>olivier.crete@collabora.co.uk</jid>
   </author>
-  <discuss>jingle</discuss>
   <revision>
     <version>1.0</version>
     <date>2015-08-11</date>
@@ -110,10 +113,10 @@
     <td>The subtype (depends on the type)</td>
     <td>OPTIONAL (possibly REQUIRED depending on the type)</td>
     <td>
-      ack: rpsi, app<br/>
-      nack: sli, pli, rpsi, app, rai<br/>
-      ccm: fir, tmmbr, tstr, vbcm<br/>
-      app: depends on the application<br/>
+      ack: rpsi, app;
+      nack: sli, pli, rpsi, app, rai;
+      ccm: fir, tmmbr, tstr, vbcm;
+      app: depends on the application;
     </td>
   </tr>
 </table>

xep-0294.xml

@@ -20,16 +20,19 @@
     <spec>XEP-0167</spec>
     <spec>RFC 5285</spec>
   </dependencies>
+  <supersedes/>
+  <supersededby/>
+  <shortname>NOT_YET_ASSIGNED</shortname>
   <schemaloc>
     <url>http://xmpp.org/schemas/jingle-apps-rtp-rtp-hdrext.xsd</url>
   </schemaloc>
+  <discuss>jingle</discuss>
   <author>
     <firstname>Olivier</firstname>
     <surname>Crête</surname>
     <email>olivier.crete@collabora.co.uk</email>
     <jid>olivier.crete@collabora.co.uk</jid>
   </author>
-  <discuss>jingle</discuss>
   <revision>
     <version>1.0</version>
     <date>2015-08-11</date>

xep-0295.xml

@@ -20,7 +20,7 @@
     <spec>XMPP Core</spec>
   </dependencies>
   <supersedes/>
-  <supersededby>XEP-0335</supersededby>
+  <supersededby><spec>XEP-0335</spec></supersededby>
   <shortname>N/A</shortname>
   &ksmith;
   &mwild;
@@ -165,7 +165,7 @@
   <p>Beautiful, elegant <em>and</em> efficient at the same time.</p>
 </section1>
 <section1 topic='Internationalization Considerations' anchor='i18n'>
-  <p>It is hoped that this representation introduces no new internationalization considerations, although it is acknowledged that if there are cultures where the symbols <code>{}:</code> are considered to be more offensive than <code>&lt;>=</code> the legacy XML encoding may be preferred.</p>
+  <p>It is hoped that this representation introduces no new internationalization considerations, although it is acknowledged that if there are cultures where the symbols <tt>{}:</tt> are considered to be more offensive than <tt>&lt;>=</tt> the legacy XML encoding may be preferred.</p>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
   <p>Implementors should be aware that the JSON encoding involves 8 additional bytes for each stanza, and this introduces a considerable risk of buffer over-flow attacks. While new codebases will hopefully be designed with this in mind, existing codebases will need to be entirely upgraded, with every buffer increased in size by at least 8 bytes to address this potentially serious potential vulnerability.</p>

xep-0296.xml

@@ -74,7 +74,7 @@
       <li>any &PRESENCE; update from any resource for the conversee's bare JID, including &lt;presence type='unavailable'/&gt;. The client SHOULD revert to the initial state,  sending any following correspondence to the conversee's bare JID.</li>
     </ul>
   </section2>
-  <section2 topic='Interactions with Chat States' id='interact-csn'>
+  <section2 topic='Interactions with Chat States' anchor='interact-csn'>
     <p>If a client supports &xep0085;, then the following additional considerations apply:</p>
     <ul>
       <li>If a client receives a &MESSAGE; with a &lt;gone xmlns='http://jabber.org/protocol/chatstates'/&gt; chat state, it SHOULD unlock the coversation.</li>

xep-0298.xml

@@ -26,6 +26,7 @@
     <supersedes />
     <supersededby />
     <shortname>coin</shortname>
+    <discuss>jingle</discuss>
     <author>
       <firstname>Emil</firstname>
       <surname>Ivov</surname>
@@ -44,7 +45,6 @@
       <email>saul@ag-projects.com</email>
       <jid>saul@ag-projects.com</jid>
     </author>
-    <discuss>jingle</discuss>
     <revision>
       <version>0.2</version>
       <date>2015-07-02</date>