diff --git a/xep-0280.xml b/xep-0280.xml
index 9d2c63ce..9a73b385 100644
--- a/xep-0280.xml
+++ b/xep-0280.xml
@@ -53,6 +53,12 @@
     <email>georg@op-co.de</email>
     <jid>georg@yax.im</jid>
   </author>
+  <revision>
+    <version>0.14.0</version>
+    <date>2021-09-28</date>
+    <initials>gl</initials>
+    <remark><p>Incorporate LC feedback: Remove requirement to remove "private" elements (and add interop note), completely reword mobile considerations to fit modern reality.</p></remark>
+  </revision>
   <revision>
     <version>0.13.4</version>
     <date>2021-05-25</date>
@@ -330,8 +336,8 @@
     <ul>
       <li>it is of type "chat".</li>
       <li>it is of type "normal" and contains a &lt;body&gt; element.</li>
-      <li>it contains payload elements typically used in IM (&xep0184;, &xep0085;).</li>
-      <li>it is of type "error" and it was sent in response to a &MESSAGE; that was eligible for carbons delivery (Note that as this would require message tracking and correlation on the server, it is unlikely to be generally appropriate for most implementations).</li>
+      <li>it contains payload elements typically used in IM (&xep0184;, &xep0085;, &xep0333;).</li>
+      <li>it is of type "error" and it was sent in response to a &MESSAGE; that was eligible for carbons delivery.</li>
       <li>it matches the MUC-related rules outlined below.</li>
     </ul>
     <p>To properly handle messages exchanged with a MUC (or similar service), the server must be able to identify MUC-related messages. This can be accomplished by tracking the clients' presence in MUCs, or by checking for the <tt>&lt;x xmlns="http://jabber.org/protocol/muc#user"&gt;</tt> element in messages. The following rules apply to MUC-related messages:
@@ -466,9 +472,9 @@
     <li> The sending client MAY exclude a &MESSAGE; from being forwarded to other Carbons-enabled resources, by adding a &lt;private/&gt; element qualified by the namespace "urn:xmpp:carbons:2" and a &lt;no-copy/&gt; hint as described in &xep0334; as child elements of the &MESSAGE; stanza.</li>
     <li>The sending server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resources of the sender.</li>
     <li>The receiving server MUST NOT deliver forwarded &MESSAGE;s to the other Carbons-enabled resource of the recipient,</li>
-    <li>and the receiving server SHOULD remove the &lt;private/&gt; element before delivering to the recipient.</li>
   </ul>
 
+  <p>Interoperability note: earlier versions of this XEP required or recommended the removal of the &lt;private/&gt; element (albeit not of the &lt;no-copy/&gt; hint) by one of the involved servers, but this behavior was considered as a potential security issue as the sender could silently manipulate the delivery of messages, so that the requirement was lifted. However, clients MUST NOT assume that a message without the element was actually routed to all other resources of the account.</p>
   <p><strong>Note:</strong>
     Use of the private mechanism might lead to partial conversations on other devices. This is the intended effect.
     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>
@@ -529,7 +535,7 @@
     <p>Forwarded 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>
   </section2>
   <section2 topic='Mobile Considerations' anchor='bizrules-mobile'>
-    <p>Enabling this protocol on mobile devices needs to be undertaken with care. This protocol can result in additional bandwidth and power usage, possibly decreasing battery lifetime and increasing monetary costs.  Additional mechanisms for controlling the Carbon-copying of individual conversations might need to be added to deal with mobile clients in the future.</p>
+    <p>Mobile clients are often connected to the server in parallel to another (desktop) client. Therefore, it is highly recommended for mobile clients to implement this protocol to receive all live traffic, and to generally follow the <link url="https://xmpp.org/about/compliance-suites-current#mobile">Mobile Compliance Suite</link> recommendations.</p>
   </section2>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>