moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

XEP-0410: mention 0198 and explicit re-join

Browse Source
This commit is contained in:
Georg Lukas 2019-01-15 17:26:10 +01:00
parent 9adae7a321
commit e56fc624a1
1 changed files with 6 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
xep-0410.xml
View File

@ -61,7 +61,8 @@
protocol).</p>
<p>This specification aims to provide the most efficient, albeit not the
most elegant, way for clients to periodically check whether they are still
joined to a chatroom.</p>
joined to a chatroom. However, it can not ensure that a client remains
joined to a room without any interruptions.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This specification only makes sense in the context of &xep0045;
@ -158,7 +159,7 @@
joined, but the participant just changed their name (e.g. initiated by
a different client).</li>
<li><strong>Any other error</strong>: the client is probably not
joined.</li>
joined any more. It should perform a re-join.</li>
<li><strong>Timeout (no response)</strong>: the MUC service (or another
client) is unreachable. The client may indicate the status to the user
and re-attempt the self-ping after some timeout, until it receives
@ -198,6 +199,9 @@
change, and before receiving the response to the nickname change from the
service, as it is not yet clear whether the new nickname will be accepted.
</p>
<p>If a client session is in hibernation (&xep0198;), the client should defer
sending of self-ping requests until it is reconnected and re-authenticated.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>A MUC service implementation should not allow a non-participant to obtain