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,7 +125,7 @@
     <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'
@@ -133,7 +133,7 @@
     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,7 +152,7 @@
     <proxy port='43253'>1.2.3.4</proxy>
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Acknowledgement of expiration'><![CDATA[
 <iq type='result'
     id='pass3'
@@ -160,7 +160,7 @@
     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,7 +175,7 @@
     <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'
@@ -183,7 +183,7 @@
     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,7 +197,7 @@
     <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'
@@ -205,7 +205,7 @@
     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='you@jabber.org/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='joogle@botster.shakespeare.lit'
@@ -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='romeo@montague.net/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='joogle@botster.shakespeare.lit'
@@ -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='joogle@botster.shakespeare.lit'
     to='juliet@capulet.com/chamber'
@@ -505,7 +505,7 @@
     </x>
   </command>
 </iq>
-    ]]></example>
+]]></example>
     <example caption="User Submits Search Form"><![CDATA[
 <iq from='juliet@capulet.com/chamber'
     to='joogle@botster.shakespeare.lit'
@@ -521,7 +521,7 @@
     </x>
   </command>
 </iq>
-    ]]></example>
+]]></example>
     <example caption="Service Returns Search Results"><![CDATA[
 <iq from='joogle@botster.shakespeare.lit'
     to='juliet@capulet.com/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='juliet@capulet.com/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='responder@company-a.com/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='requester@company-b.com/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>

xep-0012.xml

@@ -87,7 +87,7 @@
     type='get'>
   <query xmlns='jabber:iq:last'/>
 </iq>
-  ]]></example>
+]]></example>
   <p>The target entity MUST return either an IQ-result or an IQ-error. When returning an IQ-result, the target entity sends an &IQ; stanza of type='result' containing a &QUERY; element with a REQUIRED 'seconds' attribute and OPTIONAL XML character data.</p>
   <example caption='Last Activity Response'><![CDATA[
 <iq from='juliet@capulet.com'
@@ -96,7 +96,7 @@
     type='result'>
   <query xmlns='jabber:iq:last' seconds='903'/>
 </iq>
-  ]]></example>
+]]></example>
   <p>The requesting entity interprets the IQ-result based on the responding entity's JID type in order to determine the meaning of the information. Specifically, the information means something different depending on the identity of the responding entity:</p>
   <ol>
     <li>An account registered on an XMPP server, with a JID of the form &LOCALBARE;.</li>
@@ -114,7 +114,7 @@
     type='get'>
   <query xmlns='jabber:iq:last'/>
 </iq>
-  ]]></example>
+]]></example>
   <p>As specified in &xmppcore; and &xmppim;, an IQ stanza of type "get" sent to a bare JID &LOCALBARE; is handled by the user's server on the user's behalf, not delivered to one or more connected or available resources.</p>
   <p>If the requesting entity is not authorized to view the user's presence information (normally via a presence subscription as defined in <cite>XMPP-IM</cite>), the user's server MUST NOT return last activity information but instead MUST return a &forbidden; error in response to the last activity request.</p>
   <example caption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[
@@ -126,7 +126,7 @@
     <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-  ]]></example>
+]]></example>
   <p>If the requesting entity is authorized to view the user's presence information, the server shall return information about the last presence activity recorded by the server for that user.</p>
   <example caption='Last Activity Response by Server'><![CDATA[
 <iq from='juliet@capulet.com'
@@ -135,7 +135,7 @@
     type='result'>
   <query xmlns='jabber:iq:last' seconds='903'>Heading Home</query>
 </iq>
-  ]]></example>
+]]></example>
   <p>In this example, the user logged out fifteen minutes and three seconds ago, and when they logged out they sent a presence stanza of type='unavailable' whose &lt;status/&gt; element contained the text "Heading Home".</p>
   <p>If the user has at least one connected or available resource when the server receives the request, the response MUST (subject to local security policies) contain an empty &lt;query/&gt; element whose 'seconds' attribute is set to a value of '0'.</p>
 </section1>
@@ -148,7 +148,7 @@
     type='get'>
   <query xmlns='jabber:iq:last'/>
 </iq>
-  ]]></example>
+]]></example>
   <p>In this case, the user's server shall either deliver the IQ to an available resource or respond on behalf of the user.</p>
   <p>In particular, as with the offline query use case above, if the requesting entity is not authorized to view the user's presence information (normally via a presence subscription as defined in <cite>XMPP IM</cite>), the user's server MUST NOT deliver the IQ-get to an available resource but instead MUST return a &forbidden; error in response to the last activity request.</p>
   <example caption='Requesting Entity is Not Authorized to Retrieve Last Activity Information'><![CDATA[
@@ -160,7 +160,7 @@
     <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-  ]]></example>
+]]></example>
   <p>If the user's server delivers the IQ-get to one of the user's available resources, the user's client MAY respond with the idle time of the user (i.e., the last time that a human user interacted with the client application).</p>
   <example caption='Last Activity Response by Client'><![CDATA[
 <iq from='juliet@capulet.com/balcony'
@@ -169,7 +169,7 @@
     type='result'>
   <query xmlns='jabber:iq:last' seconds='123'/>
 </iq>
-  ]]></example>
+]]></example>
   <p>In the foregoing example, the user has been idle for about two minutes.</p>
   <p>Support for this functionality is OPTIONAL. A client that does not support the protocol, or that does not wish to divulge this information, MUST return a &unavailable; error.</p>
   <example caption='Service Unavailable Error'><![CDATA[
@@ -181,7 +181,7 @@
     <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-  ]]></example>
+]]></example>
   <p>If there is no available resource matching the &LOCALBARE; in the 'to' attribute of the request, the server MUST follow the rules in <cite>XMPP IM</cite> in order to determine what error stanza to return.</p>
 </section1>
 <section1 topic='Server and Component Query' anchor='server'>
@@ -193,7 +193,7 @@
     type='get'>
   <query xmlns='jabber:iq:last'/>
 </iq>
-  ]]></example>
+]]></example>
   <example caption='Last Activity Response from Server or Service'><![CDATA[
 <iq from='capulet.com'
     id='last3'
@@ -201,7 +201,7 @@
     type='result'>
   <query xmlns='jabber:iq:last' seconds='123456'/>
 </iq>
-  ]]></example>
+]]></example>
   <p>In this example, the server has been running for a little more than 34 hours.</p>
 </section1>
 <section1 topic='Determining Support' anchor='support'>
@@ -213,7 +213,7 @@
     type='get'>
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 </iq>
-  ]]></example>
+]]></example>
   <example caption='Responding entity communicates protocol support'><![CDATA[
 <iq from='jabber.org'
     id='disco1'
@@ -223,7 +223,7 @@
     <feature var='jabber:iq:last'/>
   </query>
 </iq>
-  ]]></example>
+]]></example>
   <p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
 </section1>
 <section1 topic='Implementation Notes' anchor='impl'>
@@ -270,6 +270,6 @@
   </xs:element>
 
 </xs:schema>
-    ]]></code>
+]]></code>
 </section1>
 </xep>

xep-0013.xml

@@ -124,7 +124,7 @@
 <iq type='get' to='montague.net'>
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server Reply to Discovery Request'><![CDATA[
 <iq type='result'
     from='montague.net'
@@ -133,7 +133,7 @@
     <feature var='http://jabber.org/protocol/offline'/>
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the server supports this protocol, it MUST return a &lt;feature/&gt; element in the disco result with the 'var' attribute set to the namespace name for this protocol: 'http://jabber.org/protocol/offline'.</p>
   </section2>
   <section2 topic='Requesting Number of Messages' anchor='request-number'>
@@ -144,7 +144,7 @@
   <query xmlns='http://jabber.org/protocol/disco#info'
          node='http://jabber.org/protocol/offline'/>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the server supports retrieval of the number of messages, it MUST include &xep0128; data specifying the number of messages:</p>
     <example caption='Server Returns Information About Offline Message Node, Including Number of Messages'><![CDATA[
 <iq type='result' to='romeo@montague.net/orchard'>
@@ -164,7 +164,7 @@
     </x>
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>Upon receiving a service discovery request addressed to a node of "http://jabber.org/protocol/offline" (either a disco#info request as in this use case or a disco#items request as in the next use case), the server MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. Thus the user is now free to send initial presence (if desired) and to engage in normal IM activities while continuing to read through offline messages. However, once the user sends presence, the user's server MUST deliver in-session messages as usual; this document applies to offline messages only. In addition, if the user authenticates and provides presence for another resource while the first (non-flood) resource still has an active session, the server MUST NOT flood the second resource with the offline message queue.</p>
   </section2>
   <section2 topic='Requesting Message Headers' anchor='request-headers'>
@@ -174,7 +174,7 @@
   <query xmlns='http://jabber.org/protocol/disco#items'
          node='http://jabber.org/protocol/offline'/>
 </iq>
-    ]]></example>
+]]></example>
     <p>The server now MUST return headers for all of the user's offline messages. So that the user may determine whether to view a full message, the header information provided MUST include the full Jabber ID of the sender (encoded in the 'name' attribute) and a unique identifier for the message within the user's "inbox" (encoded in the 'node' attribute), so that the user may appropriately manage (view or remove) the message.</p>
     <example caption='Server Provides Offline Message Headers'><![CDATA[
 <iq type='result' to='romeo@montague.net/orchard'>
@@ -202,7 +202,7 @@
         name='juliet@capulet.com/balcony'/>
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the requester is a JID other than an authorized resource of the user (i.e., the user@host of the requester does not match the user@host of the user), the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an &notfound; error. If there are no offline messages for this user, the server MUST return an empty query as defined in XEP-0030. (For information about the syntax of error conditions, refer to &xep0086;.)</p>
     <p>The syntax and semantics of the attributes are as follows:</p>
     <ul>
@@ -220,7 +220,7 @@
           node='2003-02-27T22:52:37.225Z'/>
   </offline>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return an &notfound; error. Otherwise, the server MUST send the requested message(s) plus an IQ result:</p>
     <example caption='Server Provides Offline Messages'><![CDATA[
 <message to='romeo@montague.net' from='juliet@capulet.com/balcony'>
@@ -231,7 +231,7 @@
 </message>
 
 <iq type='result' to='user@domain/resource' id='view1'/>
-    ]]></example>
+]]></example>
     <p>In order to distinguish incoming messages, each message MUST contain the node value. It is RECOMMENDED for the server to include &xep0091; information in the message.</p>
   </section2>
   <section2 topic='Removing Specific Messages' anchor='remove-specific'>
@@ -246,11 +246,11 @@
           node='2003-02-27T22:52:37.225Z'/>
   </offline>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a &notfound; error. Otherwise, the server MUST remove the messages and inform the user:</p>
     <example caption='Server Informs User of Removal'><![CDATA[
 <iq type='result' to='romeo@montague.net/orchard' id='remove1'/>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic='Retrieving All Messages' anchor='retrieve-all'>
     <p>The user retrieves all message by sending the "fetch" command:</p>
@@ -260,7 +260,7 @@
     <fetch/>
   </offline>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a &notfound; error. Otherwise, the server MUST retrieve all messages and inform the user:</p>
     <example caption='Server Sends All Messages and Informs User of Successful Fetch'><![CDATA[
 <message to='romeo@montague.net' from='juliet@capulet.com/balcony'>
@@ -271,7 +271,7 @@
 </message>
 
 <iq type='result' to='romeo@montague.net/orchard' id='fetch1'/>
-    ]]></example>
+]]></example>
     <p>A client MAY retrieve all messages without first requesting message headers. In this case, the server MUST return all of the user's offline messages and also MUST NOT send a flood of offline messages if the user subsequently sends initial presence to the server during this session. That is, the semantics here are the same as for requesting message headers.</p>
   </section2>
   <section2 topic='Removing All Messages' anchor='remove-all'>
@@ -282,11 +282,11 @@
     <purge/>
   </offline>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the requester is a JID other than an authorized resource of the user, the server MUST return a &forbidden; error. If the requester is authorized but the node does not exist, the server MUST return a &notfound; error. Otherwise, the server MUST remove all messages and inform the user:</p>
     <example caption='Server Informs User of Successful Purge'><![CDATA[
 <iq type='result' to='romeo@montague.net/orchard' id='purge1'/>
-    ]]></example>
+]]></example>
   </section2>
 </section1>
 <section1 topic='Protocol Flow' anchor='flow'>
@@ -377,7 +377,7 @@ C: request and remove offline messages, send and receive messages, etc.
       <doc>XEP-0013</doc>
     </type>
   </category>
-    ]]></code>
+]]></code>
   </section2>
   <section2 topic='Well-Known Service Discovery Nodes' anchor='registrar-disco-nodes'>
     <p>The XMPP Registrar includes "http://jabber.org/protocol/offline" in its registry of well-known Service Discovery nodes.</p>
@@ -397,7 +397,7 @@ C: request and remove offline messages, send and receive messages, etc.
       type='text-single'
       label='N/A'/>
 </form_type>
-    ]]></code>
+]]></code>
   </section2>
 </section1>
 <section1 topic='XML Schema' anchor='schema'>
@@ -441,6 +441,6 @@ C: request and remove offline messages, send and receive messages, etc.
   </xs:element>
 
 </xs:schema>
-  ]]></code>
+]]></code>
 </section1>
 </xep>

xep-0016.xml

@@ -132,7 +132,7 @@
     </list>
   </query>
 </iq>
-    ]]></code>
+]]></code>
     <p>If the type is "jid", then the 'value' attribute MUST contain a valid Jabber ID.  JIDs SHOULD be matched in the following order:</p>
     <ol>
       <li>&lt;user@domain/resource&gt; (only that resource matches)</li>
@@ -176,7 +176,7 @@
 <iq from='romeo@example.net/orchard' type='get' id='getlist1'>
 <query xmlns='jabber:iq:privacy'/>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server sends names of privacy lists to client, preceded by active list and default list'><![CDATA[
 <iq type='result' id='getlist1' to='romeo@example.net/orchard'>
 <query xmlns='jabber:iq:privacy'>
@@ -187,14 +187,14 @@
   <list name='special'/>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Client requests a privacy list from server'><![CDATA[
 <iq from='romeo@example.net/orchard' type='get' id='getlist2'>
 <query xmlns='jabber:iq:privacy'>
   <list name='public'/>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server sends a privacy list to client'><![CDATA[
 <iq type='result' id='getlist2' to='romeo@example.net/orchard'>
 <query xmlns='jabber:iq:privacy'>
@@ -207,14 +207,14 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Client requests another privacy list from server'><![CDATA[
 <iq from='romeo@example.net/orchard' type='get' id='getlist3'>
 <query xmlns='jabber:iq:privacy'>
   <list name='private'/>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server sends another privacy list to client'><![CDATA[
 <iq type='result' id='getlist3' to='romeo@example.net/orchard'>
 <query xmlns='jabber:iq:privacy'>
@@ -227,14 +227,14 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Client requests yet another privacy list from server'><![CDATA[
 <iq from='romeo@example.net/orchard' type='get' id='getlist4'>
 <query xmlns='jabber:iq:privacy'>
   <list name='special'/>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server sends yet another privacy list to client'><![CDATA[
 <iq type='result' id='getlist4' to='romeo@example.net/orchard'>
 <query xmlns='jabber:iq:privacy'>
@@ -255,7 +255,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>In this example, the user has three lists: (1) 'public', which allows communications from everyone except one specific entity (this is the default list); (2) 'private', which allows communications only with contacts who have a bidirectional subscription with the user (this is the active list); and (3) 'special', which allows communications only with three specific entities.</p>
     <p>If the user attempts to retrieve a list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user:</p>
     <example caption='Client attempts to retrieve non-existent list'><![CDATA[
@@ -268,7 +268,7 @@
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
 </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>The user is allowed to retrieve only one list at a time.  If the user attempts to retrieve more than one list in the same request, the server MUST return a &lt;bad request/&gt; stanza error to the user:</p>
     <example caption='Client attempts to retrieve more than one list'><![CDATA[
 <iq to='romeo@example.net/orchard' type='error' id='getlist6'>
@@ -282,7 +282,7 @@
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
 </error>
 </iq>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic="Managing Active Lists" anchor="protocol-active">
     <p>In order to set or change the active list currently being applied by the server, the user MUST send an IQ stanza of type "set" with a &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains an empty &lt;active/&gt; child element possessing a 'name' attribute whose value is set to the desired list name.</p>
@@ -292,11 +292,11 @@
   <active name='special'/>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>The server MUST activate and apply the requested list before sending the result back to the client.</p>
     <example caption='Server acknowledges success of active list change'><![CDATA[
 <iq type='result' id='active1' to='romeo@example.net/orchard'/>
-    ]]></example>
+]]></example>
     <p>If the user attempts to set an active list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user:</p>
     <example caption='Client attempts to set a non-existent list as active'><![CDATA[
 <iq to='romeo@example.net/orchard' type='error' id='active2'>
@@ -308,7 +308,7 @@
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
 </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>In order to decline the use of any active list, the connected resource MUST send an empty &lt;active/&gt; element with no 'name' attribute.</p>
     <example caption='Client declines the use of active lists'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='active3'>
@@ -316,10 +316,10 @@
   <active/>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server acknowledges success of declining any active list'><![CDATA[
 <iq type='result' id='active3' to='romeo@example.net/orchard'/>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic="Managing the Default List" anchor="protocol-default">
     <p>In order to change its default list (which applies to the user as a whole, not only the sending resource), the user MUST send an IQ stanza of type "set" with a &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains an empty &lt;default/&gt; child element possessing a 'name' attribute whose value is set to the desired list name.</p>
@@ -329,10 +329,10 @@
   <default name='special'/>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server acknowledges success of default list change'><![CDATA[
 <iq type='result' id='default1' to='romeo@example.net/orchard'/>
-    ]]></example>
+]]></example>
     <p>If the user attempts to change which list is the default list but the default list is in use by at least one connected resource other than the sending resource, the server MUST return a &lt;conflict/&gt; stanza error to the sending resource:</p>
     <example caption='Client attempts to change the default list but that list is in use by another resource'><![CDATA[
 <iq to='romeo@example.net/orchard' type='error' id='default1'>
@@ -344,7 +344,7 @@
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
 </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the user attempts to set a default list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user:</p>
     <example caption='Client attempts to set a non-existent list as default'><![CDATA[
 <iq to='romeo@example.net/orchard' type='error' id='default1'>
@@ -356,7 +356,7 @@
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
 </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>In order to decline the use of a default list (i.e., to use the domain's stanza routing rules at all times), the user MUST send an empty &lt;default/&gt; element with no 'name' attribute.</p>
     <example caption='Client declines the use of the default list'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='default2'>
@@ -364,10 +364,10 @@
   <default/>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server acknowledges success of declining any default list'><![CDATA[
 <iq type='result' id='default2' to='romeo@example.net/orchard'/>
-    ]]></example>
+]]></example>
     <p>If one connected resource attempts to decline the use of a default list for the user as a whole but the default list currently applies to at least one other connected resource, the server MUST return a &lt;conflict/&gt; error to the sending resource:</p>
     <example caption='Client attempts to decline a default list but that list is in use by another resource'><![CDATA[
 <iq to='romeo@example.net/orchard' type='error' id='default3'>
@@ -379,7 +379,7 @@
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
 </error>
 </iq>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic="Editing a Privacy List" anchor="protocol-edit">
     <p>In order to edit a privacy list, the user MUST send an IQ stanza of type "set" with a &lt;query/&gt; element qualified by the 'jabber:iq:privacy' namespace that contains one &lt;list/&gt; child element possessing a 'name' attribute whose value is set to the list name the user would like to edit.  The &lt;list/&gt; element MUST contain one or more &lt;item/&gt; elements, which specify the user's desired changes to the list by including all elements in the list (not the "delta").</p>
@@ -399,10 +399,10 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server acknowledges success of list edit'><![CDATA[
 <iq type='result' id='edit1' to='romeo@example.net/orchard'/>
-    ]]></example>
+]]></example>
     <p>Note: The value of the 'order' attribute for any given item is not fixed.  Thus in the foregoing example if the user would like to add 4 items between the "tybalt@example.com" item and the "paris@example.org" item, the user's client MUST renumber the relevant items before submitting the list to the server.</p>
     <p>The server MUST now send a "privacy list push" to all connected resources:</p>
     <example caption='Privacy list push on list edit'><![CDATA[
@@ -417,7 +417,7 @@
   <list name='public'/>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>In accordance with the semantics of IQ stanzas defined in &xmppcore;, each connected resource MUST return an IQ result to the server as well:</p>
     <example caption='Acknowledging receipt of privacy list pushes'><![CDATA[
 <iq from='romeo@example.net/orchard'
@@ -427,7 +427,7 @@
 <iq from='romeo@example.net/home'
   type='result'
   id='push2'/>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic="Adding a New Privacy List" anchor="protocol-add">
     <p>The same protocol used to edit an existing list is used to create a new list.  If the list name matches that of an existing list, the request to add a new list will overwrite the old one.  As with list edits, the server MUST also send a "privacy list push" to all connected resources.</p>
@@ -440,10 +440,10 @@
   <list name='private'/>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server acknowledges success of list removal'><![CDATA[
 <iq type='result' id='remove1' to='romeo@example.net/orchard'/>
-    ]]></example>
+]]></example>
     <p>If a user attempts to remove a list that is currently being applied to at least one resource other than the sending resource, the server MUST return a &lt;conflict/&gt; stanza error to the user; i.e., the user MUST first set another list to active or default before attempting to remove it.  If the user attempts to remove a list but a list by that name does not exist, the server MUST return an &lt;item-not-found/&gt; stanza error to the user.  If the user attempts to remove more than one list in the same request, the server MUST return a &lt;bad request/&gt; stanza error to the user.</p>
   </section2>
   <section2 topic="Blocking Messages" anchor="protocol-message">
@@ -461,7 +461,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive messages from the entity with the specified JID.</p>
     <example caption='User blocks based on roster group'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='msg2'>
@@ -476,7 +476,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive messages from any entities in the specified roster group.</p>
     <example caption='User blocks based on subscription type'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='msg3'>
@@ -491,7 +491,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive messages from any entities with the specified subscription type.</p>
     <example caption='User blocks globally'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='msg4'>
@@ -503,7 +503,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive messages from any other users.</p>
   </section2>
   <section2 topic="Blocking Inbound Presence Notifications" anchor="protocol-presencein">
@@ -522,7 +522,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from the entity with the specified JID.</p>
     <example caption='User blocks based on roster group'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='presin2'>
@@ -537,7 +537,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities in the specified roster group.</p>
     <example caption='User blocks based on subscription type'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='presin3'>
@@ -552,7 +552,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities with the specified subscription type.</p>
     <example caption='User blocks globally'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='presin4'>
@@ -564,7 +564,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive presence notifications from any other users.</p>
     <p>Note: If a client blocks incoming presence notifications from an entity that has been available before, the user's server SHOULD send unavailable presence to the user on behalf of that contact.</p>
   </section2>
@@ -584,7 +584,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not send presence notifications to the entity with the specified JID.</p>
     <example caption='User blocks based on roster group'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='presout2'>
@@ -599,7 +599,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities in the specified roster group.</p>
     <example caption='User blocks based on subscription type'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='presout3'>
@@ -614,7 +614,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities with the specified subscription type.</p>
     <example caption='User blocks globally'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='presout4'>
@@ -626,7 +626,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.</p>
     <p>Note: When a user blocks outbound presence to a contact, the user's server MUST send unavailable presence information to the contact (but only if the contact is allowed to receive presence notifications from the user in accordance with the rules defined in <cite>RFC 6121</cite>).</p>
   </section2>
@@ -645,7 +645,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from the entity with the specified JID.</p>
     <example caption='User blocks based on roster group'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='iq2'>
@@ -660,7 +660,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities in the specified roster group.</p>
     <example caption='User blocks based on subscription type'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='iq3'>
@@ -675,7 +675,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities with the specified subscription type.</p>
     <example caption='User blocks globally'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='iq4'>
@@ -687,7 +687,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any other users.</p>
   </section2>
   <section2 topic="Blocking All Communication" anchor="protocol-all">
@@ -703,7 +703,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, the entity with the specified JID.</p>
     <example caption='User blocks based on roster group'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='all2'>
@@ -716,7 +716,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities in the specified roster group.</p>
     <example caption='User blocks based on subscription type'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='all3'>
@@ -729,7 +729,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities with the specified subscription type.</p>
     <example caption='User blocks globally'><![CDATA[
 <iq from='romeo@example.net/orchard' type='set' id='all4'>
@@ -739,7 +739,7 @@
   </list>
 </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any other users.</p>
   </section2>
   <section2 topic="Blocked Entity Attempts to Communicate with User" anchor="protocol-error">
@@ -757,7 +757,7 @@
   id='probing1'>
 <query xmlns='jabber:iq:version'/>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server returns error to blocked entity'><![CDATA[
 <iq type='error'
   from='romeo@example.net'
@@ -769,7 +769,7 @@
       xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
 </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the user attempts to send an outbound stanza to a contact and that stanza type is blocked, the user's server MUST NOT route the stanza to the contact but instead MUST return a &notacceptable; error:</p>
     <example caption='Error: contact is blocked'><![CDATA[
 <message type='error' from='romeo@montague.net' to='juliet@capulet.com'>
@@ -778,7 +778,7 @@
     <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </message>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic="Higher-Level Heuristics" anchor="protocol-heuristics">
     <p>When building a representation of a higher-level privacy heuristic, a client SHOULD use the simplest possible representation.</p>
@@ -801,7 +801,7 @@
   </list>
 </query>
 </iq>
-    ]]></code>
+]]></code>
   </section2>
 </section1>
 
@@ -814,7 +814,7 @@
     type='get'>
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 </iq>
-  ]]></example>
+]]></example>
   <example caption="Service Discovery information response"><![CDATA[
 <iq from='example.com'
     id='disco1'
@@ -826,7 +826,7 @@
     ...
   </query>
 </iq>
-  ]]></example>
+]]></example>
 </section1>
 
 <section1 topic='Implementation Notes' anchor='impl'>
@@ -962,7 +962,7 @@
 </xs:simpleType>
 
 </xs:schema>
-  ]]></code>
+]]></code>
 </section1>
 
 <section1 topic='Author Note' anchor='authornote'>

xep-0020.xml

@@ -120,7 +120,7 @@
     </x>
   </feature>
 </iq>
-    ]]></example>
+]]></example>
     <example caption="Responding entity sends preferred option values"><![CDATA[
 <iq type='result'
     id='neg1'
@@ -140,7 +140,7 @@
     </x>
   </feature>
 </iq>
-    ]]></example>
+]]></example>
     <p>Note: If the responding entity does not want to reveal presence to the initiating entity for whatever reason then the responding entity's client SHOULD return a &unavailable; error (or return no response or error whatsoever if the offer was wrapped in a &MESSAGE; stanza) - see <link url='#security'>Security Considerations</link>.</p>
     <p>If the responding entity does not support <strong>Feature Negotiation</strong> or does not support the specified FORM_TYPE, it SHOULD also return a &unavailable; error:</p>
     <example caption="Responding entity does not support feature negotiation"><![CDATA[
@@ -160,7 +160,7 @@
     <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the responding entity does not support one or more of the features, it SHOULD return a &feature; error, and SHOULD specify the feature(s) not implemented in the XMPP &lt;text/&gt; element.</p>
     <example caption="Responding entity does not support a feature"><![CDATA[
 <iq type='error'
@@ -180,7 +180,7 @@
     <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>times-to-meet</text>
   </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the responding entity supports none of the options offered for one or more of the features, it SHOULD return a &notacceptable; error, and SHOULD specify the relevant feature(s) in the XMPP &lt;text/&gt; element.</p>
     <example caption="Responding entity supports no options"><![CDATA[
 <iq type='error'
@@ -200,7 +200,7 @@
     <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>places-to-meet</text>
   </error>
 </iq>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic="Querying for Negotiable Features" anchor='protocol-query'>
     <p>If at least one feature offered by an entity is subject to <strong>Feature Negotiation</strong>, the entity's response to a service discovery information request MUST include &lt;feature var='http://jabber.org/protocol/feature-neg'/&gt; as one of the features.</p>
@@ -314,7 +314,7 @@
   </xs:element>
 
 </xs:schema>
-  ]]></code>
+]]></code>
 </section1>
 <section1 topic='Author Note' anchor='authornote'>
   <p>Peter Millard, the primary author of this specification from version 0.1 through version 1.4, died on April 26, 2006. The remaining authors are thankful for Peter's work on this specification.</p>

xep-0022.xml

@@ -121,7 +121,7 @@
     <composing/>
   </x>
 </message>
-  ]]></example>
+]]></example>
   <p>Here we see the sender wants to be notified if the message is stored offline (by the server), notified when the message is delivered (to the client), and notified if the recipient begins replying to the message. In this case, the sender will potentially receive three events based on this request.  The first if the recipient is offline and the message is stored on the server, the second when the recipient becomes available and the message is delivered, and the third if the recipient begins composing a reply to the message.</p>
   <p>Note that the &MESSAGE; element requesting event notification contains an 'id' attribute. While these attributes are optional in the Jabber protocol, messages that contain event notification requests MUST contain an 'id' attribute so that raised events may be matched up with their original requests.</p>
   </section2>
@@ -137,7 +137,7 @@
     <id>message22</id>
   </x>
 </message>
-  ]]></example>
+]]></example>
   <p>When raising an event, the raiser must send a &MESSAGE; element constructed according to the following rules:</p>
     <ul>
       <li>The element must contain only a jabber:x:event extension. Standard message elements such as &lt;subject/&gt;, &lt;body/&gt;, MUST NOT be included.</li>
@@ -160,7 +160,7 @@
     <id>message22</id>
   </x>
 </message>
-  ]]></example>
+]]></example>
   <example caption='Romeo pauses to reflect before answering, thus cancelling the composing event'><![CDATA[
 <message
     from='romeo@montague.net'
@@ -169,7 +169,7 @@
     <id>message22</id>
   </x>
 </message>
-  ]]></example>
+]]></example>
   <p>The lack of an &lt;composing/&gt; tag (and any other event tag) signifies that the composing event, indicated previously by the id value, has been cancelled. In this example, the composing event being cancelled is that event that was previously raised with the id of message22.  After cancelling a composing event, a new one may be raised, following the same rules as before, when the typing of the reply is resumed.</p>
   </section2>
 </section1>
@@ -186,7 +186,7 @@ SEND: <message to='romeo@montague.net' id='message22'>
         <composing/>
       </x>
     </message>
-  ]]></example>
+]]></example>
   <p>Romeo temporarily loses his wireless connection in the Capulet's orchard and therefore his message is stored offline by the montague.net server, which generates the offline event and sends that notification to Juliet.</p>
   <example caption='Receiving the offline event'><![CDATA[
 RECV: <message
@@ -197,7 +197,7 @@ RECV: <message
         <id>message22</id>
       </x>
     </message>
-  ]]></example>
+]]></example>
   <p>Romeo reconnects and the message is delivered to his Jabber client, which generates a delivered event and sends it to Juliet's client.</p>
   <example caption='Juliet receives notification of message delivery'><![CDATA[
 RECV: <message
@@ -208,7 +208,7 @@ RECV: <message
         <id>message22</id>
       </x>
     </message>
-  ]]></example>
+]]></example>
   <p>Romeo's Jabber client displays the message and sends a displayed event to Juliet's client.</p>
   <example caption='Juliet receives notification of message display'><![CDATA[
 RECV: <message
@@ -219,7 +219,7 @@ RECV: <message
         <id>message22</id>
       </x>
     </message>
-  ]]></example>
+]]></example>
   <p>Romeo begins composing a reply to Juliet's heartfelt question, and his Jabber client notifies Juliet that he is composing a reply.</p>
   <example caption='Juliet receives notification of message composing'><![CDATA[
 RECV: <message
@@ -230,7 +230,7 @@ RECV: <message
         <id>message22</id>
       </x>
     </message>
-  ]]></example>
+]]></example>
   <p>Romeo realizes his reply is too rash and pauses to choose the right words; his Jabber client senses the delay and cancels the previous composing event.</p>
   <example caption='Juliet receives cancellation of message composing'><![CDATA[
 RECV: <message
@@ -240,7 +240,7 @@ RECV: <message
         <id>message22</id>
       </x>
     </message>
-  ]]></example>
+]]></example>
   <p>Romeo starts composing again, and his Jabber client sends a notification to Juliet's client.</p>
   <example caption='Juliet receives a second notification of message composing'><![CDATA[
 RECV: <message
@@ -251,7 +251,7 @@ RECV: <message
         <id>message22</id>
       </x>
     </message>
-  ]]></example>
+]]></example>
   <p>Romeo finally sends his reply, and requests composing events related to it.</p>
   <example caption='Romeo replies'><![CDATA[
 SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
@@ -260,7 +260,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
         <composing/>
       </x>
     </message>
-  ]]></example>
+]]></example>
 </section1>
 
 <section1 topic='Implementation Notes'>
@@ -319,7 +319,7 @@ SEND: <message to='juliet@capulet.com' id='GabberMessage43'>
   </xs:simpleType>
 
 </xs:schema>
-    ]]></code>
+]]></code>
 </section1>
 
 <section1 topic='Open Issues'>

xep-0023.xml

@@ -168,7 +168,7 @@ SEND: <message to='sabine@gnu.mine.nu' id='msg811'>
   </xs:simpleType>
 
 </xs:schema>
-    ]]></code>
+]]></code>
 </section1>
 
 <section1 topic='Open Issues'>

xep-0027.xml

@@ -163,7 +163,7 @@
   <xs:element name='x' type='xs:string'/>
 
 </xs:schema>
-    ]]></code>
+]]></code>
   </section2>
   <section2 topic='jabber:x:signed' anchor='schemas-signed'>
     <code><![CDATA[
@@ -185,7 +185,7 @@
   <xs:element name='x' type='xs:string'/>
 
 </xs:schema>
-    ]]></code>
+]]></code>
   </section2>
 </section1>
 </xep>

xep-0030.xml

@@ -276,7 +276,7 @@
     id='info1'>
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 </iq>
-      ]]></example>
+]]></example>
       <p>The target entity then MUST either return an IQ result, or return an error (see the <link url="#errors">Error Conditions</link> section of this document). The result MUST contain a &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/disco#info' namespace, which in turn contains one or more &lt;identity/&gt; elements and one or more &lt;feature/&gt; elements. (Note: Every entity MUST have at least one identity, and every entity MUST support at least the 'http://jabber.org/protocol/disco#info' feature; however, an entity is not required to return a result and MAY return an error, most likely &feature; or &unavailable;, although other error conditions may be appropriate.)</p>
       <p>Each &lt;identity/&gt; element MUST possess the 'category' and 'type' attributes specifying the category and type for the entity, and MAY possess a 'name' attribute specifying a natural-language name for the entity; the &lt;identity/&gt; element MAY also possess a standard 'xml:lang' attribute, which enables the entity to return localized results if desired (i.e., the &lt;query/&gt; element MAY include multiple &lt;identity/&gt; elements with the same category+type but with different 'xml:lang' values, however the &lt;query/&gt; element MUST NOT include multiple &lt;identity/&gt; elements with the same category+type+xml:lang but with different 'name' values).</p>
       <p>Each &lt;feature/&gt; element MUST possess a 'var' attribute whose value is a protocol namespace or other feature offered by the entity, and MUST NOT have any children.</p>
@@ -304,7 +304,7 @@
     <feature var='jabber:iq:version'/>
   </query>
 </iq>
-    ]]></example>
+]]></example>
       <p>If the JID of the specified target entity does not exist, the server or other authoritative entity SHOULD return an &notfound; error, unless doing so would violate the privacy and security considerations specified in <cite>XMPP Core</cite> and &xmppim; or local privacy and security policies (see also the <link url='#security'>Security Considerations</link> of this document):</p>
       <example caption='Target entity does not exist'><![CDATA[
 <iq type='error'
@@ -316,7 +316,7 @@
     <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-      ]]></example>
+]]></example>
       <p>If privacy and security considerations or policies prevent the server or other authoritative entity from returning an &notfound; error, it SHOULD return a &unavailable; error instead:</p>
       <example caption='Service unavailable'><![CDATA[
 <iq type='error'
@@ -328,7 +328,7 @@
     <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-      ]]></example>
+]]></example>
       <p>When an entity sends a disco#info request to a bare JID (&lt;account@domain.tld&gt;) hosted by a server, the server itself MUST reply on behalf of the hosted account, either with an IQ-error or an IQ-result. For important rules regarding access to this functionality, see the <link url='#security'>Security Considerations</link> section of this document. In particular, in response to a disco#info request sent to a bare JID with no node, if access is not denied the server SHOULD return an IQ-result for the bare JID, in which the primary identity SHOULD have a category of "account" with an appropriate type as specified in the Service Discovery Identities registry (most likely, a type of "registered"). Note: This enables authorized or trusted entities to discover whether the account exists and its account type (e.g., in IM systems to determine the existence of an account before adding it to a contact's roster).</p>
       <example caption='Requesting info from a bare JID'><![CDATA[
 <iq type='get'
@@ -337,7 +337,7 @@
     id='info2'>
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 </iq>
-      ]]></example>
+]]></example>
       <p>Here we assume that shakespeare.lit is trusted by capulet.com and that the account &lt;juliet@capulet.com&gt; is a registered account:</p>
       <example caption='Server replies on behalf of bare JID'><![CDATA[
 <iq type='result'
@@ -349,7 +349,7 @@
     <feature var='http://jabber.org/protocol/disco#info'/>
   </query>
 </iq>
-      ]]></example>
+]]></example>
       <p>A query sent to an associated entity may result in different or more detailed information. One example is sending a query to a particular conference room rather than the parent conference service:</p>
       <example caption='Querying a specific conference room'><![CDATA[
 <iq type='get'
@@ -401,7 +401,7 @@
     <feature var='jabber:iq:version'/>
   </query>
 </iq>
-      ]]></example>
+]]></example>
     </section2>
     <section2 topic='Info Nodes' anchor='info-nodes'>
       <p>A disco#info query MAY also be directed to a specific node identifier associated with a JID, although the primary use of nodes is as <link url='#items-nodes'>Items Nodes</link> rather than as info nodes:</p>
@@ -413,7 +413,7 @@
   <query xmlns='http://jabber.org/protocol/disco#info'
          node='http://jabber.org/protocol/commands'/>
 </iq>
-      ]]></example>
+]]></example>
       <p>If the request included a 'node' attribute, the response MUST mirror the specified 'node' attribute to ensure coherence between the request and the response.</p>
       <example caption='JID+node result'><![CDATA[
 <iq type='result'
@@ -428,7 +428,7 @@
     <feature var='http://jabber.org/protocol/disco#info'/>
   </query>
 </iq>
-      ]]></example>
+]]></example>
     </section2>
   </section1>
 
@@ -442,7 +442,7 @@
     id='items1'>
   <query xmlns='http://jabber.org/protocol/disco#items'/>
 </iq>
-      ]]></example>
+]]></example>
       <p>The target entity then MUST either return its list of publicly-available items, or return an error. The list of items MUST be provided in an IQ stanza of type "result", with each item specified by means of an &lt;item/&gt; child of a &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/disco#items' namespace (the &lt;item/&gt; child MUST possess a 'jid' attribute specifying the JID of the item and MAY possess a 'name' attribute specifying a natural-language name for the item):</p>
       <example caption='Result-set for all items'><![CDATA[
 <iq type='result'
@@ -468,7 +468,7 @@
           name='French Translation Service'/>
   </query>
 </iq>
-      ]]></example>
+]]></example>
       <p>The &lt;item/&gt; element MUST NOT contain XML character data and SHOULD be empty; while it MAY contain XML data in another namespace, such data MUST be ignored if an implementation does not understand it.</p>
       <p>If there are no items associated with an entity (or if those items are not publicly available), the target entity MUST return an empty query element to the requesting entity:</p>
       <example caption='Empty result set'><![CDATA[
@@ -478,7 +478,7 @@
     id='items1'>
   <query xmlns='http://jabber.org/protocol/disco#items'/>
 </iq>
-      ]]></example>
+]]></example>
       <p>As with disco#info requests, when an entity sends a disco#items request to a bare JID (&lt;account@domain.tld&gt;) hosted by a server, the server itself MUST reply on behalf of the hosted account. For important rules regarding access to this functionality, see the <link url='#security'>Security Considerations</link> section of this document. In particular, in response to a disco#items request sent to a bare JID with no node, if access is not denied the server SHOULD return the associated items including connected or available resources as appropriate:</p>
       <example caption='Requesting items from a bare JID'><![CDATA[
 <iq type='get'
@@ -487,7 +487,7 @@
     id='items2'>
   <query xmlns='http://jabber.org/protocol/disco#items'/>
 </iq>
-      ]]></example>
+]]></example>
       <p>Here we assume that shakespeare.lit is trusted by capulet.com and that the account &lt;juliet@capulet.com&gt; has two available resources:</p>
       <example caption='Server replies on behalf of bare JID'><![CDATA[
 <iq type='result'
@@ -499,7 +499,7 @@
     <item jid='juliet@capulet.com/chamber'/>
   </query>
 </iq>
-      ]]></example>
+]]></example>
     </section2>
     <section2 topic='Items Nodes' anchor='items-nodes'>
       <p>It is possible that an item associated with an entity will not be addressable as a JID; examples might include offline messages stored in an inbox (see &xep0013;), entries in a Jabber-enabled weblog, XML-RPC services associated with a client or component, items available in an online trading system (e.g., a catalog or auction), news postings located at an NNTP gateway, and topics hosted by a &xep0060; component. In order to handle such items, the &lt;item/&gt; element MAY possess an OPTIONAL 'node' attribute that supplements the REQUIRED 'jid' attribute.</p>
@@ -512,7 +512,7 @@
     id='items2'>
   <query xmlns='http://jabber.org/protocol/disco#items'/>
 </iq>
-        ]]></example>
+]]></example>
         <p>If there are items associated with the target entity but they are not addressable as JIDs, the service SHOULD then return a list of nodes (where each &lt;item/&gt; element MUST possess a 'jid' attribute, SHOULD possess a 'node' attribute, and MAY possess a 'name' attribute):</p>
         <example caption='Service returns nodes'><![CDATA[
 <iq type='result'
@@ -531,7 +531,7 @@
           name='Music from the time of Shakespeare'/>
   </query>
 </iq>
-      ]]></example>
+]]></example>
       <p>There may be futher nodes associated with the "first-level" nodes returned in the above query (e.g., the nodes may be categories that have associated items). The requesting entity can query a node further by sending a request to the JID and specifying the node of interest in the query.</p>
       <example caption='Requesting further nodes'><![CDATA[
 <iq type='get'
@@ -541,7 +541,7 @@
   <query xmlns='http://jabber.org/protocol/disco#items'
          node='music'/>
 </iq>
-      ]]></example>
+]]></example>
       <p>The service then returns the further nodes associated with the "parent" node. In the following example, the service itself enforces an alphabetically-ordered hierarchical structure on the nodes that are returned, but such a structure is a matter of implementation rather than protocol.</p>
       <example caption='Service returns further nodes'><![CDATA[
 <iq type='result'
@@ -563,7 +563,7 @@
     .
   </query>
 </iq>
-      ]]></example>
+]]></example>
       <p>The requesting entity can then query further if desired:</p>
       <example caption='Requesting even more nodes'><![CDATA[
 <iq type='get'
@@ -573,7 +573,7 @@
   <query xmlns='http://jabber.org/protocol/disco#items'
          node='music/D'/>
 </iq>
-      ]]></example>
+]]></example>
       <example caption='Service returns even more nodes'><![CDATA[
 <iq type='result'
     from='catalog.shakespeare.lit'
@@ -589,7 +589,7 @@
           name='John Dowland - A Pilgrimes Solace'/>
   </query>
 </iq>
-      ]]></example>
+]]></example>
     </section2>
     <section2 topic='Node Hierarchies' anchor='items-hierarchy'>
       <p>The foregoing examples show a hierarchy of nodes, in which some nodes are branches (i.e., contain further nodes) and some nodes are leaves (i.e., do not contain further nodes). The "hierarchy" category SHOULD be used to identify such nodes, where the "branch" and "leaf" types are exhaustive of the types within this category.</p>
@@ -616,7 +616,7 @@
   <query xmlns='http://jabber.org/protocol/disco#items'
          node='http://jabber.org/protocol/tune'/>
 </iq>
-      ]]></example>
+]]></example>
       <p>The queried entity now returns a list of publish-subscribe nodes over which it has control, each of which is hosted on a different pubsub service:</p>
       <example caption='Entity returns multiple items'><![CDATA[
 <iq from='romeo@montague.net'
@@ -634,7 +634,7 @@
           node='g8k4kds9sd89djf3'/>
   </query>
 </iq>
-      ]]></example>
+]]></example>
     </section2>
   </section1>
 
@@ -667,7 +667,7 @@
     <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>Other error conditions may be appropriate depending on the application.</p>
     <p>The following table summarizes the common error conditions that can have special meaning in the context of Service Discovery (for information regarding error condition syntax and semantics, see &xep0086;).</p>
     <table caption='Error Conditions'>
@@ -731,7 +731,7 @@
     <doc>the document (e.g., XEP) in which this type is specified</doc>
   </type>
 </category>
-          ]]></code>
+]]></code>
           <p>The registrant may register more than one category at a time, each contained in a separate &lt;category/&gt; element. The registrant may also register more than one type at a time, each contained in a separate &lt;type/&gt; child element. Registrations of new types within an existing category must include the full XML snippet but should not include the category description (only the name).</p>
         </section4>
         <section4 topic='Initial Submission' anchor='registrar-reg-identity-init'>
@@ -760,7 +760,7 @@
     <doc>XEP-0030</doc>
   </type>
 </category>
-          ]]></code>
+]]></code>
         </section4>
       </section3>
       <section3 topic='Features Registry' anchor='registrar-reg-features'>
@@ -773,7 +773,7 @@
   <desc>a natural-language description of the feature</desc>
   <doc>the document (e.g., XEP) in which this feature is specified</doc>
 </var>
-          ]]></code>
+]]></code>
           <p>The registrant may register more than one feature at a time, each contained in a separate &lt;feature/&gt; element.</p>
         </section4>
       </section3>
@@ -787,7 +787,7 @@
   <desc>a natural-language description of the node</desc>
   <doc>the document (e.g., XEP) in which this node is specified</doc>
 </node>
-          ]]></code>
+]]></code>
           <p>The registrant may register more than one node at a time, each contained in a separate &lt;node/&gt; element.</p>
         </section4>
       </section3>
@@ -797,20 +797,20 @@
       <p>The "disco" querytype is defined herein for service discovery interactions, with three keys: (1) "node" (the optional node to query), (2) "request" (with values of "info" to retrieve service discovery information and "items" to retrieve service discovery items), and (3) "type" (with values of "get" for IQ-gets and "set" for IQ-sets).</p>
       <example caption='Service Discovery Information Request: IRI/URI'><![CDATA[
 xmpp:romeo@montague.net?disco;type=get;request=info
-      ]]></example>
+]]></example>
       <example caption='Service Discovery Information Request: Resulting Stanza'><![CDATA[
 <iq to='romeo@montague.net' type='get'>
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 </iq>
-      ]]></example>
+]]></example>
       <example caption='Service Discovery Items Request: IRI/URI'><![CDATA[
 xmpp:romeo@montague.net?disco;type=get;request=items
-      ]]></example>
+]]></example>
       <example caption='Service Discovery Items Request: Resulting Stanza'><![CDATA[
 <iq to='romeo@montague.net' type='get'>
   <query xmlns='http://jabber.org/protocol/disco#items'/>
 </iq>
-      ]]></example>
+]]></example>
       <p>The following submission registers the "disco" querytype.</p>
       <code><![CDATA[
 <querytype>
@@ -850,7 +850,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
   </keys>
 </querytype>
 
-      ]]></code>
+]]></code>
     </section2>
   </section1>
   <section1 topic='XML Schemas' anchor='schemas'>
@@ -916,7 +916,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
   </xs:simpleType>
 
 </xs:schema>
-      ]]></code>
+]]></code>
     </section2>
     <section2 topic='disco#items' anchor='schemas-items'>
       <code><![CDATA[
@@ -970,7 +970,7 @@ xmpp:romeo@montague.net?disco;type=get;request=items
   </xs:simpleType>
 
 </xs:schema>
-      ]]></code>
+]]></code>
     </section2>
   </section1>
 <section1 topic='Author Note' anchor='authornote'>

xep-0033.xml

@@ -703,7 +703,7 @@
   </xs:simpleType>
 
 </xs:schema>
-        ]]></code>
+]]></code>
     </section1>
 
     <section1 topic='Acknowledgements' anchor='ack'>

xep-0038.xml

@@ -288,7 +288,7 @@
     </xs:complexType>
   </xs:element>
 </xs:schema>
-    ]]></code>
+]]></code>
   </section2>
 
   <section2 topic="icondef.xml file example">
@@ -342,7 +342,7 @@
     <object mime="audio/x-wav">alert.wav</object>
   </icon>
 </icondef>
-    ]]></code>
+]]></code>
   </section2>
 </section1>
 

xep-0041.xml

@@ -264,7 +264,7 @@
    </xs:element>
 
 </xs:schema>
-  ]]></code>
+]]></code>
 </section1>
 
 </xep>

xep-0042.xml

@@ -118,7 +118,7 @@
 <iq type='get' to='domain'>
   <query xmlns='jabber:iq:browse'/>
 </iq>
-      ]]></example>
+]]></example>
       <example caption='Browse result'><![CDATA[
 <iq type='get' to='sender@domain/res' from='domain'>
   ...
@@ -131,7 +131,7 @@
   </item>
   ...
 </iq>
-      ]]></example>
+]]></example>
     </section3>
   </section2>
   <section2 topic='Creating a Session'>
@@ -147,7 +147,7 @@
   <session xmlns='http://jabber.org/protocol/jobs'
       action='create'/>
 </iq>
-      ]]></example>
+]]></example>
       <example caption='Creation result'><![CDATA[
 <iq
     type='result' to='sender@domain/res' from='jobs.domain'>
@@ -161,7 +161,7 @@
       expires='30'
       receivers='1'/>
 </iq>
-      ]]></example>
+]]></example>
 
       <p>This creates a session between sender@domain/resource and any one receiver. At this point, the JOBS service is ready to accept connections for this session. The &lt;session/&gt; element describes the details for the session. The value returned in the "id" attribute is the JOBS session ID <note>The exact value of the ID is left to JOBS implementations.</note>.</p>
     </section3>
@@ -174,7 +174,7 @@
 <iq id='JOBS0' type='get' to='jobs.domain'>
   <session xmlns='http://jabber.org/protocol/jobs' action='create'/>
 </iq>
-      ]]></example>
+]]></example>
       <example caption='Parameter statistics result'><![CDATA[
 <iq id='JOBS0' type='result' to='sender@domain/res' from='jobs.domain'>
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -199,7 +199,7 @@
         min='1'/>
   </session>
 </iq>
-      ]]></example>
+]]></example>
 
       <p>The returned &lt;session/&gt; is also prefilled with default values for all known parameters.</p>
 
@@ -209,7 +209,7 @@
   <session xmlns='http://jabber.org/protocol/jobs' action='create'
       expires='-1'/>
 </iq>
-      ]]></example>
+]]></example>
       <example caption='Creation result, with parameters'><![CDATA[
 <iq type='result' to='sender@domain/res' from='jobs.domain'>
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -222,7 +222,7 @@
       expires='-1'
       receivers='1'/>
 </iq>
-      ]]></example>
+]]></example>
 
       <p>The above example creates a session that does not timeout. A JOBS service uses values from the default information set for any parameters that are missing.</p>
 
@@ -239,7 +239,7 @@
     <x xmlns='jabber:x:data'/>
   </session>
 </iq>
-      ]]></example>
+]]></example>
       <example caption='Creation form result'><![CDATA[
 <iq type='result' from='jobs.domain' to='sender@domain/res'>
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -259,7 +259,7 @@
     </x>
   </session>
 </iq>
-      ]]></example>
+]]></example>
 
       <p>The exact fields present in the form are dependent upon the JOBS implementation. The form SHOULD allow a user to at least specify the &lt;session/&gt; attributes.</p>
       <p>Using the form-based approach, the session is then created by sending a &lt;session action='create'/&gt; with a form submission (as defined for "jabber:x:data"):</p>
@@ -275,7 +275,7 @@
     </x>
   </session>
 </iq>
-      ]]></example>
+]]></example>
       <example caption='Creation result (form-based)'><![CDATA[
 <iq type='result' from='jobs.domain' to='sender@domain/res'>
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -288,7 +288,7 @@
       expires='300'
       receivers='1'/>
 </iq>
-      ]]></example>
+]]></example>
     </section3>
   </section2>
   <section2 topic='Inviting Receivers'>
@@ -308,7 +308,7 @@
       expires='30'
       receivers='1'/>
 </message>
-      ]]></example>
+]]></example>
 
       <p>When inviting directly, the &lt;session/&gt; MUST contain enough information for a receiver to connect OOB. The required information is:</p>
       <ul>
@@ -327,7 +327,7 @@
       id='01234567'>
     <item type='connection' action='invite'>receiver@domain</item>
 </message>
-      ]]></example>
+]]></example>
       <p>This results in the JOBS service sending the &lt;message/&gt; to each &lt;item/&gt;. Any additional elements (such as a &lt;body/&gt;) are passed onto those invited:</p>
       <example caption='Invitation message (from JOBS service)'><![CDATA[
 <message from='jobs.domain' to='receiver@domain'>
@@ -344,7 +344,7 @@
       receivers='1'>
     <item type='connection' action='invite'/>
 </message>
-      ]]></example>
+]]></example>
     </section3>
   </section2>
   <section2 topic='Retrieving Session Information'>
@@ -357,7 +357,7 @@
   <session xmlns='http://jabber.org/protocol/jobs'
       action='info'/>
 </iq>
-      ]]></example>
+]]></example>
       <p>The JOBS service responds with all the sessions within the "iq-result". This is the only case where a result can have more than one &lt;session/&gt;.</p>
       <example caption='Information result (all sessions)'><![CDATA[
 <iq type='result' from='jobs.domain' to='sender@domain/res'>
@@ -382,7 +382,7 @@
       expires='30'
       receivers='1'/>
 </iq>
-      ]]></example>
+]]></example>
     </section3>
     <section3 topic='Session-specific'>
       <p>Alternatively, a client can request the information for a specific session by sending an "iq-get" containing a &lt;session action="info"/&gt; with the ID:</p>
@@ -392,7 +392,7 @@
       action='info'
       id='01234567'/>
 </iq>
-      ]]></example>
+]]></example>
       <p>The service responds with an "iq-result" of just the requested session.</p>
       <example caption='Information result (session-specific)'><![CDATA[
 <iq type='result' from='jobs.domain' sender='sender@domain/res'>
@@ -408,7 +408,7 @@
     <item type='connection' action='accept'>sender@domain/res</item>
   </session>
 </iq>
-      ]]></example>
+]]></example>
     </section3>
   </section2>
   <section2 topic='Connecting OOB'>
@@ -422,7 +422,7 @@ jobs/0.4 init
 session-id: 01234567
 client-jid: sender@domain/res
 
-      ]]></example>
+]]></example>
 
       <p>If the session exists, and the client's JID is not automatically rejected, the JOBS service responds with an auth-challenge packet, containing an unique, arbitrary token:</p>
 
@@ -430,7 +430,7 @@ client-jid: sender@domain/res
 jobs/0.4 auth-challenge
 confirm: SID00001234
 
-      ]]></example>
+]]></example>
 
       <p>Once received, the client then sends an "iq-set" containing a &lt;session action="authenticate"/&gt;, which itself contains an &lt;item type='auth' action='confirm'/&gt; with this confirm key:</p>
 
@@ -442,7 +442,7 @@ confirm: SID00001234
       <item type='auth' action='confirm'>SID00001234</item>
     </session>
   </iq>hehe
-      ]]></example>
+]]></example>
 
       <p>The service then compares this confirm key to that sent with the "auth-challenge" OOB packet. If this matches correctly, and the service determines this connection is authorized, the session will respond with a &lt;session action="authenticate"/&gt; containing a &lt;item type="auth" action="accept"/&gt; with the accept key:</p>
 
@@ -455,7 +455,7 @@ confirm: SID00001234
       <item type='auth' action='accept'>SID88884321</accept>
     </session>
   </iq>
-    ]]></example>
+]]></example>
 
       <p>At this point, the client responds on the OOB data stream with an "auth-response" packet:</p>
 
@@ -463,14 +463,14 @@ confirm: SID00001234
   jobs/0.4 auth-response
   accept: SID88884321
 
-    ]]></example>
+]]></example>
 
       <p>If the connection is accepted, the JOBS service sends a "connected" packet:</p>
 
       <example caption='Server CONNECTED'><![CDATA[
   jobs/0.4 connected
 
-      ]]></example>
+]]></example>
       <p>and after this, the data transfer occurs. If this connection is the sender, they may start sending data now (regardless if receivers are connected). If this connection is a receiver, the sender's data immediately follows the terminating "newline".</p>
     </section3>
     <section3 topic='Authorizing'>
@@ -487,7 +487,7 @@ confirm: SID00001234
     <item type='connection' action='confirm'>receiver@domain/res</item>
   </session>
 </iq>
-      ]]></example>
+]]></example>
 
       <p>One or more &lt;item type="connection" action="confirm/&gt; elements, each specifying a JID to accept/reject. To accept (or reject) a connection, the sender responds with an "iq-result", wrapping each JID in either an &lt;item type="connection" action="accept"/&gt; or &lt;item type="connection" action="reject"/&gt;.</p>
 
@@ -499,7 +499,7 @@ confirm: SID00001234
     <item type='connection' action='accept'>receiver@domain/res</item>
   </session>
 </iq>
-      ]]></example>
+]]></example>
       <example caption='Confirmation result (reject)'><![CDATA[
 <iq id='JOBS5' type='result' to='jobs.domain'>
   <session xmlns='http://jabber.org/protocol/jobs'
@@ -508,7 +508,7 @@ confirm: SID00001234
     <item type='connection' action='reject'>receiver@domain/res</item>
   </session>
 </iq>
-      ]]></example>
+]]></example>
 
       <p>If the connection is rejected, the service drops the connection, and notifies the sender and receiver of the dropped connection.</p>
     </section3>
@@ -523,7 +523,7 @@ confirm: SID00001234
     <item type='connection' action='drop'>receiver@domain/res</item>
   </session>
 </iq>
-      ]]></example>
+]]></example>
 
       <p>If the connection is successfully dropped, the service returns an "iq-result":</p>
 
@@ -533,7 +533,7 @@ confirm: SID00001234
       status='active'
       id='01234567'/>
 </iq>
-      ]]></example>
+]]></example>
 
       <p>The service also sends notification messages to the sender and the JID of the dropped connection (detailed in the "Being Notified about Events" section).</p>
     </section3>
@@ -553,14 +553,14 @@ confirm: SID00001234
   <session xmlns='http://jabber.org/protocol/jobs'
       action='delete'/>
 </iq>
-      ]]></example>
+]]></example>
       <example caption='Delete result'><![CDATA[
 <iq id='JOBS50' type='result' to='sender@domain/res' from='jobs.domain'>
   <session xmlns='http://jabber.org/protocol/jobs'
       status='closed'
       id='01234567'/>
 </iq>
-      ]]></example>
+]]></example>
     </section3>
   </section2>
   <section2 topic='Being Notified about Events'>
@@ -576,7 +576,7 @@ confirm: SID00001234
     <item type='connection' action='accept'/>
   </session>
 </message>
-      ]]></example>
+]]></example>
 
       <p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
     </section3>
@@ -592,7 +592,7 @@ confirm: SID00001234
     <item type='connection' action='reject'/>
   </session>
 </message>
-      ]]></example>
+]]></example>
 
       <p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
     </section3>
@@ -608,7 +608,7 @@ confirm: SID00001234
     <item type='connection' action='drop'/>
   </session>
 </message>
-      ]]></example>
+]]></example>
 
       <p>If the notification is not about the recipient of the message, then the &lt;item/&gt; contains the JID this notification pertains to.</p>
     </section3>
@@ -624,7 +624,7 @@ confirm: SID00001234
     <item type='status' action='delete'/>
   </session>
 </message>
-      ]]></example>
+]]></example>
 
       <example caption='"Session Deleted (timed out)" message'><![CDATA[
 <message to='sender@domain/res' from='jobs.domain'>
@@ -635,7 +635,7 @@ confirm: SID00001234
     <item type='status' action='expire'/>
   </session>
 </message>
-      ]]></example>
+]]></example>
 
       <p>The reason the session is deleted is specified by the action attribute. A value of "delete" means it was explicitly deleted. A value of "expire" means it timed out.</p>
     </section3>
@@ -676,7 +676,7 @@ confirm: SID00001234
     max     CDATA #REQUIRED
     min     CDATA #REQUIRED
 >
-      ]]></code>
+]]></code>
     </section3>
     <section3 topic='&lt;session/&gt; Element'>
       <p>The &lt;session/&gt; element is the core element to the protocol. This element provides both information about a session and the action applied to it. It has a large number of attributes, and contains zero or more &lt;item/&gt; elements, zero or more &lt;connect/&gt; elements, and zero or three &lt;limit/&gt; elements. It may also contain elements governed by other namespaces.</p>
@@ -1009,7 +1009,7 @@ SP :=               <US-ASCII SP, space (32)>
 CR :=               <US-ASCII CR, carriage return (13)>
 LF :=               <US-ASCII LF, linefeed (10)>
 BINDATA :=          <Arbitrary Binary Data>
-      ]]></code></section3>
+]]></code></section3>
     <section3 topic='State Details'>
       <table caption='"init" details'>
         <tr>

xep-0047.xml

@@ -133,14 +133,14 @@
         sid='i781hf64'
         stanza='iq'/>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the responder wishes to proceed with the IBB session, it returns an IQ-result to the initiator.</p>
     <example caption='Responder accepts session'><![CDATA[
 <iq from='juliet@capulet.com/balcony'
     id='jn3h8g65'
     to='romeo@montague.net/orchard'
     type='result'/>
-    ]]></example>
+]]></example>
     <p>If the responder does not support IBB, it returns a &unavailable; or &feature; error.</p>
     <example caption='Responder does not support IBB'><![CDATA[
 <iq from='juliet@capulet.com/balcony'
@@ -151,7 +151,7 @@
     <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the responder supports IBB but would prefer a smaller block-size, it returns a &constraint; error.</p>
     <example caption='Responder prefers smaller chunks'><![CDATA[
 <iq from='juliet@capulet.com/balcony'
@@ -162,7 +162,7 @@
     <resource-constraint xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>If the responder supports IBB but does not wish to proceed with the session, it returns a &notacceptable; error.</p>
     <example caption='Responder does not wish to proceed'><![CDATA[
 <iq from='juliet@capulet.com/balcony'
@@ -173,7 +173,7 @@
     <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-    ]]></example>
+]]></example>
   </section2>
 
   <section2 topic='Sending Data' anchor='send'>
@@ -192,7 +192,7 @@
     kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
   </data>
 </iq>
-    ]]></example>
+]]></example>
     <p>Each chunk of data is included as the XML character data of the &lt;data/&gt; element after being encoded as Base64 as specified in Section 4 of &rfc4648;. Each block MUST be a valid base64 block with padding at the end if needed.</p>
     <p>The &lt;data/&gt; element MUST possess a 'seq' attribute; this is a 16-bit unsigned integer that acts as a counter for data chunks sent in a particular direction within this session. The 'seq' value starts at 0 (zero) for each sender and MUST be incremented for each packet sent by that entity. Thus, the second chunk sent has a 'seq' value of 1, the third chunk has a 'seq' value of 2, and so on. The counter loops at maximum, so that after value 65535 (2<span class='super'>15</span> - 1) the 'seq' MUST start again at 0.</p>
     <p>The &lt;data/&gt; element MUST also possess a 'sid' attribute that ties the data chunk to this particular IBB session.</p>
@@ -202,7 +202,7 @@
     id='kr91n475'
     to='romeo@montague.net/orchard'
     type='result'/>
-    ]]></example>
+]]></example>
     <p>The sender of a data chunk need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize the potential for rate-limiting penalties or throttling.</p>
     <p>It is possible that delivery of the stanza might fail, in which case the sender's or recipient's server shall return an appropriate error:</p>
     <ol>
@@ -229,14 +229,14 @@
     type='set'>
   <close xmlns='http://jabber.org/protocol/ibb' sid='i781hf64'/>
 </iq>
-    ]]></example>
+]]></example>
     <p>The receiving party then acknowledges that the bytestream has been closed by returning an IQ-result (however, the receiving party might wait until it has had a chance to send any remaining data in the other direction, if the bytestream is bidirectional; in this case, the party that sent the original &lt;close/&gt; element SHOULD wait to receive the IQ response from the receiving party before considering the bytestream to be closed).</p>
     <example caption='Success response'><![CDATA[
 <iq from='juliet@capulet.com/balcony'
     id='us71g45j'
     to='romeo@montague.net/orchard'
     type='result'/>
-    ]]></example>
+]]></example>
     <p>It is possible that the recipient of the close notification does not know about the bytestream, in which case it would return an &notfound; error.</p>
     <example caption='Recipient does not know about the IBB session'><![CDATA[
 <iq type='error'
@@ -247,7 +247,7 @@
     <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>In either case, both parties MUST consider the bytestream to be closed.</p>
   </section2>
 
@@ -271,7 +271,7 @@
     kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
   </data>
 </message>
-    ]]></example>
+]]></example>
 </section1>
 
 <section1 topic='Usage Guidelines' anchor='usage'>
@@ -362,7 +362,7 @@
   </xs:simpleType>
 
 </xs:schema>
-  ]]></code>
+]]></code>
 </section1>
 
 <section1 topic='Acknowledgements' anchor='ack'>

xep-0048.xml

@@ -120,7 +120,7 @@
         <nick>Puck</nick>
       </conference>
     </storage>
-    ]]></example>
+]]></example>
    <p>This bookmark would be displayed as 'Council of Oberon' and, if activated, would attempt to join the conference room 'council@conference.underhill.org' with nickname 'Puck'.</p>
    <p>Note: A bookmark set may contain any number of conference rooms.</p>
   </section2>
@@ -152,7 +152,7 @@
       <url name='Complete Works of Shakespeare'
            url='http://the-tech.mit.edu/Shakespeare/'/>
     </storage>
-    ]]></example>
+]]></example>
     <p>This bookmark would be displayed in the client as 'Complete Works of Shakespeare' and would take the user to &lt;<link url='http://the-tech.mit.edu/Shakespeare/'>http://the-tech.mit.edu/Shakespeare/</link>&gt; when selected.</p>
     <p>Note: A bookmark set can contain any number of URLs.</p>
   </section2>
@@ -191,10 +191,10 @@
     </publish-options>
   </pubsub>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server acknowledges successful storage'><![CDATA[
 <iq to='juliet@capulet.lit/balcony' type='result' id='pip1'/>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic='Receiving Notifications' anchor='storage-pubsub-notify'>
     <p>The stored data is automatically pushed to all of the user's connected resources.</p>
@@ -236,7 +236,7 @@
     </items>
   </event>
 </message>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic='Retrieving Data' anchor='storage-pubsub-retrieve'>
     <p>In order to retrieve stored data without receiving notifications (e.g., upon initial login), the user's client sends a retrieve-items request as specified in <cite>XEP-0060</cite>.</p>
@@ -246,7 +246,7 @@
     <items node='storage:bookmarks'/>
   </pubsub>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Server returns all items'><![CDATA[
 <iq type='result'
     to='juliet@capulet.lit/randomID'
@@ -265,7 +265,7 @@
     </items>
   </pubsub>
 </iq>
-    ]]></example>
+]]></example>
   </section2>
 </section1>
 
@@ -338,7 +338,7 @@
   </xs:simpleType>
 
 </xs:schema>
-  ]]></code>
+]]></code>
 </section1>
 
 <section1 topic='Author Note' anchor='authornote'>

xep-0049.xml

@@ -112,7 +112,7 @@ SERVER:
     from="hamlet@shakespeare.lit/denmark"
     to="hamlet@shakespeare.lit/denmark"
     id="1001"/>
-    ]]></example>
+]]></example>
 
     <example caption='Client Retrieves Private Data'><![CDATA[
 CLIENT:
@@ -133,7 +133,7 @@ SERVER:
     </exodus>
   </query>
 </iq>
-    ]]></example>
+]]></example>
 
     <p>If a user attempts to get or set jabber:iq:private data that belongs to another user, the server MUST return a "Forbidden" or "Service Unavailable" error to the sender (the latter condition is in common use by existing implementations, although the former is preferable).</p>
     <example caption='User Attempts to Get or Set Data for Another User'><![CDATA[
@@ -161,7 +161,7 @@ SERVER:
         xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>If a user attempts to perform an IQ get without providing a child element, the server SHOULD return a "Bad Format" error (however, some existing implementations return a "Not Acceptable" error in such circumstances):</p>
     <example caption='User Attempts to Get Data Without Specifying Child Element/Namespace'><![CDATA[
 CLIENT:
@@ -177,7 +177,7 @@ SERVER:
         xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-    ]]></example>
+]]></example>
     <p>Certain namespaces are reserved in Jabber (namespaces beginning with 'jabber:' or 'http://jabber.org/', as well as 'vcard-temp'). If a user attempts to get or set jabber:iq:private data in a reserved namespace, historically some server implementations have chosen to return an error (commonly "Not Acceptable") to the sender. Such behavior is OPTIONAL, but may be encountered by clients when interacting with some existing server implementations.</p>
     <example caption='User Attempts to Get or Set Data in a Reserved Namespace'><![CDATA[
 CLIENT:
@@ -201,7 +201,7 @@ SERVER (optional error):
         xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </error>
 </iq>
-    ]]></example>
+]]></example>
   </section2>
 </section1>
 <section1 topic='Error Conditions'>
@@ -247,6 +247,6 @@ SERVER (optional error):
   </xs:element>
 
 </xs:schema>
-    ]]></code>
+]]></code>
 </section1>
 </xep>

xep-0050.xml

@@ -169,7 +169,7 @@
     from='requester@domain'>
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Disco result for information'><![CDATA[
 <iq type='result'
     from='responder@domain'
@@ -180,7 +180,7 @@
     ...
   </query>
 </iq>
-    ]]></example>
+]]></example>
   </section2>
   <section2 topic='Retrieving the Command List' anchor='retrieve'>
     <p>To find what commands an entity provides, the requester uses Service Discovery. Each command is a node of the responder, under the fixed node "http://jabber.org/protocol/commands" (for which the service discovery identity category is "automation" and type is "command-list"). Use of a fixed node for all commands of an entity allows for immediate retrieval of commands.</p>
@@ -193,7 +193,7 @@
   <query xmlns='http://jabber.org/protocol/disco#items'
          node='http://jabber.org/protocol/commands'/>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Disco result for items'><![CDATA[
 <iq type='result'
     to='requester@domain'
@@ -220,7 +220,7 @@
           name='Restart Service'/>
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>The result can then be used by the client to populate a menu, a dialog of buttons, or whatever is appropriate to the current user interface. The responder is not required to send the same list of commands to all requesters.</p>
     <p>If additional information about a command is desired, the requester queries for disco information on the command node:</p>
     <example caption='Disco request for command information'><![CDATA[
@@ -230,7 +230,7 @@
   <query xmlns='http://jabber.org/protocol/disco#info'
          node='config'/>
 </iq>
-    ]]></example>
+]]></example>
     <example caption='Disco result for command information'><![CDATA[
 <iq type='result'
     to='requester@domain'
@@ -244,7 +244,7 @@
     <feature var='jabber:x:data'/>
   </query>
 </iq>
-    ]]></example>
+]]></example>
     <p>A responder MUST at least provide &lt;identity category='automation' type='command-node'/&gt; and &lt;feature var='http://jabber.org/protocol/commands'/&gt;, and SHOULD include &lt;feature var='jabber:x:data'/&gt;. It is not required to support additional information about a command. If the command is not available to the requester, the responder SHOULD respond with a 403 "Forbidden" error.</p>
   </section2>
   <section2 topic='Announcing the Command List' anchor='announce'>
@@ -274,7 +274,7 @@
           name='Restart Service'/>
   </query>
 </message>
-    ]]></example>
+]]></example>
     <p>The only portion required is &lt;query xmlns='http://jabber.org/protocol/disco#items'/&gt;. Any other information (such as the &lt;subject/&gt; in the foregoing example) is OPTIONAL.</p>
   </section2>
   <section2 topic='Executing Commands' anchor='execute'>
@@ -286,7 +286,7 @@
            node='list'
            action='execute'/>
 </iq>
-      ]]></example>
+]]></example>
     <p>The requester MAY include the "action='execute'", although this is implied.</p>
     <p>If the command does not require any user interaction (returns results only), the responder sends a packet similar to the following:</p>
     <example caption="Execute command result"><![CDATA[
@@ -328,7 +328,7 @@
     </x>