From 67be001a36e07561f4a024623e8c8155ced5da69 Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre <stpeter@jabber.org>
Date: Tue, 22 May 2007 15:00:26 +0000
Subject: [PATCH] 0.4

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@856 4b5297f7-1745-476d-ba37-a9c6900126ab
---
 xep-0199.xml | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/xep-0199.xml b/xep-0199.xml
index 3bd38ac2..721ec090 100644
--- a/xep-0199.xml
+++ b/xep-0199.xml
@@ -21,6 +21,12 @@
   <supersededby/>
   <shortname>TO BE ASSIGNED</shortname>
   &stpeter;
+  <revision>
+    <version>0.4</version>
+    <date>2007-05-21</date>
+    <initials>psa</initials>
+    <remark><p>Modified security considerations to ensure coherence of error handling between client and server.</p></remark>
+  </revision>
   <revision>
     <version>0.3</version>
     <date>2007-05-07</date>
@@ -55,7 +61,7 @@
   <p>The XMPP ping protocol is extremely simple:</p>
   <ol>
     <li>The pinging entity sends an IQ-get containing a &lt;ping/&gt; element qualified by the 'http://www.xmpp.org/extensions/xep-0199.html#ns' namespace &NSNOTE;.</li>
-    <li>The pinged entity returns either an IQ-result (if it supports the namespace) or an IQ-error (if it does not). (See the <link url='#security'>Security Considerations</link> regarding leaks of presence information in the context of pings sent to clients.)</li>
+    <li>The pinged entity returns either an IQ-result (if it supports the namespace) or an IQ-error (if it does not).</li>
   </ol>
 </section1>
 <section1 topic='Use Cases' anchor='usecases'>
@@ -195,7 +201,7 @@
   <example caption="Service Discovery information request"><![CDATA[
 <iq type='get'
     from='juliet@capulet.lit/balcony'
-    from='capulet.lit'
+    to='capulet.lit'
     id='disco1'>
   <query xmlns='http://jabber.org/protocol/disco#info'/>
 </iq>
@@ -214,7 +220,7 @@
   ]]></example>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
-  <p>A pinged entity MAY ignore the IQ (i.e., return neither a result nor an error) if doing so would reveal its presence (network availability) information to an entity that is not authorized to view that information; this mainly applies to pings sent to clients (where the response would reveal client availability) but may apply to other entities as well.</p>
+  <p>If a server receives a ping request directed to a full JID (&FULLJID;) associated with a registered account but there is no connected resource matching the 'to' address, it MUST reply with a &unavailable; error and set the 'from' address of the IQ-error to the full JID provided in the 'to' address of the ping request. If a connected resource receives a ping request but it does not want to reveal its network availability to the sender for any reason (e.g., because the sender is not authorized to know the connected resource's availability), then it too MUST reply with a &unavailable; error. This consistency between the server response and the client response helps to prevent presence leaks.</p>
 </section1>
 
 <section1 topic='IANA Considerations' anchor='iana'>