0.2

xep-0276.xml

@@ -6,11 +6,11 @@
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
 <xep>
 <header>
-  <title>Temporary Presence Sharing</title>
+  <title>Presence Decloaking</title>
   <abstract>This specification defines an XMPP protocol extension that enables a user to send directed presence with a request for the target to also share presence information for the duration of a communications session.</abstract>
   &LEGALNOTICE;
   <number>0276</number>
-  <status>Deferred</status>
+  <status>Experimental</status>
   <type>Standards Track</type>
   <sig>None</sig>
   <approver>Council</approver>
@@ -26,6 +26,12 @@
   </author>
   &stpeter;
   &robmcqueen;
+  <revision>
+    <version>0.2</version>
+    <date>2012-07-11</date>
+    <initials>psa</initials>
+    <remark><p>Back by popular demand; also changed namespace to decloak (again).</p></remark>
+  </revision>
   <revision>
     <version>0.1</version>
     <date>2010-01-26</date>
@@ -45,13 +51,14 @@
     <remark><p>First draft.</p></remark>
   </revision>
 </header>
+
 <section1 topic='Introduction' anchor='intro'>
 
-  <p>Various XMPP extensions, such as &xep0166;, require additional support from clients, advertised in presence via &xep0115;, or require that IQ stanzas are sent to a particular resource. For instance, Jingle calls can be made only by sending an IQ to a particular resource. However, two parties who wish to communicate do not always shared presence information and therefore cannot use entity capabilities to determine the correct resource (full JID) for communication. Indeed, one of the parties might not even use XMPP: e.g., a remote user on the other side of a gateway to a network based on the Session Initiation Protocol (SIP; &rfc3261;) or to the Public Switched Telephone Network (PSTN). It would be helpful if a user could make a call through such a gateway by typing the SIP URI or telephone number of an arbitrary contact, without first exchanging presence.</p>
+  <p>Various XMPP extensions, such as &xep0166;, require additional support from clients, advertised in presence via &xep0115;, or require that IQ stanzas are sent to a particular resource. For instance, Jingle calls can be made only by sending an IQ to a particular resource. However, two parties who wish to communicate do not always share presence information through subscriptions and therefore cannot use entity capabilities to determine the proper full JID for communication. Indeed, one of the parties might not even use XMPP: e.g., a remote user on the other side of a gateway to a network based on the Session Initiation Protocol (SIP; &rfc3261;) or to the Public Switched Telephone Network (PSTN). It would be helpful if a user could make a call through such a gateway by typing the SIP URI or telephone number of an arbitrary contact, without first exchanging presence.</p>
 
-  <p>This document defines an XML protocol extension that enables two parties to temporarily share presence with each other through an intentional presence leak.</p>
+  <p>&rfc6121; already defines a way to send directed presence to another entity. This document supplements RFC 6121 by defining an XML protocol extension enabling two parties to explicitly share presence with each other on a temporary basis through an "intentional presence leak"; we call this "decloaking".</p>
 
-  <p>Note: This protocol has already been implemented using an XML namespace of "http://telepathy.freedesktop.org/xmpp/protocol/decloak" but the &REGISTRAR; was requested to issue the XMPP URN "urn:xmpp:temppres:0" upon publication of this proposal in the &xep0001; series.</p>
+  <p>Note: This protocol has already been implemented using an XML namespace of "http://telepathy.freedesktop.org/xmpp/protocol/decloak" but the &REGISTRAR; was requested to issue the XMPP URN "urn:xmpp:decloak:0" upon publication of this proposal in the &xep0001; series.</p>
 
 </section1>
 
@@ -65,9 +72,9 @@
 
 <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;temppres xmlns='urn:xmpp:temppres: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='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>Although the &lt;temppres/&gt; 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 presence sharing.</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>
 
 </section1>
 
@@ -96,13 +103,13 @@
 </presence>
   ]]></example>
 
-  <p>Juliet requests that Tybalt divulges his availability and capabilities, by sending directed presence to his bare JID &lt;tybalt@shakespeare.lit&gt;, where the presence stanza contains a &lt;temppres/&gt; element.</p>
+  <p>Juliet requests that Tybalt divulge his availability and capabilities, by sending directed presence to his bare JID &lt;tybalt@shakespeare.lit&gt;, where the presence stanza contains a &lt;decloak/&gt; element.</p>
 
   <example caption="Requesting that a peer share session presence"><![CDATA[
 <presence from='juliet@shakespeare.lit/balcony'
           to='tybalt@shakespeare.lit'>
   <c ver='juliet-caps-hash' .../>
-  <temppres xmlns='urn:xmpp:temppres:0' reason='media'/>
+  <decloak xmlns='urn:xmpp:decloak:0' reason='media'/>
 </presence>
   ]]></example>
 
@@ -123,7 +130,7 @@
 
   <p>Once Juliet has received the session presence from Tybalt, if necessary she can perform service discovery to find out the meaning of the entity capabilities hashes (if unknown), then proceed to make a Jingle call, initiate a file transfer, or complete some other use case.</p>
 
-  <p>Alternatively, Tybalt MAY ignore the request (in particular, this will happen for any resource that does not implement this specification).</p>
+  <p>Naturally, it's also possible that Tybalt's client will ignore the request (in particular, this will happen for any resource that does not implement this specification). However, in this case the parties are no worse off than they were before Juliet requested decloaking.</p>
 
 </section1>
 
@@ -131,14 +138,14 @@
 
   <p>Let us now suppose that Juliet wishes to make a media call to Romeo, who does not use XMPP but who has a SIP URI of sip:romeo@shakespeare.lit, which can be called via an XMPP-to-SIP gateway.</p>
 
-  <p>Juliet requests that the SIP contact representing Romeo on the gateway shall divulge its availability and capabilities, by sending directed presence to its bare JID at the gateway containing a &lt;temppres/&gt; element.</p>
+  <p>Juliet requests that the SIP contact representing Romeo on the gateway shall divulge its availability and capabilities, by sending directed presence to its bare JID at the gateway containing a &lt;decloak/&gt; element.</p>
 
   <example caption="Requesting that a gateway contact shall share session presence">
     <![CDATA[
 <presence from='juliet@shakespeare.lit/balcony'
           to='romeo%shakespeare.lit@sip.shakespeare.lit'>
   <c ver='juliet-caps-hash' .../>
-  <temppres xmlns='urn:xmpp:temppres:0' reason='media'/>
+  <decloak xmlns='urn:xmpp:decloak:0' reason='media'/>
 </presence>
   ]]></example>
 
@@ -157,7 +164,7 @@
 </section1>
 
 <section1 topic='The reason Attibute' anchor='reason'>
-  <p>To signal the type of communication that is desired, the entity that first shares session presence MAY include a 'reason' attribute on the &lt;temppres/&gt; element. The following values for the 'reason' attribute are defined:</p>
+  <p>To signal the type of communication that is desired, the entity that first shares session presence MAY include a 'reason' attribute on the &lt;decloak/&gt; element. The following values for the 'reason' attribute are defined:</p>
 
   <dl>
     <dt>media</dt>
@@ -165,7 +172,7 @@
 
     <dt>text</dt>
 
-    <dd>Presence is requested for a plaintext or &xep0071; conversation, e.g. with end-to-end encryption (which requires capabilities to be disclosed).</dd>
+    <dd>Presence is requested for a textual conversation using an extension that requires capabilities to be disclosed, such as &xep0071;, &xep0085;, &xep0301;, or end-to-end encryption.</dd>
 
     <dt>file</dt>
     <dd>Presence is requested for one or more file transfers, e.g. via &xep0234; or &xep0095;.</dd>
@@ -181,14 +188,14 @@
   
   <ol>
     <li><p>The initiating entity cannot know which of the receiving entity's resources is more likely to engage in communication. This might imply that the initiating entity will need to send a session initiation request or other communication to more than one of the receiving entity's resources (and then retract the session initiation requests that are not answered by the receiving entity). Solutions to that problem are out of scope for this specification.</p></li>
-    <li><p>Set up of a session might be delayed (e.g., because in Jingle it is desirable to start negotiating candidates as soon as possible but a user interface that prompts the receiving entity to explicitly approve of divulging presence will tend to delay call setup). As a result, it may be advantageous to have a way to configure unconditional sharing of session presence in certain deployments, at least within the same trust domain.</p></li>
+    <li><p>Establishment of a session might be delayed (e.g., because in Jingle it is desirable to start negotiating candidates as soon as possible but a user interface that prompts the receiving entity to explicitly approve of divulging presence will tend to a delay in call setup). As a result, it may be advantageous to have a way to configure unconditional sharing of session presence in certain deployments, at least within the same trust domain.</p></li>
   </ol>
 
 </section1>
 
 <section1 topic='Security Considerations' anchor='security'>
 
-  <p>Because sharing of session presence is a presence leak (albeit intentional), an XMPP client that implements the receiving side of this specification MUST disable sharing of session presence by default and MUST enable the feature only as a result of explicit user configuration. (Gateways and other non-user entities MAY divulge their own presence and capabilities unconditionally, if that is appropriate for the service policy at the gateway.)</p>
+  <p>Because decloaking is a presence leak (albeit intentional), an XMPP client that implements the receiving side of this specification MUST disable sharing of session presence by default and MUST enable the feature only as a result of explicit user configuration. (Gateways and other non-user entities MAY divulge their own presence and capabilities unconditionally, if that is appropriate for the service policy at the gateway.)</p>
 
 </section1>
 
@@ -197,18 +204,18 @@
 </section1>
 
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
-  <p>The XMPP Registrar is requested to issue an initial namespace of "urn:xmpp:temppres:0".</p>
+  <p>The XMPP Registrar is requested to issue an initial namespace of "urn:xmpp:decloak:0".</p>
 </section1>
 
 <section1 topic='XML Schema' anchor='schema'>
   <code><![CDATA[
 <xs:schema
   xmlns:xs='http://www.w3.org/2001/XMLSchema'
-  targetNamespace='urn:xmpp:temppres:0'
+  targetNamespace='urn:xmpp:decloak:0'
-  xmlns='urn:xmpp:temppres:0'
+  xmlns='urn:xmpp:decloak:0'
   elementFormDefault='qualified'>
 
-  <xs:element name='temppres'>
+  <xs:element name='decloak'>
     <xs:complexType>
       <xs:simpleContent>
         <xs:extension base='empty'>