diff --git a/xep-0155.xml b/xep-0155.xml
index 65a19df4..6b6b6259 100644
--- a/xep-0155.xml
+++ b/xep-0155.xml
@@ -663,7 +663,7 @@ PENDING  o---------------+
   </section2>
   <section2 topic='Unavailable Presence' anchor='impl-unavail'>
     <p>If a party receives an XMPP presence stanza of type "unavailable" from the full JID &LOCALFULL; of the other party (i.e., the resource with which it has had an active session) during a session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated session until it reconnects and receives "offline" messages).</p>
-    <p>However, the receiving party MAY assume that the other client will <em>not</em> be able to continue the session. <note>In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session.</note> In that case it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Session</link>) -- since its assumption could be incorrect. If after terminating the session the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the session, then it MUST initiate a new session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in <cite>XEP-0085</cite>.)</p>
+    <p>However, the receiving party MAY assume that the other client will <em>not</em> be able to continue the session. <note>In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session.</note> In that case it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Session</link>) -- since its assumption could be incorrect. If after terminating the session the receiving party later receives available presence (i.e., a &PRESENCE; stanza with no 'type' attribute) from that same resource or another resource associated with the other party and the receiving party desires to restart the session, then it MUST initiate a new session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in <cite>XEP-0085</cite>.)</p>
   </section2>
   <section2 topic='Mapping to SIP' anchor='impl-sip'>
     <p>When mapping instant messaging flows to SIP, implementations SHOULD adhere to &xmppsimple;.</p>