diff --git a/xep-0138.xml b/xep-0138.xml
old mode 100644
new mode 100755
index 87f8fae8..0c366e3a
--- a/xep-0138.xml
+++ b/xep-0138.xml
@@ -151,52 +151,12 @@
     ]]></example>
   </section1>
 
-<!--
-  <section1 topic='Feature Negotiation (Optional)' anchor='negotiation'>
-    <p>The initiating entity and receiving entity MAY support &xep0020; for more fine-grained negotiation of parameters (such as compression levels). Such support is OPTIONAL, and the initiating entity should expect that the receiving entity may not support feature negotiation. Because use of &xep0030; to discover negotiable features is inconvenient during stream negotiation, the initiating entity SHOULD negotiate only features that are registered for use with the 'http://jabber.org/protocol/compress' FORM_TYPE as described in the <link url="#registrar-formtype">Field Standardization</link> section of this document.</p>
-    <p>The initiating entity MAY include a feature negotiation child within the initial &lt;compress/&gt; element requesting stream compression:</p>
-    <example caption='Initiating Entity Requests Stream Compression (With Feature Negotiation)'><![CDATA[
-<compress xmlns='http://jabber.org/protocol/compress'>
-  <method>foobar</method>
-  <feature xmlns='http://jabber.org/protocol/feature-neg'>
-    <x xmlns='jabber:x:data' type='submit'>
-      <field type='hidden' var='FORM_TYPE'>
-         <value>http://jabber.org/protocol/compress/method/foobar</value>
-      </field>
-      <field var='foobar-compression-level'>
-         <value>3</value>
-      </field>
-    </x>
-  </feature>
-</compress>
-    ]]></example>
-    <p>If the receiving entity does not support the use of feature negotiation within stream compression, it MUST ignore the &lt;feature/&gt; element.</p>
-    <p>If the receiving entity does not support one or more of the included features, it MUST return a &lt;failure/&gt; containing an XMPP &feature; error and SHOULD specify the feature(s) not implemented in an XMPP &lt;text/&gt; element.</p>
-    <example caption="Receiving entity does not support a feature"><![CDATA[
-<compress xmlns='http://jabber.org/protocol/compress'>
-  <failure>
-    <feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
-    <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>foobar-compression-level</text>
-  </failure>
-</compress>
-    ]]></example>
-    <p>If the receiving entity supports none of the included options for a certain feature, it MUST return a &lt;failure/&gt; containing an XMPP &notacceptable; error and SHOULD specify the option(s) not supported in an XMPP &lt;text/&gt; element.</p>
-    <example caption="Receiving entity does not support an option"><![CDATA[
-<compress xmlns='http://jabber.org/protocol/compress'>
-  <failure>
-    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
-    <text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>foobar-compression-level: 3</text>
-</compress>
-    ]]></example>
-  </section1>
--->
-
   <section1 topic='Business Rules' anchor='bizrules'>
     <p>The following business rules apply:</p>
     <ul>
       <li>If stream compression is negotiated, it MUST be used in both directions.</li>
       <li>TLS compression and stream compression SHOULD NOT be used simultaneously.</li>
-      <li>Stream compression MAY be offered after TLS negotiation if TLS compression fails.</li>
+      <li>Stream compression MAY be offered after TLS negotiation if TLS compression is not used.</li>
     </ul>
     <p>For detailed recommendations regarding the order of stream feature negotiation, refer to &xep0170;.</p>
   </section1>
@@ -219,6 +179,7 @@
 
   <section1 topic='Security Considerations' anchor='security'>
     <p>Stream encryption via TLS (as defined in <cite>RFC 3920</cite>) and stream compression (as defined herein) are not mutually exclusive, but stream encryption via TLS MUST be negotiated before negotiation of stream compression in order to secure the stream.</p>
+    <p>Many of the security considerations related to TLS compression (see Section 6 of <cite>RFC 3749</cite>) also apply to stream compression.</p>
   </section1>
 
   <section1 topic='IANA Considerations' anchor='iana'>
@@ -255,11 +216,6 @@
         ]]></code>
       </section3>
     </section2>
-    <!--
-    <section2 topic='Field Standardization' anchor='registrar-formtype'>
-      <p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. Reserved fields shall be registered with the XMPP Registrar as necessary.</p>
-    </section2>
-    -->
   </section1>
 
   <section1 topic='XML Schemas' anchor='schemas'>