mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 18:22:24 -05:00
155 lines
6.9 KiB
XML
155 lines
6.9 KiB
XML
<?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>Client State Indication</title>
|
|
<abstract>This document defines a way for the client to indicate its active/inactive state.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0352</number>
|
|
<status>Proposed</status>
|
|
<lastcall>2015-09-07</lastcall>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>NOT_YET_ASSIGNED</shortname>
|
|
&mwild;
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2014-08-28</date>
|
|
<initials>XEP Editor (asw)</initials>
|
|
<remark><p>Initial published version approved by the XMPP Council.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2014-08-14</date>
|
|
<initials>mw</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>It is common for IM clients to be logged in and 'online' even while the user is not interacting with the application. This
|
|
protocol allows the client to indicate to the server when the user is not actively using the client, allowing the server to
|
|
optimise traffic to the client accordingly. This can save bandwidth and resources on both the client and server.</p>
|
|
</section1>
|
|
|
|
<section1 topic='Requirements' anchor='reqs'>
|
|
<p>The aim of this specification is to provide a simple and efficient protocol for the client to report its
|
|
state to the server. Exactly how the server uses this information is beyond the scope of this document, although
|
|
some examples are given.</p>
|
|
<p>Other extensions exist, such as &xep0273;, which also aim to optimise the traffic between the client and server.
|
|
A notable difference is that instead of being client-controlled, CSI shifts the responsibility to the server, and
|
|
aims to just provide the server with enough information to implement various optimisations itself.</p>
|
|
</section1>
|
|
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
<section2 topic='User and client behaviour' anchor='behaviour-user'>
|
|
<p>Juliet has an XMPP client on her phone, which is available to receive messages. However most of the time
|
|
Juliet has her phone screen turned off and is not interested in the status of her contacts unless they are
|
|
communicating with her.</p>
|
|
|
|
<p>Juliet's client informs the server when Juliet is not interacting with it. The server uses this information to
|
|
suppress or reduce stanzas that are unimportant, such as status updates.</p>
|
|
|
|
<p>When Juliet returns to her IM client, the client again informs the server, this time to report that it is active
|
|
again. The server then disables its traffic optimisations and restores the stream to its normal state.</p>
|
|
</section2>
|
|
<section2 topic="Server behaviour">
|
|
<p>When the server knows that the user is not engaging with their client many optimisations become possible. For
|
|
example a server could:</p>
|
|
<ul>
|
|
<li>Suppress presence updates until the client becomes active again. On becoming active, push the latest
|
|
presence from each contact.</li>
|
|
<li>Discard messages containing only &xep0085; payloads.</li>
|
|
<li>Defer or discard unimportant PEP notifications, possibly unsubscribe from certain PEP nodes
|
|
until the client becomes active again.</li>
|
|
</ul>
|
|
|
|
<p>This list is for example only, a server is not required to implement all or any of these, nor is it prevented
|
|
from implementing other behaviour not listed here. Regardless of what optimisations a server implements, it SHOULD
|
|
provide a way for administrators to configure them, and MAY provide such configuration to users also (e.g., through an
|
|
ad-hoc command).</p>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic="Protocol" anchor="protocol">
|
|
<section2 topic="Discovering support" anchor="discovery">
|
|
<p>If the server supports CSI, it advertises it in the stream features after the client has authenticated:</p>
|
|
<example caption='Server indicates support for CSI'><![CDATA[
|
|
<stream:features>
|
|
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
|
|
<csi xmlns='urn:xmpp:csi:0'/>
|
|
</stream:features>
|
|
]]></example>
|
|
</section2>
|
|
|
|
<section2 topic="Indicating state" anchor="indication">
|
|
<p>A stream always begins in 'active' state. If a client wishes to inform the server that it has become inactive,
|
|
it sends an <inactive/> element in the 'urn:xmpp:csi:0' namespace:</p>
|
|
<example caption='Client indicates it is inactive'><![CDATA[
|
|
<inactive xmlns='urn:xmpp:csi:0'/>
|
|
]]></example>
|
|
|
|
<p>As might be anticipated, when the client is active again it sends an <active/> element:</p>
|
|
<example caption='Client indicates it is active'><![CDATA[
|
|
<active xmlns='urn:xmpp:csi:0'/>
|
|
]]></example>
|
|
|
|
<p>There is no reply from the server to either of these elements (though they may indirectly cause the server to
|
|
send stanzas, e.g., to update presence information when the client becomes active after a period of inactivity).</p>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Business Rules' anchor='rules'>
|
|
<p>As this protocol is for indication only, clients MUST NOT make assumptions about how the server
|
|
will use the active/inactive state information.</p>
|
|
|
|
<p>The server MUST assume all clients to be in the 'active' state until the client indicates otherwise. Also the
|
|
CSI active/inactive state is unrelated to the user's presence, the server MUST treat the two independently.</p>
|
|
|
|
<p>This protocol is intended primarily for clients with human interaction. Due to the open-ended nature of
|
|
the possible optimisations implemented by the server, it may not be suitable for non-IM purposes where the
|
|
fully standard behaviour of XMPP is required.</p>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>To protect the privacy of users, servers MUST NOT reveal the clients active/inactive state to other
|
|
entities on the network.</p>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This document requires no interaction with &IANA;.</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<p>This document requires no interaction with ®ISTRAR;.</p>
|
|
</section1>
|
|
<section1 topic='XML Schema'>
|
|
<code><![CDATA[
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
|
|
<xs:schema
|
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
|
targetNamespace='urn:xmpp:csi:0'
|
|
xmlns='urn:xmpp:csi:0'
|
|
elementFormDefault='qualified'>
|
|
|
|
<xs:element name='csi' type='empty'/>
|
|
<xs:element name='active' type='empty'/>
|
|
<xs:element name='inactive' type='empty'/>
|
|
|
|
<xs:simpleType name='empty'>
|
|
<xs:restriction base='xs:string'>
|
|
<xs:enumeration value=''/>
|
|
</xs:restriction>
|
|
</xs:simpleType>
|
|
|
|
</xs:schema>
|
|
]]></code>
|
|
</section1>
|
|
</xep>
|