Change Carbons delivery rules to 'all IM traffic'

After discussion on the standards list at the time of Last Call, it
became clear that servers were not generally implementing Carbons as
specified. This patch updates the text to be more forgiving of such
discrepancies, and to try to reflect general consensus between
implementations of what should be eligible for carbons delivery.

xep-0280.xml

@@ -124,9 +124,9 @@
     <li>Clients that do not implement the new protocol MUST NOT
     receive protocol they do not expect</li>
     <li>All clients that turn on the new protocol MUST be able to see
-    all inbound chat-type messages.</li>
+    all inbound instant messaging messages.</li>
     <li>All clients that turn on the new protocol MUST be able to see
-    all outbound chat-type messages from all of the resources of the
+    all outbound instant messaging messages from all of the resources of the
     user, regardless of whether the clients for the other resources
     have implemented the new protocol.</li>
   </ul>
@@ -229,8 +229,22 @@
   </section2>
 </section1>
 
+<section1 topic='Messages Eligible for Carbons Delivery' anchor='which-messages'>
+    <p>The focus of this specification is instant messaging applications and so those (and only those) &MESSAGE; stanzas used for instant messaging SHOULD be delivered as Carbons. Defining precisely which messages are used for instant messaging and which are not is difficult, as future specifications may add additional payloads used for, or not used for, instant messaging; as such, the rules for which messages are eligible for carbons delivery is left as an implementation detail for servers. The following is a suggested set of rules a server MAY use, or it MAY use its own; in either case it SHOULD follow the general intent of these rules:</p>
+    <p>Possible delivery rules:
+        <ul>
+            <li>A &MESSAGE; is eligible for carbons delivery if it is of type "chat".</li>
+            <li>A &MESSAGE; is eligible for carbons delivery if it is of type "normal" and it contains a &lt;body&gt; element.</li>
+            <li>A &MESSAGE; is not eligible for carbons delivery if it is determined to have been sent by a MUC room or service, even if it would be otherwise eligible.</li>
+            <li>A &MESSAGE; is not eligible for carbons delivery if it does not meet any of these criteria.</li>
+        </ul>
+    </p>
+    <p>Future specifications may have more precise requirements on which messages need to be eligible for carbons delivery; such future specifications will provide their own discovery and negotiation mechanisms, such that a client negotiating Carbons using the protocol defined in this specification will cause the server to consider messages eligible for Carbons delivery based on the requirements described herein.</p>
+    <p>Note: previous versions of this specification limited eligible messages to those of type "chat" - however, this was generally found to be inadequate due to the proliferation of type "normal" messages used in instant messaging.</p>
+</section1>
+
 <section1 topic='Receiving Messages to the Bare JID' anchor='inbound-bare'>
-  <p>When the server receives a &MESSAGE; of type "chat" addressed to a bare JID (localpart@domainpart), it delivers a copy to each Carbons-enabled resource for the bare JID – in addition to delivering according to <cite>RFC 6121</cite> § 8.5.2. This process is sometimes called "forking".</p>
+  <p>When the server receives a &MESSAGE; <link url='#which-messages'>eligible for carbons delivery</link> addressed to a bare JID (localpart@domainpart), it first delivers it according to <cite>RFC 6121</cite> § 8.5.2, and then delivers a copy to each Carbons-enabled resource for the bare JID that did not receive it due to the <cite>RFC 6121</cite> delivery rules. This process is sometimes called "forking".</p>
 
   <example caption='Juliet sends Romeo an undirected message'><![CDATA[
 <message xmlns='jabber:client'
@@ -261,7 +275,7 @@
   <p>The receiving server MUST deliver a copy to every Carbons-enabled resource, even if that resource normally would not receive &MESSAGE; stanzas addressed to the bare JID (e.g., resources which have broadcast &PRESENCE; with a negative priority). A Carbons-enabled resource MUST NOT receive more than one copy of the &MESSAGE;.</p>
 </section1> 
 <section1 topic='Receiving Messages to the Full JID' anchor='inbound-full'>
-  <p>When the server receives a &MESSAGE; of type "chat" addressed to a full JID (localpart@domainpart/resourcepart), it delivers the &MESSAGE; according to <cite>RFC 6121</cite> § 8.5.3, and delivers a forwarded copy to each Carbons-enabled resource for the matching bare JID recipient.</p>
+  <p>When the server receives a &MESSAGE; <link url='#which-messages'>eligible for carbons delivery</link> addressed to a full JID (localpart@domainpart/resourcepart), 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. Note that the <cite>RFC 6121</cite> delivery rules can cause a &MESSAGE; addressed to a full JID to be delivered using bare JID delivery rules; in this case the server should also apply the <link url='#inbound-bare'>bare JID rules for Carbons</link>.</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[
@@ -292,10 +306,10 @@
 </message>
 ]]></example>
 
-  <p>The receiving server MUST NOT send a forwarded copy to the full JID the original &MESSAGE; stanza was addressed to, as that recipient receives the original &MESSAGE; stanza.</p>
+  <p>The receiving server MUST NOT send a forwarded copy to the client(s) receiving full JID the original &MESSAGE; stanza was addressed to, as that recipient receives the original &MESSAGE; stanza.</p>
 </section1> 
 <section1 topic='Sending Messages' anchor='outbound'>
-  <p>When a client sends a &MESSAGE; of type "chat", 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.</p>
+  <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. 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>
   <example caption='Romeo responds to Juliet'><![CDATA[
 <message xmlns='jabber:client'
@@ -357,7 +371,7 @@
 </section1> 
 <section1 topic='Business Rules' anchor='bizrules'>
   <section2 topic='Handling Multiple Enable/Disalble Requests' anchor='bizrules-multi'>
-    <p>If a client is permitted to enable Carbons during its login session, the server MUST allow the client 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>
+    <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>
   </section2>
   <section2 topic='Interaction with Chat States' anchor='bizrules-chatstates'>
     <p>Note that &xep0085; recommends sending chat state