diff --git a/inbox/muc-selfping.xml b/inbox/muc-selfping.xml
index afb49504..7b2da711 100644
--- a/inbox/muc-selfping.xml
+++ b/inbox/muc-selfping.xml
@@ -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