Add section on starting / stopping OTR sessions

xep-0364.xml

@@ -223,6 +223,50 @@
       </p>
     </section2>
   </section1>
+  <section1 topic='OTR Sessions'>
+    <section2 topic='Starting an OTR session'>
+      <p>
+        Most clients today provide options to automatically start an OTR
+        session, to manually construct a session at the users request, or to
+        always require the use of an OTR session even if the remote client does
+        not support OTR.
+      </p>
+      <p>
+        In the interest of user experience, it is NOT RECOMMENDED to start an
+        OTR session with a previously unseen resource or one for which we do not
+        have OTR keys cached without first discovering if the remote end
+        supports OTR using one of the mechanisms described in the "Discovery"
+        section of this document except in security critical contexts where user
+        experience is not a concern.
+      </p>
+      <p>
+        Instead, it is RECOMMENDED to always allow the user to manually start an
+        OTR session and to indicate that OTR is known to be available when OTR
+        support is discovered by any of the aforementioned mechanisms.
+      </p>
+    </section2>
+    <section2 topic='Ending an OTR session'>
+      <p>
+        It is RECOMMENDED that the lifetime of OTR sessions be limited to the
+        lifetime of the XMPP session in which the OTR session was established.
+        If a resource associated with either end of the OTR session goes offline
+        (a closing stream tag is received, or a fatal stream error occurs), it
+        is RECOMMENDED that the other end terminate the OTR session.
+      </p>
+      <p>
+        When an XMPP session that is hosting an OTR session ends, it is
+        RECOMMENDED that XMPP session be completely torn down before the
+        associated OTR session is ended. For instance, when receiving a closing
+        stream tag, clients should send their own closing stream tag (as
+        specified in &rfc6120;), close the underlying TCP connection (or
+        connections), and then terminate the OTR session in that order. This
+        prevents a race condition in some clients that attempt to automatically
+        establish an OTR session where the OTR session is torn down and then
+        re-established by an incomming message before the XMPP session can be
+        closed.
+      </p>
+    </section2>
+  </section1>
   <section1 topic='Use in XMPP URIs'>
     <p>
       &rfc5122; defines a Uniform Resource Identifier (URI) and