diff --git a/xep-0166.xml b/xep-0166.xml
index 44b93ed6..bb9547c0 100644
--- a/xep-0166.xml
+++ b/xep-0166.xml
@@ -925,7 +925,7 @@ PENDING  o----------------------+   |
       <p>The <strong>content-remove</strong> action is used to remove one or more content definitions from the session. The sender MUST specify only the removed content definition(s), not the removed content definition(s) plus the remaining content definition(s). Therefore it is the responsibility of the recipient to maintain a local copy of the current content definition(s). Upon receiving a content-remove from the other party, the recipient MUST NOT send a content-accept and MUST NOT continue to negotiate the transport method related to that content definition or send application data related to that content definition.  <note>If the content-remove results in zero content definitions for the session, the entity that receives the content-remove SHOULD send a session-terminate action to the other party (since a session with no content definitions is void).</note></p>
     </section3>
     <section3 topic='session-accept' anchor='def-action-session-accept'>
-      <p>The <strong>session-accept</strong> action is used to definitively accept a session negotiation (implicitly this action also serves as a content-accept). A session-accept action indicates acceptance <em>only</em> of the content definition(s) included in the session-initiate, not any content definition(s) subsequently added during the PENDING state. In the session-accept stanza, the &JINGLE; element MUST contain one or more &lt;content/&gt; elements, each of which MUST contain one &lt;description/&gt; element and one &lt;transport/&gt; element. The &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity; after sending acknowledgement of the session-accept, the initiator SHOULD send all future commmunications about this Jingle session to the JID provided in the 'responder' attribute and note the new JID in the user interface.</p>
+      <p>The <strong>session-accept</strong> action is used to definitively accept a session negotiation (implicitly this action also serves as a content-accept). A session-accept action indicates acceptance <em>only</em> of the content definition(s) whose disposition type is "session" (the default value of the &CONTENT; element's 'disposition' attribute), not any content definition(s) whose disposition type is something other than "session" (e.g., "early-session" for early media). In the session-accept stanza, the &JINGLE; element MUST contain one or more &lt;content/&gt; elements, each of which MUST contain one &lt;description/&gt; element and one &lt;transport/&gt; element. The &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity; after sending acknowledgement of the session-accept, the initiator SHOULD send all future commmunications about this Jingle session to the JID provided in the 'responder' attribute and note the new JID in the user interface.</p>
     </section3>
     <section3 topic='session-info' anchor='def-action-session-info'>
       <p>The <strong>session-info</strong> action is used to send session-level information, such as (for Jingle RTP sessions) a ringing message.</p>