XEP-0384: rephrase 'session termination' to 'opting-out'

Sessions are device-to-device relationships. When we talk about
'opting-out' we want to communicate a _preference_ for an entire account
not just on specific device-to-device relationship.

The actual double ratchet sessions will also remain intact. So it is not
reversing what ever we did in 'Starting a session' but just switching back
from omemo to plain. (When we currently do that manuelly we also wouldn’t
touch the actual underlying sessions)

I would like to note at this point that we don’t have a way of 'opting-in'
either. Nowhere do we say that a client MUST use OMEMO if they discover
that the other side has bundles. Therefor I find it strange that the opt-out
was a MUST and i weakend it to SHOULD. (we don’t say that a client SHOULD start
omemo when it discovers support either so I even find a SHOULD too strong)

xep-0384.xml

@@ -442,15 +442,6 @@
 </iq>]]></example>
     <p>A random pk entry is selected, and used to build an OMEMO session.</p>
   </section2>
-  <section2 topic='Ending a session' anchor='usecases-ending'>
-    <p>In order to signal a contact that you like to terminate a session, your
-    device MUST send a &lt;terminate&gt; element to all intended recipient devices
-    inside an encrypted stanza. A user or client MAY tag the element with a
-    reason. If a device is receiving a stanza containing a &lt;terminate&gt; element,
-    it MUST show an information that the peer has ended the session. To prevent
-    that the user is accidentally sending plaintext messages, the client MUST
-    block all outgoing message until the user switched to plaintext.</p>
-  </section2>
   <section2 topic='Sending a message' anchor='usecases-messagesend'>
     <p>
       In order to send a chat message, extension elements that are deemed sensible first have to be
@@ -525,6 +516,31 @@
       After either the OMEMOKeyExchange or the OMEMOAuthenticatedMessage is decrypted, the content is decrypted as described in the section about <link url="#protocol-message_decryption">Message Decryption</link>.
     </p>
   </section2>
+  <section2 topic='Opt-out' anchor='opt-out'>
+    <p>An account can signal to a peer that it wants to stop communicating using
+    OMEMO encrypted messages and would like to proceed in plain text instead. To do
+    that any of that account’s devices sends an &lt;opt-out/&gt; element qualified
+    by the <tt>&ns;</tt> namespace to all intended recipient devices
+    inside an encrypted stanza. The element MAY contain a child element &lt;reason&gt;.
+    If a device is receiving an encrypted stanza containing an &lt;opt-out/&gt; element,
+    it SHOULD display the information, that the peer would like to receive plain text messages.
+    To prevent that the user is accidentally sending plaintext messages, the client MUST
+    block all outgoing message until the user has confirmed the switch to plaintext.
+    Any existing double ratchet sessions SHOULD remain intact. At any point any party MAY
+    revert their decision and go back to sending OMEMO encrypted messages again.</p>
+    <example caption='A client signaling that it’s account no longer wants to receive OMEMO-encrypted messages'><![CDATA[
+<content xmlns='urn:xmpp:sce:0'>
+  <payload>
+    <opt-out xmlns=']]>&ns;<![CDATA['>
+      <reason>
+        Sorry, but for compliance reasons I need a permanent,
+        server-side, record of our conversation.
+      </reason>
+    </opt-out>
+  </payload>
+</content>
+]]></example>
+  </section2>
   <section2 topic='Group Chats' anchor='group-chats'>
     <p>Note: OMEMO encrypted group chats are currently specified to work with &xep0045;. This XEP might be updated in the future to specify the usage of OMEMO in conjunction with &xep0369;.</p>
     <p>A Multi-User Chat room that supports OMEMO MUST be configured non-anonymous and SHOULD be configured members-only.</p>