Update after discussions on the standards@ mailing list.
Initial version.
"Notifications" are (usually) pop-up windows that appear in a visible area of the screen even when the emitting application is in the background, often triggering a sound alert. Instant messaging clients expectedly use notifications to inform users when they receive a message.
Users may want to customise which conversations should trigger notifications and under which conditions. In practice, this is already implemented in many instant messaging clients, including XMPP clients. This specification proposes a mechanism to synchronise per-discussion notification settings across different XMPP clients and other XMPP based applications.
Notification settings are represented by the <notify> element. This element MUST be a child of an element identifying a specific chat by its JID, such as a PEP Native Bookmarks (XEP-0402)
This protocol specifies three notification elements as children for the <notify> element, each corresponding to a notification setting: <always> <on-mention> and <never>. A notification element without attributes is called a "fallback element".
Applications MAY choose different notification settings depending on their own Service Discovery Identity. In this case, the two optional attributes 'identity-category' and 'identity-type' MAY be added to the notification element, using values registered in the Service Discovery Identities registry at <https://xmpp.org/registrar/disco-categories.html>.
The 'identity-type' attribute MAY be omitted, if the notification setting should apply to a whole Identity Category. You MUST NOT add the 'identity-type' attribute without an accompanying 'identity-category' attribute.
Finally, clients can use this specification to synchronise finer-grained notification settings using custom namespaces in the optional <advanced/> child of the notification elements.
The <advanced/> element SHOULD NOT be empty.
Applications implementing this specification MUST NOT delete or alter the <advanced /> notification settings they do not support when updating the notification settings for a given conversation.
When reading the notification settings for a given conversation, applications implementing this specification MUST use the element most specific to their own application identity. Sorted from high to low specifity, this is:
When writing the notification settings, applications MAY use the 'identity-category' and 'identity-type' attributes as described in the Identities section. If a fallback element without any attributes isn't present, the application SHOULD add it with the same settings. As secondary fallback, it MAY also add a notification setting having only the 'identity-category' attribute, if not already present.
There SHALL NOT be more than one notification element having the same name, attributes and attribute values.
Applications using the <advanced/> child SHOULD attempt to choose the parent notification element being the closest to what they offer as a fallback for other applications not supporting the advanced settings.
In the absence of any notification settings for a given conversation, "always" SHOULD be assumed for direct chats and private group chats, and on-mention for public group chats.
The "on-mention" notification MAY rely on the user's nickname being spelled out in an incoming message in a group chat, but SHOULD rely on mechanisms to explicitly "ping" the user, such as a Message Replies (XEP-0461)
See considerations in PEP Native Bookmarks (XEP-0402)
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)
This specification defines the following XML namespace:
The XMPP Registrar
If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, 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.
The protocol documented by this schema is defined in
XEP-]]>04920492
]]>