-
Notifications
You must be signed in to change notification settings - Fork 0
/
xep-0018.xml
138 lines (136 loc) · 11 KB
/
xep-0018.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Invisible Presence</title>
<abstract>Documentation of invisible presence.</abstract>
&LEGALNOTICE;
<number>0018</number>
<status>Rejected</status>
<type>Informational</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
<author>
<firstname>Ben</firstname>
<surname>Schumacher</surname>
<email>ben@blahr.com</email>
<jid>rynok@jabber.com</jid>
</author>
<author>
<firstname>Jeremie</firstname>
<surname>Miller</surname>
<email>jer@jabber.org</email>
<jid>jer@jabber.org</jid>
</author>
<revision>
<version>0.2</version>
<date>2003-09-26</date>
<initials>bs</initials>
<remark>Updated to focus solely on <presence type='invisible'/>.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2002-01-28</date>
<initials>jmm</initials>
<remark>Initial draft.</remark>
</revision>
</header>
<section1 topic="Introduction">
<p>Jabber users have long wanted the ability to come online using Jabber, but appear "unavailable" to a subset of their roster, an ability which is commonly referred to as invisible mode. While several current implementations have various ways of providing this functionality, the systems currently in place often lack clear behavior and documentation. This document provides requirements for invisible mode and clarifies the existing protocol-in-use to provide the desired functionality.</p>
<p><strong>Note well:</strong> The functionality described herein can and should be implemented by means of the Privacy Rules namespace defined in &xmppim;. This document is provided for historical purposes only.</p>
</section1>
<section1 topic="Requirements">
<p>The requirements for invisible mode are basic:</p>
<ol>
<li>A user should be able to become visible or invisible at any time.</li>
<li>When in either mode, users should be able to selectively allow or block presence updates to be distributed to their contacts.</li>
</ol>
</section1>
<section1 topic="Use Cases">
<p>For the purposes of this discussion, we will assume this terminology.</p>
<ul>
<li>Undirected Presence - A presence stanza without a "to" attribute.</li>
<li>Directed Presence - A presence stanza with a "to" attribute.</li>
</ul>
<section2 topic="User Becomes Invisible to All Contacts">
<p>Assuming the user's client has authenticated with the system normally, it would send the following presence stanza to become invisible (note: this can be the initial presence stanza sent by the user). To do so, the client will send undirected presence with a type="invisible" attribute.</p>
<example caption="Invisible presence stanza"><![CDATA[<presence type="invisible"/>]]></example>
</section2>
<section2 topic="User Becomes Visible to All Contacts">
<p>If a user chooses to become visible after being invisible, the client will send undirected presence with a type="visible" attribute.</p>
<example caption="Visible presence stanza"><![CDATA[<presence type="visible"/>]]></example>
</section2>
<section2 topic="User Becomes Invisible to Selected Contact">
<p>If a user is visible to all of their contacts, and wishes to become invisible to selected contacts on their roster, then their client will send the following directed presence stanza.</p>
<example caption="User becomes invisible to joe@foo.com"><![CDATA[<presence to="joe@foo.com" type="invisible"/>]]></example>
<p>In this case, the server begins to track that the user is invisible to the contact joe@foo.com, and does not forward further presence updates to joe@foo.com. If the user wishes joe@foo.com to received further presence updates, then their client must send either an undirected presence stanza with a type="visible" attribute (see Example 2), or a directed presence stanza to joe@foo.com with a type="visible" attribute as below.</p>
<example caption="User becomes visible to joe@foo.com"><![CDATA[<presence to="joe@foo.com" type="visible"/>]]></example>
</section2>
<section2 topic="User Becomes Visible to Selected Contact">
<p>The opposite behavior of the previous section should, also, be present in the server. For example, if a user is invisible to all of their contacts, they should be able to become visible to a selected contact by send a stanza similar to the one in Example 4.</p>
<p>As with the previous section, a user can later choose to hide his presence updates for joe@foo.com by either sending an undirected presence stanza (see Example 1), or by sending a directed presence stanza to joe@foo.com (see Example 3).</p>
</section2>
</section1>
<section1 topic="Server Implementation Details">
<p>The above section documents the major points of the invisible mode protocol. It is important to understand how the server should interact with the protocol documented above.</p>
<p>Normally, when a server receives a presence stanza, it stamps the appropriate 'from' attribute on the stanza and sends it on its way. If the stanza does not possess a 'to' attribute, the process of sending the stanza on its way involves broadcasting that stanza to all contacts listed in the user's roster. If the stanza does have a 'to' attribute, the stanza is simply routed to the correct contact. With the addition of invisible mode presence, the server MUST now verify that a stanza should be directed to contacts on a user's roster before sending it on. In addition, stanzas that are directly related to invisible presence (stanzas with a 'type' attribute of either "visible" or "invisible") MUST NOT be sent to any contacts, but MAY cause other presence stanzas to be sent instead.</p>
<section2 topic="Undirected Presence While Invisible to Selected Contacts">
<p>One of the biggest failings of older invisible mode implementations were client features like auto-away. In most cases, these auto-away stanza would inadvertently cause a user to become visible (although away) to all contacts on its roster. This invisible presence protocol has been designed to deal with that problem elegantly.</p>
<p>Consider the following situation (the protocol for which is shown in the examples below):</p>
<ol>
<li>joe@foo.com has contacts stpeter@foo.com, pgmillard@foo.com and rynok@foo.com on his roster.</li>
<li>joe@foo.com has logged into the foo.com sever, but has set his presence to invisible.</li>
<li>Assume that stpeter@foo.com, pgmillard@foo.com and rynok@foo.com are all online and visible.</li>
<li>joe@foo.com wants rynok@foo.com to see his presence updates, but not stpeter@foo.com or pgmillard@foo.com</li>
<li>joe@foo.com sets his presence to extended away.</li>
<li>joe@foo.com decides to become visible to all contacts on his roster.</li>
<li>joe@foo.com decides to become invisible to pgmillard@foo.com.</li>
<li>joe@foo.com set his presence to free to chat.</li>
</ol>
<example caption="joe@foo.com sends initial presence stanza"><![CDATA[<presence type="invisible"/>]]></example>
<p>Since joe@foo.com has just come online, the server SHOULD NOT forward any presence stanzas to contacts on his roster.</p>
<example caption="joe@foo.com sends visible presence to rynok@foo.com"><![CDATA[<presence to="rynok@foo.com" type="visible"/>]]></example>
<example caption="Server forwards presence update to rynok@foo.com"><![CDATA[<presence from="joe@foo.com/resource" to="rynok@foo.com"/>]]></example>
<example caption="joe@foo.com sets his presence to extended away"><![CDATA[<presence><show>xa</show><status>Away (due to idle)</status></presence>]]></example>
<example caption="Server forwards presence update to rynok@foo.com"><![CDATA[<presence from="joe@foo.com/resource" to="rynok@foo.com">
<show>away</show><status>Meeting</status>
</presence>]]></example>
<p>Note that in this example, presence updates from joe@foo.com are routed only to rynok@foo.com, despite the fact that stpeter@foo.com and pgmillard@foo.com are both online and available. This is because joe@foo.com has chosen to be visible only to rynok@foo.com. If joe@foo.com chooses to become visible to his entire roster, he simply sends an undirected presence stanza with the type="visible" attribute. In this case the server SHOULD forward the last undirected presence stanza received to stpeter@foo.com and pgmillard@foo.com.</p>
<example caption="joe@foo.com sends undirected visible stanza"><![CDATA[<presence type="visible"/>]]></example>
<example caption="Server forwards last presence update to stpeter@foo.com and pgmillard@foo.com"><![CDATA[<presence from="joe@foo.com/resource" to="stpeter@foo.com"/>
<presence from="joe@foo.com/resource" to="pgmillard@foo.com"/>]]></example>
<p>Now Joe has decided that he doesn't want pgmillard@foo.com to receive further presence updates. Since he is currently visible to all contacts, he simply needs to send a directed presence stanza to pgmillard@foo.com with the type="invisible" attribute set.</p>
<example caption="joe@foo.com sends directed presence stanza to pgmillard@foo.com"><![CDATA[<presence to="pgmillard@foo.com" type="invisible"/>]]></example>
<p>In this case, the server will send a directed presence stanza to pgmillard@foo.com with the type="unavailable" attribute set, which indicates to pgmillard@foo.com's client that joe@foo.com has gone "offline."</p>
<example caption="Server sends unavailable presence stanza to pgmillard@foo.com"><![CDATA[<presence from="joe@foo.com/resource" to="pgmillard@foo.com" type="unavailable"/>]]></example>
<p>Further presence updates sent by joe@foo.com will now be forwarded to stpeter@foo.com and rynok@foo.com, and MUST NOT be forwarded pgmillard@foo.com.</p>
<example caption="joe@foo.com set his presence to free to chat"><![CDATA[<presence><show>chat</show></presence>]]></example>
<example caption="Server forwards presence update to stpeter@foo.com and rynok@foo.com"><![CDATA[<presence from="joe@foo.com/resource" to="stpeter@foo.com">
<show>chat</show>
</presence>
<presence from="joe@foo.com/resource" to="rynok@foo.com/resource">
<show>chat</show>
</presence>]]></example>
<p>The server MUST NOT forward presence stanzas containing the type="visible" or type="invisible" attribute to a client.</p>
</section2>
</section1>
<section1 topic="Security Considerations">
<p>There are no security features or concerns related to this proposal.</p>
</section1>
<section1 topic="IANA Considerations">
<p>No interaction with &IANA; is required as a result of this document.</p>
</section1>
<section1 topic="XMPP Registrar Considerations">
<p>No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this document.</p>
</section1>
</xep>