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

spacing

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1784 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-04-18 16:51:57 +00:00
parent b6f8be2206
commit 3ee3bdc2c7
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
xep-0199.xml
View File

@ -16,6 +16,7 @@
<approver>Council</approver> <approver>Council</approver>
<dependencies> <dependencies>
<spec>XMPP Core</spec> <spec>XMPP Core</spec>
<spec>XEP-0030</spec>
</dependencies> </dependencies>
<supersedes/> <supersedes/>
<supersededby/> <supersededby/>
@ -61,9 +62,11 @@
<remark><p>Initial version.</p></remark> <remark><p>Initial version.</p></remark>
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p>As specified in &rfc3920;, the XML streams used in XMPP are bound to TCP. Unfortunately, TCP connections can go down without the application (XMPP) layer knowing about it. The traditional approach to solving this issue has been to periodically send so-called "whitespace pings" over the XML stream. This document recommends a more XML-friendly approach, which can be used over more than one hop in the communication path (e.g., from one client to another) and can also be used with other bindings such as the &xep0124; method for which &xep0206; is the XMPP profile.</p> <p>As specified in &rfc3920;, the XML streams used in XMPP are bound to TCP. Unfortunately, TCP connections can go down without the application (XMPP) layer knowing about it. The traditional approach to solving this issue has been to periodically send so-called "whitespace pings" over the XML stream. This document recommends a more XML-friendly approach, which can be used over more than one hop in the communication path (e.g., from one client to another) and can also be used with other bindings such as the &xep0124; method for which &xep0206; is the XMPP profile.</p>
</section1> </section1>
<section1 topic='Requirements' anchor='reqs'> <section1 topic='Requirements' anchor='reqs'>
<p>This specification addresses the following requirements:</p> <p>This specification addresses the following requirements:</p>
<ol start='1'> <ol start='1'>
@ -72,6 +75,7 @@
</ol> </ol>
<p>The number of "hops" for which the ping tests connectivity depends on how far the pinged entity is from the pinging entity, as shown in the following use cases. However, this specification does not provide per-hop information similar to that provided by the traceroute protocol (&rfc1393;); a future specification may define such functionality for XMPP.</p> <p>The number of "hops" for which the ping tests connectivity depends on how far the pinged entity is from the pinging entity, as shown in the following use cases. However, this specification does not provide per-hop information similar to that provided by the traceroute protocol (&rfc1393;); a future specification may define such functionality for XMPP.</p>
</section1> </section1>
<section1 topic='Protocol' anchor='protocol'> <section1 topic='Protocol' anchor='protocol'>
<p>The XMPP ping protocol is extremely simple:</p> <p>The XMPP ping protocol is extremely simple:</p>
<ol> <ol>
@ -214,7 +218,7 @@
</section1> </section1>
<section1 topic='Discovering Support' anchor='disco'> <section1 topic='Discovering Support' anchor='disco'>
<p>If an entity supports the XMPP Ping protocol, it MUST report that by including a service discovery feature of "urn:xmpp:ping" in response to a &xep0030; information request:</p> <p>If an entity supports the XMPP Ping protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:ping" in response to a &xep0030; information request:</p>
<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'
@ -236,6 +240,7 @@
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<p>If a server receives a ping request directed to a full JID &LOCALFULL; 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> <p>If a server receives a ping request directed to a full JID &LOCALFULL; 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>