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

muc-selfping: Document nick change / 'item-not-found' response, thx jonasw

Browse Source
This commit is contained in:
Georg Lukas 2018-08-01 17:37:10 +02:00
parent f3fdd4e28c
commit aacde05426
1 changed files with 13 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
inbox/muc-selfping.xml
View File

@ -141,6 +141,9 @@
<li><strong>Error (&lt;service-unavailable&gt; or
&lt;feature-not-implemented&gt;)</strong>: the client is joined, but
the pinged client does not implement &xep0199;.</li>
<li><strong>Error (&lt;item-not-found&gt;)</strong>: the client is
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>
<li><strong>Timeout (no response)</strong>: the MUC service (or another
@ -161,6 +164,16 @@
opposed to routing it to any of the participant's clients.</p>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>In Multi-Session-Nick scenarios, where multiple clients of the same user
are joined as the same participant, it is possible that another client
initiates a nickname change while a ping request is pending. In that case,
the ping might be responded to with &lt;item-not-found&gt;.</p>
<p>A client should not perform a self-ping after initiating a nickname
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>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>A MUC service implementation should not allow a non-participant to obtain
information about participants. This is however true irregardless of