mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
XEP-0319 -- fix typos, added clarifications and added acks section
This commit is contained in:
parent
e46ad7b3f4
commit
1295e8b25c
13
xep-0319.xml
13
xep-0319.xml
@ -51,11 +51,11 @@
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>This protocol describes a way to communicate a user's last interaction time with other XMPP entities over &PRESENCE; stanzas. For the purposes of this document, user interaction here refers to a human end user interacting with her device by means of a keyboard, mouse, touch screen, and so on. Based on this information XMPP clients can display the time a contact went idle or how a duration for who long a contact has been idle, thereby allowing end users to estimate the expected responsiveness of their contacts.</p>
|
||||
<p>This protocol describes a way to communicate a user's last interaction time with other XMPP entities over &PRESENCE; stanzas. For the purposes of this document, user interaction here refers to a human end user interacting with her device by means of a keyboard, mouse, touch screen, and so on. Based on this information XMPP clients can display the time a contact went idle or a duration for how long a contact has been idle, thereby allowing end users to estimate the expected responsiveness of their contacts.</p>
|
||||
<p>This protocol uses absolute timestamps formatted according to &xep0082;, indicated as value of the 'since' attribute in the <idle/> element.</p>
|
||||
<p>Experience has shown a number of issues with &xep0256;:</p>
|
||||
<ul>
|
||||
<li>The use of relative durations is too vague.</li>
|
||||
<li>The use of relative durations is too vague. It requires additional information from &xep0203; to provide a reliable user experience.</li>
|
||||
<li>Distinguishing between the idle and last online use cases is very difficult.</li>
|
||||
<li>It is desirable to have idle time indiciated for &PRESENCE; <show/> values other than "away" and "xa".</li>
|
||||
</ul>
|
||||
@ -71,18 +71,21 @@
|
||||
<idle xmlns='urn:xmpp:idle:1' since='1969-07-21T02:56:15Z'/>
|
||||
</presence>
|
||||
]]></example>
|
||||
<p>The amount of time the user has been idle before a client sends this enhanced presence application-specific; it is suggested that a sensible default interval of 5 minutes be used.</p>
|
||||
<p>The amount of time the user has to be idle before a client sends this enhanced presence is application-specific; it is suggested that a sensible default interval of 5 minutes be used.</p>
|
||||
</section2>
|
||||
<section2 topic='Presence Indicating User Coming Back From Idle' anchor='back-from-idle'>
|
||||
When a user comes back and uses her device again the client can informs user's contacts by sending a normal presence stanza like shown in the following example, omiting the <idle/> element.
|
||||
When a user comes back and uses her device again the client informs user's contacts by sending a normal presence stanza like shown in the following example, omiting the <idle/> element.
|
||||
<example caption='Presence Indicating Return to Device'><![CDATA[
|
||||
<presence from='juliet@capulet.com/balcony' />
|
||||
]]></example>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Acknowledgements' anchor='ack'>
|
||||
<p>Thanks to Florian Schmaus, Christian Schudt, and Lance Stout for their helpful comments.</p>
|
||||
</section1>
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>The security considerations of <cite>XEP-0082</cite> apply to this protocol.</p>
|
||||
<p>this specification introduces no new security or privacy concerns. While including a last user interaction notation in &PRESENCE; updates can enable recipients to determine exactly when a user has stopped interacting with his or her XMPP client or even their system, this information is in essence already available if the user's client publishes timely presence updates.</p>
|
||||
<p>This specification introduces no new security or privacy concerns. While including a last user interaction notation in &PRESENCE; updates can enable recipients to determine exactly when a user has stopped interacting with her XMPP client or even their system, this information is in essence already available if the user's client publishes timely presence updates.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
|
Loading…
Reference in New Issue
Block a user