From 7c1bc5571761f4fae26b499d9e921487f5505203 Mon Sep 17 00:00:00 2001 From: "Matthew A. Miller" Date: Fri, 20 Jun 2014 09:10:42 -0600 Subject: [PATCH] fixing a typo --- xep-0276.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xep-0276.xml b/xep-0276.xml index 48dd1406..ea71db26 100644 --- a/xep-0276.xml +++ b/xep-0276.xml @@ -78,7 +78,7 @@ -

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 <decloak xmlns='urn:xmpp:decloak:0'/>. 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 <presence type='uavailable'/> 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;.

+

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 <decloak xmlns='urn:xmpp:decloak:0'/>. 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 <presence type='unavailable'/> 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;.

Although the <decloak/> 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.