moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

XEP-0384: Fix misspellings

Browse Source
This commit is contained in:
Melvin Keskin 2020-03-12 19:12:52 +01:00
parent 226b58b312
commit 324507d8ee
No known key found for this signature in database
GPG Key ID: 04EFAD0F7A4D9724
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
xep-0384.xml
View File

@ -508,7 +508,7 @@
<section2 topic='Receiving a message' anchor='usecases-receiving'> <section2 topic='Receiving a message' anchor='usecases-receiving'>
<p>When an OMEMO element is received, the client MUST check whether there is a &lt;keys&gt; element with a jid attribute matching its own bare jid and an inner &lt;key&gt; element with a rid attribute matching its own device id. If this is not the case the message was not encrypted for this particular device and a warning message SHOULD be displayed instead. If such an element exists, the client checks whether the element's contents are an OMEMOKeyExchange.</p> <p>When an OMEMO element is received, the client MUST check whether there is a &lt;keys&gt; element with a jid attribute matching its own bare jid and an inner &lt;key&gt; element with a rid attribute matching its own device id. If this is not the case the message was not encrypted for this particular device and a warning message SHOULD be displayed instead. If such an element exists, the client checks whether the element's contents are an OMEMOKeyExchange.</p>
<p>If this is the case, a new session is built from this received element. The client MUST then republish their bundle information, replacing the used PreKey, such that it won't be used again by a different client. If the client already has a session with the sender's device, it MUST replace this session with the newly built session. The client MUST eventually delete the private key belonging to the PreKey after use (this is subject to the <link url="#business-rules">Business rules</link>).</p> <p>If this is the case, a new session is built from this received element. The client MUST then republish their bundle information, replacing the used PreKey, such that it won't be used again by a different client. If the client already has a session with the sender's device, it MUST replace this session with the newly built session. The client MUST eventually delete the private key belonging to the PreKey after use (this is subject to the <link url="#business-rules">Business rules</link>).</p>
<p>If the element's contents are a OMEMOAuthenticatedMessage, and the client has a session with the sender's device, it tries to decrypt the OMEMOAuthenticatedMessage using this session. If the decryption fails or there is no session with the sending device, a warning message SHOULD be displayed instead. Also refer to the section about recovering from broken sessions in the <link url="#business-rules">Business Rules</link>.</p> <p>If the element's contents are an OMEMOAuthenticatedMessage, and the client has a session with the sender's device, it tries to decrypt the OMEMOAuthenticatedMessage using this session. If the decryption fails or there is no session with the sending device, a warning message SHOULD be displayed instead. Also refer to the section about recovering from broken sessions in the <link url="#business-rules">Business Rules</link>.</p>
<p> <p>
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>. 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> </p>
@ -547,7 +547,7 @@
</section3> </section3>
<section3 topic='Fetching devices and bundles' anchor='group-fetch'> <section3 topic='Fetching devices and bundles' anchor='group-fetch'>
<p>Before sending a message a participant MUST explicitly fetch device lists (if not already cached) for each of the members.</p> <p>Before sending a message a participant MUST explicitly fetch device lists (if not already cached) for each of the members.</p>
<example caption='Juliet fetching devices for Remeo and Mercutio'><![CDATA[ <example caption='Juliet fetching devices for Romeo and Mercutio'><![CDATA[
<iq type='get' from='juliet@capulet.lit' to='romeo@montague.lit' id='gfetch0'> <iq type='get' from='juliet@capulet.lit' to='romeo@montague.lit' id='gfetch0'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node=']]>&nsdevices;<![CDATA['/> <items node=']]>&nsdevices;<![CDATA['/>