diff --git a/xep-0170.xml b/xep-0170.xml
index 1df67e5b..ec7d211d 100644
--- a/xep-0170.xml
+++ b/xep-0170.xml
@@ -10,7 +10,7 @@
   <abstract>This document specifies a recommended order for negotiation of XMPP stream features.</abstract>
   &LEGALNOTICE;
   <number>0170</number>
-  <status>Proposed</status>
+  <status>Active</status>
   <type>Informational</type>
   <jig>Standards JIG</jig>
   <approver>Council</approver>
@@ -24,6 +24,12 @@
   <supersededby/>
   <shortname>N/A</shortname>
   &stpeter;
+  <revision>
+    <version>1.0</version>
+    <date>2007-01-04</date>
+    <initials>psa</initials>
+    <remark>Per a vote of the XMPP Council, advanced status to Active.</remark>
+  </revision>
   <revision>
     <version>0.5</version>
     <date>2006-12-06</date>
@@ -71,18 +77,16 @@
       <li>TLS</li>
       <li>SASL</li>
       <li>Resource binding</li>
-      <li>IM session establishment</li>
     </ol>
     <p>That order MUST be followed if no other stream features are negotiated.</p>
   </section2>
   <section2 topic='Stream Compression' anchor='c2s-compress'>
-    <p>&xep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
+    <p>&xep0138; is negotiated when it is not possible to set up TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
     <ol>
       <li>TLS</li>
       <li>SASL</li>
       <li>Stream compression</li>
       <li>Resource binding</li>
-      <li>IM session establishment</li>
     </ol>
   </section2>
   <section2 topic='In-Band Registration' anchor='c2s-register'>
@@ -92,7 +96,6 @@
       <li>In-band registration</li>
       <li>SASL</li>
       <li>Resource binding</li>
-      <li>IM session establishment</li>
     </ol>
     <p>If both stream compression and in-band registration are negotiated, the following order is RECOMMENDED:</p>
     <ol>
@@ -101,7 +104,6 @@
       <li>SASL</li>
       <li>Stream compression</li>
       <li>Resource binding</li>
-      <li>IM session establishment</li>
     </ol>
   </section2>
 </section1>
@@ -123,7 +125,7 @@
     </ol>
   </section2>
   <section2 topic='Stream Compression' anchor='s2s-compress'>
-    <p>&xep0138; is negotiated when it is not possible to set TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation fo both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
+    <p>&xep0138; is negotiated when it is not possible to set up TLS compression for whatever reason. It seems safest to negotiate stream compression after negotiation of both TLS (to safely complete the negotiation) and SASL (to prevent certain denial-of-service attacks). Therefore the following order is RECOMMENDED:</p>
     <ol>
       <li>TLS</li>
       <li>SASL</li>
diff --git a/xep-0190.xml b/xep-0190.xml
index 59f013bf..8fab4ee4 100644
--- a/xep-0190.xml
+++ b/xep-0190.xml
@@ -7,10 +7,10 @@
 <xep>
 <header>
   <title>Best Practice for Closing Idle Streams</title>
-  <abstract>This document specifies a best practice for closing an idle XMPP stream.</abstract>
+  <abstract>This document specifies a best practice for closing an XML stream that is perceived to be idle.</abstract>
   &LEGALNOTICE;
   <number>0190</number>
-  <status>Proposed</status>
+  <status>Active</status>
   <type>Informational</type>
   <jig>Standards JIG</jig>
   <dependencies>
@@ -25,6 +25,12 @@
     <email>lynX@jabber.getting.psyced.org</email>
     <jid>lynX@ve.symlynX.com</jid>
   </author>
+  <revision>
+    <version>1.0</version>
+    <date>2007-01-04</date>
+    <initials>psa</initials>
+    <remark>Per a vote of the XMPP Council, advanced status to Active.</remark>
+  </revision>
   <revision>
     <version>0.1</version>
     <date>2006-07-26</date>
@@ -47,7 +53,7 @@
 
 <section1 topic='Introduction' anchor='intro'>
   &RFC3920BISNOTE;
-  <p><cite>RFC 3920</cite> describes several ways to terminate an XMPP stream, but does not always make a clear statement about which to use. This can lead to faulty implementations. In particular, closing a stream that has not been in use for a while is very often achieved using a connection-timeout error, then closing the socket. This can lead to loss of data. Therefore this document proposes a practice that will avoid such data loss.</p>
+  <p><cite>RFC 3920</cite> describes several ways to terminate an XML stream, but does not always make a clear statement about which to use. This can lead to faulty implementations. In particular, closing a stream that has not been in use for a while is very often achieved using a connection-timeout error, then closing the socket. This can lead to loss of data. Therefore this document proposes a practice that will avoid such data loss.</p>
   <p>Note: The recommendation described herein has been incorporated into <cite>rfc3920bis</cite>.</p>
 </section1>