mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 08:45:04 -05:00
ProtoXEP Client Station Notification v0.0.1
This commit is contained in:
Matthew A. Miller
parent
29e45b2e2a
commit
a2317a78cf
147
inbox/client-state-notification.xml
Normal file
147
inbox/client-state-notification.xml
Normal file
@ -0,0 +1,147 @@
|
||||
<?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>xxxx</number>
|
||||
<status>ProtoXEP</status>
|
||||
<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.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'/>
|
||||
</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' namespace:</p>
|
||||
<example caption='Client indicates it is inactive'><![CDATA[
|
||||
<inactive xmlns='urn:xmpp:csi'/>
|
||||
]]></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'/>
|
||||
]]></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'
|
||||
xmlns='urn:xmpp:csi'
|
||||
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>
|
||||
Loading…
Reference in New Issue
Block a user