moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-22 07:38:52 -05:00
Code Issues Releases Wiki Activity

Add section on starting / stopping OTR sessions

Browse Source
This commit is contained in:
Sam Whited 2016-05-08 11:45:07 -05:00
parent cefba6e02c
commit e1e908464f
1 changed files with 44 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
xep-0364.xml
View File

@ -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