From fb2965af2c9d3f395db469c9eb5c6a2c1723c8e7 Mon Sep 17 00:00:00 2001
From: Sam Whited <sam@samwhited.com>
Date: Fri, 27 Jan 2017 10:21:09 -0600
Subject: [PATCH] XEP-0369: Cleanup trailing whitespace

---
 xep-0369.xml | 34 +++++++++++++++++-----------------
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/xep-0369.xml b/xep-0369.xml
index 738655e2..5770565f 100644
--- a/xep-0369.xml
+++ b/xep-0369.xml
@@ -256,7 +256,7 @@
     <p>
       A MIX channel does not send messages and presence directly to an XMPP MIX client of a channel participant, but addresses them to participant using the participant's bare JID. The participant's server must then handle these messages and pass them on to zero, one or multiple clients.   To enable MIX to work, this behaviour is necessary and so the server of every MIX client must follow the rules set out in this specification.
 This approach  enables flexible support of multiple clients for a MIX channel participant.
-       The MIX model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the client's bare JID. 
+       The MIX model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the client's bare JID.
        There are a number of MIX requirements on behaviour of the MIX Participant's server, which are summarized here:
      </p>
     <ol>
@@ -2104,11 +2104,11 @@ A client creates a channel by sending a simple request to the MIX service.   A c
   <jid xmlns='urn:xmpp:mix:0'>coven+123456@mix.shakespeare.example</jid>
 </message>
 ]]></example>
-    
+
   <p>
-    The following example shows how the participant's server modifies the inbound message to replace the bare JID in the 'to' with a full JID for each of two active MIX clients.    
-  </p>  
-    
+    The following example shows how the participant's server modifies the inbound message to replace the bare JID in the 'to' with a full JID for each of two active MIX clients.
+  </p>
+
     <example caption="Participant's Server Sends Modified Message to two Clients"><![CDATA[
 <message from='coven@mix.shakespeare.example'
          to='hecate@shakespeare.example/pda3'
@@ -2135,18 +2135,18 @@ A client creates a channel by sending a simple request to the MIX service.   A c
     <p>
       Messages sent by a MIX channel participant to the MIX channel are always sent from a MIX client directly to the channel. The participant's server relays the message but does not modify the messages.
     </p>
-  </section2>   
-    
+  </section2>
+
   <section2 topic="IQ Support on Local Server" anchor="mix-diso">
   <p>
-    The MIX specification requires that some IQ messages MUST or MAY come from the participant's server, and not directly from the client.   
-   This indirect operation enables the participant's server to use information from the client to improve the service provided to the client.  
+    The MIX specification requires that some IQ messages MUST or MAY come from the participant's server, and not directly from the client.
+   This indirect operation enables the participant's server to use information from the client to improve the service provided to the client.
     The following table shows which IQs are direct from client, indirect through the local server or may be either.
   </p>
-    
+
     <table caption="IQ Direct vs Indirect">
       <tr><th>Action</th><th>Direct or Indirect</th></tr>
-      
+
        <tr><td>MIX Service Discovery</td><td>Direct</td></tr>
       <tr><td>MIX Service Information Discovery</td><td>Direct</td></tr>
       <tr><td>MIX Channel Discovery</td><td>Either</td></tr>
@@ -2162,9 +2162,9 @@ A client creates a channel by sending a simple request to the MIX service.   A c
     </table>
     <p>
       The rest of this section describes how indirect discovery is achieved, using channel join as an example.
-      
+
       The client addresses indirect messages to the user's own bare JID, indicating the channel with the channel attribute.  This is illustrated below.
-      
+
     </p>
   <example caption="Client sends request to local server to Join a MIX Channel"><![CDATA[
 <iq type='set'
@@ -2181,9 +2181,9 @@ A client creates a channel by sending a simple request to the MIX service.   A c
   </join>
 </iq>
 ]]></example>
-   
+
    <p>This is then modified by the local server and sent to the MIX channel.  This is shown in the following example, repeated from the earlier specification of channel behaviour. </p>
-    
+
     <example caption="Participant's Server sends Join to MIX Channel"><![CDATA[
 <iq type='set'
     from='hag66@shakespeare.example'
@@ -2198,12 +2198,12 @@ A client creates a channel by sending a simple request to the MIX service.   A c
   </join>
 </iq>
 ]]></example>
-    
+
   <p>
     The MIX service will send the IQ response to indirect messages to the user's server using the user's bare JID.   The user's server will then route the response back to the user's client.
   </p>
   </section2>
-  
+
 
   <section2 topic="Roster Management" anchor="proxy-roster">
     <p>