XEP-0280: Fix whitespace issues

xep-0280.xml

@@ -170,7 +170,7 @@
     ...
   </query>
 </iq>]]></example>
-</section1> 
+</section1>
 
 <section1 topic='Enabling Carbons' anchor='enabling'>
   <p>When a client wants to participate in the Carbons protocol, it enables the protocol by sending an IQ-set containing a child element &lt;enable/&gt; qualified by the namespace "urn:xmpp:carbons:2":</p>
@@ -207,7 +207,7 @@
     </ul>
     <p>See the section <link url='#bizrules-multi'>Handling Multiple Enable/Disable Requests</link> for considerations when a client attempts to enable Carbons multiple times.</p>
   </section2>
-</section1> 
+</section1>
 
 <section1 topic='Disabling Carbons' anchor='disabling'>
   <p>Some clients might want to disable Carbons.  To disable Carbons, the client sends an IQ-set containing a child element &lt;disable/&gt; qualified by the namespace "urn:xmpp:carbons:2":</p>
@@ -224,8 +224,7 @@
     from='romeo@montague.example'
     id='disable1'
     to='romeo@montague.example/garden'
-    type='result'/>
-  ]]></example>
+    type='result'/>]]></example>
   <p>If the server cannot disable Carbons for this client, it sends an IQ-error to the client, with an appropriate error condition (e.g., &lt;not-allowed/&gt; if trying to disable another client's Carbons):</p>
   <example caption='Server informs client cannot disable Carbons'><![CDATA[
 <iq xmlns='jabber:client'
@@ -264,7 +263,7 @@
 <section1 topic='Receiving Messages' anchor='inbound'>
   <p>When the server receives a &MESSAGE; <link url='#which-messages'>eligible for carbons delivery</link> addressed to a client JID (either bare or full), it delivers the &MESSAGE; according to <cite>RFC 6121</cite> § 8.5.3, and then delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID recipient that did not receive it under the RFC 6121 delivery rules.</p>
   <p>Each forwarded copy is wrapped using &xep0297;. The wrapping message SHOULD maintain the same 'type' attribute value; the 'from' attribute MUST be the Carbons-enabled user's bare JID (e.g., "localpart@domainpart"); and the 'to' attribute MUST be the full JID of the resource receiving the copy. The content of the wrapping message MUST contain a &lt;received/&gt; element qualified by the namespace "urn:xmpp:carbons:2", which itself contains a &lt;forwarded/&gt; element qualified by the namespace "urn:xmpp:forward:0" that contains the original &MESSAGE;.</p>
-  
+
   <example caption='Juliet sends Romeo a directed message'><![CDATA[
 <message xmlns='jabber:client'
          from='juliet@capulet.example/balcony'
@@ -294,7 +293,7 @@
 ]]></example>
 
   <p>The receiving server MUST NOT send a forwarded copy to the client(s) the original &MESSAGE; stanza was addressed to, as these recipients receive the original &MESSAGE; stanza.</p>
-</section1> 
+</section1>
 <section1 topic='Sending Messages' anchor='outbound'>
   <p>When a client sends a &MESSAGE; <link url='#which-messages'>eligible for carbons delivery</link>, its sending server delivers the &MESSAGE; according to <cite>RFC 6120</cite> and <cite>RFC 6121</cite>, and delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID sender, excluding the sending client. Note that this happens irrespective of whether the sending client has carbons enabled.</p>
   <p>Each forwarded copy is wrapped using &xep0297;. The wrapping message SHOULD maintain the same 'type' attribute value; the 'from' attribute MUST be the Carbons-enabled user's bare JID (e.g., "localpart@domainpart"); and the 'to' attribute SHOULD be the full JID of the resource receiving the copy. The content of the wrapping message MUST contain a &lt;sent/&gt; element qualified by the namespace "urn:xmpp:carbons:2", which itself contains a &lt;forwarded/&gt; qualified by the namespace "urn:xmpp:forward:0" that contains the original &MESSAGE; stanza.</p>
@@ -328,7 +327,7 @@
 
   <p>The sending server SHOULD NOT send a forwarded copy to the sending full JID if it is a Carbons-enabled resource.</p>
 
-</section1> 
+</section1>
 <section1 topic='Avoiding Carbons for a single message' anchor='avoiding'>
   <p>Some clients might want to avoid Carbons on a single message, while still keeping all of the other semantics of Carbon support. This might be useful for clients sending end-to-end encrypted messages, for example. To exclude a &MESSAGE; from being forwarded to other Carbons-enabled resources, the sending client add a &lt;private/&gt; element qualified by the namespace "urn:xmpp:carbons:2" as a child content element to the &MESSAGE; stanza.</p>
 
@@ -355,7 +354,7 @@
 </message>]]></example>
   <p>The sending server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resources of the sender. The receiving server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resource of the recipient, and SHOULD remove the &lt;private/&gt; element before delivering to the recipient.</p>
   <p><strong>Note:</strong> if the private &MESSAGE; stanza is addressed to a bare JID, the receiving server still delivers it according to <cite>RFC 6121</cite>. This might result in a copy being delivered to each resource for the recipient, which effectively negates the behavior of the &lt;private/&gt; element for recipients.</p>
-</section1> 
+</section1>
 <section1 topic='Business Rules' anchor='bizrules'>
   <section2 topic='Handling Multiple Enable/Disable Requests' anchor='bizrules-multi'>
     <p>If a client is permitted to enable Carbons during its login session, the server MUST allow the client to enable and disable the protocol multiple times within a session.  The server SHOULD NOT treat multiple enable requests (without an intermediate disable request) as an error; it SHOULD simply return an IQ-result (if the protocol is already enabled) or an IQ-error (if the client is not permitted to enable Carbons) for any subsequent requests after the first. Similarly, the server SHOULD NOT treat multiple disable requests (without an intermediate enable request) as an error; it SHOULD return an IQ-result (if the protocols is already disabled) or an IQ-error (if the client's request failed previously) for any subsequent requests after the first.</p>
@@ -373,7 +372,7 @@
   </section2>
   <section2 topic='Handling of Errors' anchor='bizrules-errors'>
     <p>When a receiving server attempts to deliver a forked message, and that message bounces with an error for any reason, the receiving server MUST NOT forward that error back to the original sender.  The receiving server SHOULD use the sent element in the bounce to determine that an error is from a forked message.</p>
-    <p>This rule is used to prevent some of the half-failure modes that have been an issue in other prototocols.</p> 
+    <p>This rule is used to prevent some of the half-failure modes that have been an issue in other prototocols.</p>
   </section2>
   <section2 topic='Auto-responses' anchor='bizrules-autoresponses'>
     <p>Clients that automatically respond to messages for any reason (e.g., when in the "dnd" presence show state) MUST take adequate care when enabling Carbons in order to prevent storms or loops.  Carbon copies of messages MUST NOT be auto-replied to under any circumstances.  Forked inbound messages MUST NOT be auto-replied to unless the client has some way of ensuring no more than one auto-reply is sent from all of its user's resources.</p>
@@ -387,7 +386,7 @@
   <p>Outbound chat messages that are encrypted end-to-end are not often useful to receive on other resources.  As such, they should use the &lt;private/&gt; element specified above to avoid such copying, unless the encryption mechanism is able to accommodate this protocol.</p>
 </section1>
 <section1 topic='IANA Considerations' anchor='iana'>
-  <p>This document requires no interaction with &IANA;.</p> 
+  <p>This document requires no interaction with &IANA;.</p>
 </section1>
 <section1 topic='XMPP Registrar Considerations' anchor='reg'>
   <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
@@ -412,7 +411,7 @@
     elementFormDefault='qualified'>
 
   <xs:element name='disable' type='empty'/>
-  
+
   <xs:element name='enable' type='empty'/>
 
   <xs:element name='private' type='empty'/>
@@ -426,7 +425,7 @@
       <xs:enumeration value=''/>
     </xs:restriction>
   </xs:simpleType>
-  
+
   <xs:complexType name='forward-container' abstract='true'>
     <xs:choice>
       <xs:element name='forwarded'
@@ -437,7 +436,7 @@
   </xs:complexType>
 
 </xs:schema>
-  ]]></code>
+]]></code>
 </section1>
 <section1 topic='Acknowledgements' anchor='ack'>
   <p>The authors wish to thank Patrick Barry, Teh Chang, Jack Erwin, Craig Kaes, Kathleen McMurry, Tory Patnoe, Peter Saint-Andre, Ben Schumacher, and Kevin Smith for their feedback.</p>