diff --git a/xep-0237.xml b/xep-0237.xml
index 58e2aceb..2d6096d8 100644
--- a/xep-0237.xml
+++ b/xep-0237.xml
@@ -27,6 +27,12 @@
   </schemaloc>
   &stpeter;
   &dcridland;
+  <revision>
+    <version>1.1rc1</version>
+    <date>2010-02-11</date>
+    <initials>psa</initials>
+    <remark><p>Corrected rules about when to include the ver attribute.</p></remark>
+  </revision>
   <revision>
     <version>1.0</version>
     <date>2009-05-27</date>
@@ -132,12 +138,25 @@
 </section1>
 
 <section1 topic='Protocol' anchor='proto'>
+  <section2 topic='Stream Feature' anchor='feature'>
+    <p>If a server supports roster versioning, it MUST inform the connecting entity when returning stream features during the stream negotiation process (at the latest, when informing a client that resource binding is required). This is done by including a &lt;ver/&gt; element qualified by the 'urn:xmpp:features:rosterver' namespace.</p>
+    <example caption="Stream features"><![CDATA[
+<stream:features>
+  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
+    <required/>
+  </bind>
+  <ver xmlns='urn:xmpp:features:rosterver'>
+    <optional/>
+  </ver>
+</stream:features>
+    ]]></example>
+  </section2>
   <section2 topic='Data Format' anchor='format'>
     <p>This document adds a new 'ver' attribute to the &QUERY; element qualified by the 'jabber:iq:roster' namespace, defined as follows.</p>
     <p class='def'><strong>Definition:</strong> The <strong>'ver' attribute</strong> is a string that identifies a particular version of the roster information. The value MUST be generated only by the server and MUST be treated by the client as opaque. The server can use any appropriate method for generating the version ID, such as a hash of the roster data or a strictly-increasing sequence number.</p>
   </section2>
   <section2 topic='Client Request' anchor='request'>
-    <p>If a client supports roster versioning, it MUST include the 'ver' element in its request for the roster, where the 'ver' attribute is set to the version ID associated with its last cache of the roster.</p>
+    <p>If a client supports roster versioning and the server to which it has connected advertises support for roster versioning as described under <link url='#feature'>Stream Feature</link>, then the client MUST include the 'ver' element in its request for the roster. If the server does not advertise support for roster versioning, the client MUST NOT include the 'ver' attribute. If included, the 'ver' attribute is set to the version ID associated with its last cache of the roster.</p>
     <example caption="Roster get with version ID"><![CDATA[
 C: <iq from='romeo@montague.lit/home' id='r1h3vzp7' to='romeo@montague.lit' type='get'>
      <query xmlns='jabber:iq:roster' ver='ver14'/>
@@ -244,20 +263,6 @@ S: <iq from='romeo@montague.lit' id='dh361f35' to='romeo@montague.lit/home' type
     ]]></example>
 </section1>
 
-<section1 topic='Stream Feature' anchor='feature'>
-  <p>If a server supports roster versioning, it MUST inform the connecting entity when returning stream features during the stream negotiation process; at the latest, when informing a client that resource binding is required. This is done by including a &lt;ver/&gt; element qualified by the 'urn:xmpp:features:rosterver' namespace.</p>
-  <example caption="Stream features"><![CDATA[
-<stream:features>
-  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
-    <required/>
-  </bind>
-  <ver xmlns='urn:xmpp:features:rosterver'>
-    <optional/>
-  </ver>
-</stream:features>
-  ]]></example>
-</section1>
-
 <section1 topic='Implementation Guidelines' anchor='impl'>
   <p>This specification is specifically designed to allow for a wide range of implementation choices. These range from highly simplistic but inefficient, to very efficient but quite complex.</p>
   <p>This section provides suggestions, rather than instructions, on some lightweight approaches to conforming with the specification.</p>