+ 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. +
++ 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. +
++ 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. +
++ 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. +
++ 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. +
+&rfc5122; defines a Uniform Resource Identifier (URI) and