diff --git a/xep-0167.xml b/xep-0167.xml
index f3d3c638..45603c21 100644
--- a/xep-0167.xml
+++ b/xep-0167.xml
@@ -265,7 +265,7 @@
      <li><p>The semantics of the &DESCRIPTION; element are defined in the <link url='#format'>Application Format</link> section of this document.</p></li>
      <li><p>A mapping of Jingle semantics to the Session Description Protocol is provided in the <link url='#sdp'>Mapping to Session Description Protocol</link> section of this document.</p></li>
      <li><p>A Jingle RTP session SHOULD use a datagram transport method (e.g. &xep0177; or the "ice-udp" method specified in &xep0176;), but MAY use a streaming transport if the end-to-end link has minimal latency and the media negotiated is not unduly heavy (e.g., it might be possible to use a streaming transport for audio, but not for video).</p></li>
-     <li><p>If multiple components are to be communicated over the chosen transport, the component numbered "1" shall be associated with RTP and the component numbered "2" shall be associated with the Real Time Control Protocol (RTCP).</p></li>
+     <li><p>Jingle RTP requires two components: one for RTP itself and one for the Real Time Control Protocol (RTCP). The component numbered "1" MUST be associated with RTP and the component numbered "2" MUST be associated with RTCP. Even if an implementation does not support RTCP, it MUST accept Jingle content types that include component "2" by mirroring the second component in its replies (however, it would simply ignore the RTCP-related data during the RTP session).</p></li>
      <li>
        <p>Content is to be sent and received as follows:</p>
        <ul>
@@ -589,8 +589,13 @@ delivery-method=inline; configuration=somebase16string;
     inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:32
     KDR=1 UNENCRYPTED_SRTCP
   ]]></code>
-  <p>When the responder receives a session-initiate message containing an &lt;encryption/&gt; element with the 'required' attribute set to TRUE, the responder MUST either (1) accept the offer by denoting one of the &lt;crypto/&gt; elements as acceptable (it does this by mirroring that &lt;crypto/&gt; element in its session acceptance) or (2) reject the offer by sending a session-terminate message with a Jingle reason of &lt;security-error/&gt; (typically with an RTP-specific condition of &lt;invalid-crypto/&gt;).</p>
-  <p>If the 'required' attribute is set to FALSE (this is the default), depending on personal security policies or client configuration the responder SHOULD accept the offer if possible, but MAY simply proceed without encryption.</p>
+  <p>When the responder receives a session-initiate message containing an &lt;encryption/&gt; element, the responder MUST do one of the following:</p>
+  <ol>
+    <li>Attempt to proceed with an encrypted session by including the acceptable credentials (i.e., the relevant &lt;crypto/&gt; element) in its session-accept message.</li>
+    <li>Attempt to proceed with an unencrypted session by not including any &lt;crypto/&gt; element in its session-accept message (it is up to the initiator to reject this attempt if desired).</li>
+    <li>Reject the initiator's offer by sending a session-terminate message with a Jingle reason of &lt;security-error/&gt; (typically with an RTP-specific condition of &lt;invalid-crypto/&gt;).</li>
+  </ol>
+  <p>Which of these the responder does is a matter of personal security policies or client configuration.</p>
   <example caption="Responder terminates session because of invalid crypto"><![CDATA[
 <iq from='juliet@capulet.lit/balcony'
     id='nv71c396'