1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-13 21:05:09 -05:00
xeps/xep-0224.xml

155 lines
7.7 KiB
XML
Raw Normal View History

<?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>Attention</title>
<abstract>This document defines an XMPP protocol extension for getting the attention of another user.</abstract>
&LEGALNOTICE;
<number>0224</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0030</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT YET ASSIGNED</shortname>
<author>
<firstname>Andreas</firstname>
<surname>Monitzer</surname>
<email>andy@monitzer.com</email>
<jid>andy@monitzer.com</jid>
</author>
<revision>
<version>0.1</version>
<date>2007-08-08</date>
<initials>psa</initials>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2007-07-03</date>
<initials>am</initials>
<remark><p>Initial version.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Even though a client might be available (as stated in the most recent presence stanza) the user this client belongs to might not have the focus on the client currently. &xep0132; defines a method for a physical test of user presence. Since this requires special hardware that can not be assumed to be available, this XEP defines a software-only implementation where no direct feedback is expected. This is known as 'nudge' or 'buzz' in some legacy IM protocols.</p>
<p>It was discussed whether this should be part of &xep0085;. However, the semantics are inherently different, since it describes the sender's state, not a request to change the receiver's. Thus, a separate extension is desirable.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>The specification addresses remotely getting the user's attention in a more assertive way than simple text messages.</p>
</section1>
<section1 topic='Protocol' anchor='protocol'>
<p>In the following conversation, a user talks to somebody, but this user doesn't respond. The second inquiry includes an attention extension.</p>
<example caption="User sends a regular message"><![CDATA[
<message from='calvin@usrobots.lit/lab' to='herbie@usrobots.lit/home' type='chat'>
<body>All right, then, Herbie, give! We're waiting.</body>
</message>
]]></example>
<p>When no reply is received, the sending user might want to grab the other's attention. This is done by sending a message that includes an &lt;attention/&gt; element qualified by the 'http://www.xmpp.org/extensions/xep-0224.html#ns' namespace &NSNOTE;. Note: The message may or may not include a &BODY; element.</p>
<example caption="User tries to capture the other's attention"><![CDATA[
<message from='calvin@usrobots.lit/lab' to='herbie@usrobots.lit/home' type='headline'>
<attention xmlns='http://www.xmpp.org/extensions/xep-0224.html#ns'/>
<body>Why don't you answer, Herbie?</body>
</message>
]]></example>
<p>Finally, the receiving user notices the urgency of the message and responds.</p>
<example caption="The user whose attention has been captured responds."><![CDATA[
<message from='herbie@usrobots.lit/home' to='calvin@usrobots.lit/lab' type='chat'>
<body>I cannot. You know I cannot! Dr. Bogert and Dr. Lanning don't want me to.</body>
</message>
]]></example>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<p>The following rules apply to generating and processing of the attention extension.
<ol>
<li>Before sending an attention message stanza, the client MUST confirm support for it in the other client as described under <link url='#disco'>Determining Support</link>.</li>
<li>The message stanza containing the attention extension MAY contain a body and/or other extensions, which is to be displayed along with executing the attention event.</li>
<li>In message stanzas containing either &xep0203; data, attention extensions MUST be ignored, since this is an instant event which should not be replayed after a delay.</li>
<li>Messages containing an attention extension SHOULD use the headline message type to avoid offline storage.</li>
<li>Using the attention extension in &IQ; stanzas is not desirable, since this is part of the conversation.</li>
</ol>
</p>
</section1>
<section1 topic='Determining Support' anchor='disco'>
<p>If an entity supports receiving the attention extension, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "http://www.xmpp.org/extensions/xep-0224.html#ns":</p>
<example caption='A disco#info query'><![CDATA[
<iq type='get'
from='calvin@usrobots.lit/lab'
to='herbie@usrobots.lit/home'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption='A disco#info response'><![CDATA[
<iq type='result'
from='herbie@usrobots.lit/home'
to='calvin@usrobots.lit/lab'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='http://www.xmpp.org/extensions/xep-0224.html#ns'/>
...
</query>
</iq>
]]></example>
<p>In addition, support for receiving attention extensions in message stanzas can be determined through the dynamic profile of Service Discovery defined in &xep0115;.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>The implementation of the alert is up to the developer. Possible behavior is:</p>
<ul>
<li>Shaking the window.</li>
<li>Playing a specific sound not used for any other event.</li>
<li>Flashing the screen.</li>
<li>Enabling external hardware such as flashlights.</li>
<li>Let it be user customizable.</li>
</ul>
<p>However, since some users might not want this feature to disturb them, a client SHOULD enable the user to disable support. When the feature is disabled, it MUST NOT be advertised in disco#info.</p>
<p>Rate-limiting might be desirable in some implementations.</p>
<p>Formal feedback in response to the attention request to the requesting user is not specified, and so the request might be silently dropped.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>It is recommended that only message stanzas containing attention extensions from peers on the user's roster are accepted. Finer grained control might be implemented.</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'>
<section2 topic='Protocol Namespaces' anchor='ns'>
<p>Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-0224.html#ns"; upon advancement of this specification, the &REGISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
</section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://www.xmpp.org/extensions/xep-0224.html#ns'
xmlns='http://www.xmpp.org/extensions/xep-0224.html#ns'
elementFormDefault='qualified'>
<xs:element name='attention' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
]]></code>
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>The quotes have been taken from Isaac Asimov's short story "Liar!" as published in the book <cite>The Complete Robot</cite>.</p>
</section1>
</xep>