mirror of https://github.com/moparisthebest/xeps
inbox proposals from Tobian Markmann
This commit is contained in:
Peter Saint-Andre
parent
59ca20b09f
commit
732ca534f3
|
|
@ -0,0 +1,71 @@
|
|||
<?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>Last Presence using Delayed Delivery</title>
|
||||
<abstract>This specification defines a way to determine the time when a XMPP entity has last changed its presence.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>XXXX</number>
|
||||
<status>ProtoXEP</status>
|
||||
<type>Informational</type>
|
||||
<sig>Standards</sig>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XMPP IM</spec>
|
||||
<spec>XEP-0203</spec>
|
||||
</dependencies>
|
||||
<supersedes>
|
||||
<xep>XEP-0012</xep>
|
||||
</supersedes>
|
||||
<supersededby/>
|
||||
<shortname>last-presence</shortname>
|
||||
&tobias;
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2013-02-20</date>
|
||||
<initials>tobias</initials>
|
||||
<remark><p>Initial version.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>This protocol describes a way to communicate time of last presence change with other XMPP entities over presence stanzas. This is done extending presence stanzas with delayed delivery information according to &xep0203; and can be used to determine the time of last presence change for XMPP entities includeing servers. For users on the same server, the server also adds delyed delivery information to the presence responses.</p>
|
||||
<p>The time of the delayed delivery information attatched to the presence indicates the time a XMPP entity has last changed to this presence.</p>
|
||||
</section1>
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
<section2 topic='Last Presence of a XMPP Entity' anchor='case-xmpp-entity'>
|
||||
<p>This section describes how to determine the time a user when offline or, in general, changed to her current presence state. This is merly a description since the protocol is already described in &rfc6121;, section 4.3.2.</p>
|
||||
<p>The following example show a possible incoming presence in response to going online by sending your own available presence.</p>
|
||||
<example caption='Incoming Presence with Delayed Delivery'><![CDATA[
|
||||
<presence from='romeo@montague.com/kitchen' to='juliet@capulet.com/balcony' type'unavailable'>
|
||||
<delay xmlns='urn:xmpp:delay' stamp='2002-09-10T23:41:07Z'/>
|
||||
</presence>]]></example>
|
||||
</section2>
|
||||
<section2 topic='Uptime Reporting of Servers and Components' anchor='case-uptime-report'>
|
||||
<p>Reqesting the uptime of a server or component is done by sending a directed presence probe to the XMPP entity of interest. The request is shown in the following example.</p>
|
||||
<example caption='Request for Uptime Reporting using Presence Probe'><![CDATA[
|
||||
<presence from='juliet@capulet.com/balcony' to='montague.com' type='probe' />]]></example>
|
||||
<p>The server or component then responds with an available presence, extended with delayed delivery information, according to &xep0203;, indicating its startup time. This is shown below:</p>
|
||||
<example caption='Response to the Presence Probe'><![CDATA[
|
||||
<presence from='montague.com' to='juliet@capulet.com/balcony'>
|
||||
<delay xmlns='urn:xmpp:delay' stamp='2002-09-10T23:41:07Z'/>
|
||||
</presence>]]></example>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to Kim Alvefur and Lance Stout for their helpful comments.</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>Adding delayed delivery notation to the presence probe responses exposes information a user might not expect to have exposed. However the information about last presence change is known to all entities subscribed to one's presence which are online. This extension just provides this information to XMPP entities which have been offline during the course of presence change.</p>
|
||||
<p>It's worth to note that the security considerations of &xep0082; apply here.</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 the ®ISTRAR;.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
<?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>Last User Interaction in Presence</title>
|
||||
<abstract>This specification defines a way to communicate time of last user interaction with her system using XMPP presence notifications.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>XXXX</number>
|
||||
<status>ProtoXEP</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XMPP IM</spec>
|
||||
<spec>XEP-0082</spec>
|
||||
</dependencies>
|
||||
<supersedes>
|
||||
<xep>XEP-0256</xep>
|
||||
</supersedes>
|
||||
<supersededby/>
|
||||
<shortname>idle</shortname>
|
||||
&tobias;
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2013-02-17</date>
|
||||
<initials>tobias</initials>
|
||||
<remark><p>Initial version.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>This protocol describes a way to communicate time of last user interaction with other XMPP entities over presence stanzas. User interaction refers to a human end user interacting with her device by means of keyboard, mouse, touch and so on. Based on this information XMPP clients can display the time a contact went idle or how for how long a contact has been idle. Thereby end users can get a hunch on the expected responsiveness of their contacts.</p>
|
||||
<p>The described protocol uses absolute timestamps indicated as value of the 'since'-attribute in the <![CDATA[<idle>]]>-tag. The time, represented in the 'since'-attribute, is to be formatted according to &xep0082;.</p>
|
||||
</section1>
|
||||
<section1 topic='Use Cases' anchor='usecases'>
|
||||
Generally there are two main use cases for this extension explained in more detail in the following sections.
|
||||
<section2 topic='Presence with Last Interaction' anchor='last-interact'>
|
||||
<p>After a user has not interacted with her device for some amount of time the user wants to inform her contacts about this fact. For this the client sends a presence stanza with time of last interaction.</p>
|
||||
<example caption='Time of Last User Interaction in Auto-Away'><![CDATA[
|
||||
<presence from='juliet@capulet.com/balcony'>
|
||||
<show>away</show>
|
||||
<idle xmlns='urn:xmpp:idle:1' since='1969-07-21T02:56:15Z'/>
|
||||
</presence>
|
||||
]]></example>
|
||||
<p>The amount of time after a client sends this enhanced presence is not set in stone but 5 minutes is suggested as a sensible default value.</p>
|
||||
</section2>
|
||||
|
||||
<section2 topic='Presence Indicating User Coming Back From Idle' anchor='back-from-idle'>
|
||||
The moment a user comes back and uses her device again the client can inform user's contacts by sending a normal presence stanza like shown in the following example.
|
||||
<example caption='Presence Indicating Return to Device'><![CDATA[
|
||||
<presence from='juliet@capulet.com/balcony'>
|
||||
<show>available</show>
|
||||
</presence>
|
||||
]]></example>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>Including a last user interaction notation in presence notifications can enable those who receive such notifications to determine exactly when a user has stopped interacting with his or her XMPP client or even their system, but this information is in essence already available if the user publishes timely presence updates. Therefore, this specification introduces no new vulnerabilities.</p>
|
||||
<p>It's worth to note that the security considerations of &xep0082; apply here.</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 the ®ISTRAR;.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
Loading…
Reference in New Issue