From a203d092afd05610013bc8ee1c763b50e657f181 Mon Sep 17 00:00:00 2001
From: Peter Saint-Andre Modified namespace to incorporate namespace versioning. 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. 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 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. 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. 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 'http://www.xmpp.org/extensions/xep-0224.html#ns' namespace &NSNOTE;. Note: The message may or may not include a &BODY; element. 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 or may not include a &BODY; element. The following rules apply to generating and processing of the attention extension.
-
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":
+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 "urn:xmpp:attention:0":
In addition, support for receiving attention extensions in message stanzas can be determined through the dynamic profile of Service Discovery defined in &xep0115;.
+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.
The implementation of the alert is up to the developer. Possible behavior is:
@@ -112,19 +118,26 @@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.
+However, since some users might not want this feature to disturb them, a client SHOULD allow the user to disable support. When the feature is disabled, it MUST NOT be advertised in disco#info.
Rate-limiting might be desirable in some implementations.
Formal feedback in response to the attention request to the requesting user is not specified, and so the request might be silently dropped.
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.
+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.
This document requires no interaction with &IANA;.
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 ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.
+This specification defines the following XML namespace:
+Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
+If the protocol defined in this specification undergoes a major revision that is not fully backward-compatible with an older version, or that contains significant new features, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.