fixing a typo

This commit is contained in:
Matthew A. Miller 2014-06-20 09:10:42 -06:00
parent e95d88f598
commit 7c1bc55717
1 changed files with 1 additions and 1 deletions

View File

@ -78,7 +78,7 @@
<section1 topic='Approach' anchor='approach'>
<p>The approach taken here is that the user who wishes to initiate presence sharing for the length of a communications session sends directed presence (including entity capabilities) to the bare JID &LOCALBARE; of the initiator's intended communication partner, including a special XMPP extension &lt;decloak xmlns='urn:xmpp:decloak:0'/&gt;. Upon receipt of this directed presence stanza, if configured to do so the recipient's sends directed presence (including entity capabilities) to the initiator's full JID &LOCALFULL;. Once the parties complete their communications session, they can terminate presence sharing by sending directed &lt;presence type='uavailable'/&gt; to each other; alternatively, at any time they could "upgrade" their session-based presence sharing to a full XMPP presence subscription as described in &xmppim;.</p>
<p>The approach taken here is that the user who wishes to initiate presence sharing for the length of a communications session sends directed presence (including entity capabilities) to the bare JID &LOCALBARE; of the initiator's intended communication partner, including a special XMPP extension &lt;decloak xmlns='urn:xmpp:decloak:0'/&gt;. Upon receipt of this directed presence stanza, if configured to do so the recipient's sends directed presence (including entity capabilities) to the initiator's full JID &LOCALFULL;. Once the parties complete their communications session, they can terminate presence sharing by sending directed &lt;presence type='unavailable'/&gt; to each other; alternatively, at any time they could "upgrade" their session-based presence sharing to a full XMPP presence subscription as described in &xmppim;.</p>
<p>Although the &lt;decloak/&gt; element could be sent in presence stanzas of type "subscribe" instead of in directed presence notifications, that behavior is discouraged because the "fall-through" case for subscription requests is a long-lived subscription, not temporary sharing of presence information for the life of a communication session.</p>