Remove spaces at the end of CDATA blocks in all XEPs.

sed -i 's/^\s\+]]>/]]>/g' xep-*.xml

xep-0001.xml

@@ -846,6 +846,6 @@ THE SOFTWARE.
   </xs:simpleType>
 
 </xs:schema>
-  ]]></code>
+]]></code>
 </section1>
 </xep>

xep-0003.xml

@@ -90,14 +90,14 @@
     <expire>600</expire>
   </query>
 </iq>
-  ]]></example>
+]]></example>
   <example caption='Result from PASS Service'><![CDATA[
 <iq id='pass1' type='result' from='pass.jabber.org'>
   <query xmlns='jabber:iq:pass'>
     <server port='43253'>1.2.3.4</server>
   </query>
 </iq>
-  ]]></example>
+]]></example>
   <p>At this point, the PASS service is now listening on the given IP and port for incoming connections on behalf of the Jabber Entity. The provided IP and port can now be sent to any other entity as a connection point, for file transfers or any other use.</p>
   <p>The default behavior for the PASS service is to listen on the port forever, unless the requesting client specifies an &lt;expire/&gt; value (in seconds).  If the service is not configured with an expire value, it will not timeout the connection, and will start listening on the port again after one of the two sides disconnects.</p>
   <table caption='Error Codes'>
@@ -125,15 +125,15 @@
     <proxy port='43523'>1.2.3.4</proxy>
   </query>
 </iq>
-  ]]></example>
+]]></example>
   <example caption='IQ result to accept connection'><![CDATA[
 <iq type='result'
     id='pass2'
     from='[email protected]/resource'
     to='pass.jabber.org'>
   <query xmlns='jabber:iq:pass'/>
 </iq>
-  ]]></example>
+]]></example>
   <p>The entity SHOULD now immediately connect to the given proxy IP and port, and upon connection all data written to that socket will be copied to the client connection, and vice-versa. Any disconnect on either side MUST cause a disconnect on the other (initiated by the service). If the IQ set to the entity fails or returns an error, the client socket MUST be dropped as well. The client XML element provides the information about the remote end of the incoming socket.</p>
   <p>Abuse in bandwidth or resources could become an issue, so PASS implementations SHOULD include strict and detailed rate and usage limits, allowing only limited usage by single entities and rate-limiting bandwidth used if necessary for both single connections or overall usage. These limits are implementation-specific.</p>
 </section1>
@@ -152,15 +152,15 @@
     <proxy port='43253'>1.2.3.4</proxy>
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Acknowledgement of expiration'><![CDATA[
 <iq type='result'
     id='pass3'
     from='[email protected]/resource'
     to='pass.jabber.org'>
   <query xmlns='jabber:iq:pass'/>
 </iq>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic='oneshot'>
     <p>This tells the server to listen once, and then close the port.  Even if the &lt;expire/&gt; has not been met, the &lt;oneshot/&gt; overrides that and shuts down the listening port.  When this happens the server notifies the client with the following packet:</p>
@@ -175,15 +175,15 @@
     <proxy port='43253'>1.2.3.4</proxy>
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Client acknowledges closing of oneshot port'><![CDATA[
 <iq type='result'
     id='pass4'
     from='[email protected]/resource'
     to='pass.jabber.org'>
   <query xmlns='jabber:iq:pass'/>
 </iq>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic='close'>
     <p>This tells the server to explicitly shut down a listening port.  Useful for when the client shuts down and can tell the PASS service to recycle the port. The server sends back:</p>
@@ -197,15 +197,15 @@
     <proxy port='43253'>1.2.3.4</proxy>
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server acknowledges port closing request'><![CDATA[
 <iq type='result'
     id='pass5'
     to='[email protected]/resource'
     from='pass.jabber.org'>
   <query xmlns='jabber:iq:pass'/>
 </iq>
-    ]]></example>
+]]></example>
     <table caption='Error Codes'>
       <tr>
         <th>Code</th>
@@ -246,7 +246,7 @@
     from='[email protected]/resource'>
   <query xmlns='jabber:iq:pass'/>
 </iq>
-    ]]></example>
+]]></example>
     <p>The other client SHOULD send back:</p>
     <example><![CDATA[
 <iq type='result'
@@ -257,7 +257,7 @@
     <client>4.3.2.1</client>
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>Obviously the port is not going to be known, but the IP address will let you authenticate the JID via the PASS service since the PASS service tells you the &lt;client/&gt; information upon a connection.</p>
   </section2>
   <section2 topic='Denying a Connection'>
@@ -273,7 +273,7 @@
     <proxy port='43523'>1.2.3.4</proxy>
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>Your client would send back:</p>
     <example><![CDATA[
 <iq type='error'
@@ -288,7 +288,7 @@
     <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-    ]]></example>
+]]></example>
     <table caption='Error Codes'>
       <tr>
         <th>Code</th>
@@ -354,6 +354,6 @@
   </xs:simpleType>
 
 </xs:schema>
-    ]]></code>
+]]></code>
 </section1>
 </xep>

xep-0004.xml

@@ -169,7 +169,7 @@
     <option label='option-label'><value>option-value</value></option>
   </field>
 </x>
-  ]]></code>
+]]></code>
   <p>The &X; element qualified by the 'jabber:x:data' namespace SHOULD be included either directly as a first-level child of a &MESSAGE; stanza or as a second-level child of an &IQ; stanza (where the first-level child is an element qualified by a "wrapper" namespace); see also the restrictions enumerated below.</p>
   <p>The OPTIONAL &lt;title/&gt; and &lt;instructions/&gt; elements enable the form-processing entity to label the form as a whole and specify natural-language instructions to be followed by the form-submitting entity. The XML character data for these elements SHOULD NOT contain newlines (the \n and \r characters), and any handling of newlines (e.g., presentation in a user interface) is unspecified herein; however, multiple instances of the &lt;instructions/&gt; element MAY be included.</p>
   <section2 topic='Form Types' anchor='protocol-formtypes'>
@@ -299,7 +299,7 @@
   .
   .
 </x>
-    ]]></code>
+]]></code>
     <p>Each of these elements MUST contain one or more &lt;field/&gt; children. The &lt;reported/&gt; element defines the data format for the result items by specifying the fields to be expected for each item; for this reason, the &lt;field/&gt; elements SHOULD possess a 'type' attribute and 'label' attribute in addition to the 'var' attribute, and SHOULD NOT contain a &lt;value/&gt; element. Each &lt;item/&gt; element defines one item in the result set, and MUST contain each field specified in the &lt;reported/&gt; element (although the XML character data of the &lt;value/&gt; element MAY be null).</p>
   </section2>
 </section1>
@@ -321,7 +321,7 @@
            node='create'
            action='execute'/>
 </iq>
-    ]]></example>
+]]></example>
     <p>The hosting service then returns a data form to the user:</p>
     <example caption="Service Returns Bot Creation Form"><![CDATA[
 <iq from='[email protected]'
@@ -388,7 +388,7 @@
     </x>
   </command>
 </iq>
-    ]]></example>
+]]></example>
     <p>The user then submits the configuration form:</p>
     <example caption="User Submits Bot Creation Form"><![CDATA[
 <iq from='[email protected]/home'
@@ -432,7 +432,7 @@
     </x>
   </command>
 </iq>
-    ]]></example>
+]]></example>
     <p>The service then returns the results to the user:</p>
     <example caption="Service Returns Bot Creation Result"><![CDATA[
 <iq from='[email protected]'
@@ -471,7 +471,7 @@
     </x>
   </command>
 </iq>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic='Search' anchor='examples-search'>
     <p>Now that the user has created this search bot, let us suppose that one of the friends he has invited decides to try it out by sending a search request:</p>
@@ -485,7 +485,7 @@
            node='search'
            action='execute'/>
 </iq>
-    ]]></example>
+]]></example>
     <example caption="Service Returns Search Form"><![CDATA[
 <iq from='[email protected]'
     to='[email protected]/chamber'
@@ -505,7 +505,7 @@
     </x>
   </command>
 </iq>
-    ]]></example>
+]]></example>
     <example caption="User Submits Search Form"><![CDATA[
 <iq from='[email protected]/chamber'
     to='[email protected]'
@@ -521,7 +521,7 @@
     </x>
   </command>
 </iq>
-    ]]></example>
+]]></example>
     <example caption="Service Returns Search Results"><![CDATA[
 <iq from='[email protected]'
     to='[email protected]/chamber'
@@ -580,7 +580,7 @@
     </x>
   </command>
 </iq>
-    ]]></example>
+]]></example>
   </section2>
 </section1>
 <section1 topic='Service Discovery' anchor='disco'>
@@ -592,7 +592,7 @@
     id='disco1'>
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 </iq>
-  ]]></example>
+]]></example>
   <example caption="Service Discovery information response"><![CDATA[
 <iq type='result'
     from='[email protected]/balcony'
@@ -604,7 +604,7 @@
     ...
   </query>
 </iq>
-  ]]></example>
+]]></example>
   <p>If an entity supports data forms indirectly through inclusion of data forms in a wrapper namespace (rather than directly within a &MESSAGE; stanza), it MUST NOT advertise support for the 'jabber:x:data' namespace, since support is implicit in support for the wrapper protocol.</p>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
@@ -733,7 +733,7 @@
   </xs:simpleType>
 
 </xs:schema>
-  ]]></code>
+]]></code>
 </section1>
 <section1 topic='Changes in Final State' anchor='final-changes'>
   <p>The following substantive protocol changes have been made while this specification has been in the Final state:</p>

xep-0009.xml

@@ -89,7 +89,7 @@
     </methodCall>
   </query>
 </iq>
-  ]]></example>
+]]></example>
   <example caption='A typical response'><![CDATA[
 <iq type='result'
     from='[email protected]/jrpc-server'
@@ -105,7 +105,7 @@
     </methodResponse>
   </query>
 </iq>
-  ]]></example>
+]]></example>
   <p>If the requesting entity does not have sufficient permissions to perform remote procedure calls, the responding entity MUST return a &forbidden; error:</p>
   <example caption='Requesting entity is forbidden to perform remote procedure calls'><![CDATA[
 <iq type='error'
@@ -126,7 +126,7 @@
     <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-  ]]></example>
+]]></example>
 </section1>
 <section1 topic='Service Discovery' anchor='disco'>
   <p>If an entity supports the Jabber-RPC protocol, it SHOULD advertise that fact in response to &xep0030; information ("diso#info") requests by returning an identity of "automation/rpc" and a feature of "jabber:iq:rpc":</p>
@@ -137,7 +137,7 @@
     id='disco1'>
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 </iq>
-  ]]></example>
+]]></example>
   <example caption='A disco#info response'><![CDATA[
 <iq type='result'
     to='[email protected]/jrpc-client'
@@ -148,7 +148,7 @@
     <feature var='jabber:iq:rpc'/>
   </query>
 </iq>
-  ]]></example>
+]]></example>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
   <p>An entity that supports Jabber-RPC SHOULD establish a "whitelist" of entities that are allowed to perform remote procedure calls and MUST return a &forbidden; error if entities with insufficient permissions attempt such calls.</p>
@@ -324,6 +324,6 @@
   </xs:simpleType>
 
 </xs:schema>
-  ]]></code>
+]]></code>
 </section1>
 </xep>

xep-0011.xml

@@ -471,7 +471,7 @@
   <xs:element name='ns' type='xs:string'/>
 
 </xs:schema>
-    ]]></code>
+]]></code>
 </section1>
 <section1 topic='Future Considerations'>
   <p>The 'jabber:iq:browse' namespace has been in use for quite some time. However, live browsing still needs to be better defined by a generic publication/subscription system. It is assumed that when such a system is defined, updates to this document will be made. It is, however, possible that no futher changes to jabber:iq:browse itself may be needed.</p>