<p>Even though a client might be available (as stated in the most recent presence stanza), the user this client belongs to might not be focused on the client currently. &xep0132; defines a method for a physical test of user presence. Since this requires special hardware that cannot be assumed to be available, this XEP defines a software-only implementation where no direct feedback is expected. This feature is known as 'nudge' or 'buzz' in some non-XMPP IM protocols.</p>
<p>It was discussed whether this feature belongs in &xep0085;. However, the semantics are inherently different, since Chat State Notificaitons describe the sender's state, not a request to change the receiver's. Thus, a separate extension is desirable.</p>
<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 <attention/> element qualified by the 'urn:xmpp:attention:0' namespace &VNOTE;. Note: The message MAY include a &BODY; element.</p>
<li>Before sending an attention message stanza, the client SHOULD confirm support for it in the other client as described under <linkurl='#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 the attention request is an instant event which SHOULD NOT be replayed after a delay.</li>
<p>If an entity wishes to receive the attention extension, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "urn:xmpp:attention:0":</p>
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
<p>Because some users might not want this feature to disturb them, a client MUST either (1) allow the user to disable support or (2) disable the feature by default and process attention requests only if the user has explicitly enabled support. When the feature is disabled, it MUST NOT be advertised in disco#info.</p>
<p>It is RECOMMENDED that a client accept message stanzas containing the attention extension only contacts that are in the user's roster or with whom the user's client is currently sharing directed presence, mainly to prevent the user from being annoyed by attention requests from random entities on the network. A client could implement finer-grained control if desired (e.g., allow attention requests only from entities in a particular roster group).</p>
