moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-22 01:02:17 -05:00
Code Issues Releases Wiki Activity

0.4

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@856 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-05-22 15:00:26 +00:00
parent c342482a25
commit 67be001a36
1 changed files with 9 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
xep-0199.xml
View File

@ -21,6 +21,12 @@
<supersededby/> <supersededby/>
<shortname>TO BE ASSIGNED</shortname> <shortname>TO BE ASSIGNED</shortname>
&stpeter; &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> <revision>
<version>0.3</version> <version>0.3</version>
<date>2007-05-07</date> <date>2007-05-07</date>
@ -55,7 +61,7 @@
<p>The XMPP ping protocol is extremely simple:</p> <p>The XMPP ping protocol is extremely simple:</p>
<ol> <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 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> </ol>
</section1> </section1>
<section1 topic='Use Cases' anchor='usecases'> <section1 topic='Use Cases' anchor='usecases'>
@ -195,7 +201,7 @@
<example caption="Service Discovery information request"><![CDATA[ <example caption="Service Discovery information request"><![CDATA[
<iq type='get' <iq type='get'
from='juliet@capulet.lit/balcony' from='juliet@capulet.lit/balcony'
from='capulet.lit' to='capulet.lit'
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
@ -214,7 +220,7 @@
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <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>
<section1 topic='IANA Considerations' anchor='iana'> <section1 topic='IANA Considerations' anchor='iana'>