Sieve Notification Using Presence Information
Extracted elements (14)
The 'status' item is provided not for direct machine-readable comparison but to enable extraction of its value into a Sieve variable for use elsewhere (e.g., in an auto-reply message). Because it is free-form and user-created, no value including 'unknown' can have special meaning.
While the defined presence items are documented as similar to items in XMPP (RFC 6121), the extension is intentionally not tied to XMPP or any particular presence source. Flexible implementations should be ready for future extensions derived from diverse sources including calendar information and geographic location.
There is no capability string associated with this extension, but it requires support for the 'enotify' extension (RFC 5435). If the implementation does not support the item being tested, RFC 5435 already specifies that the test fails without an error.
If a particular presence item is tested multiple times within the same script execution context, implementations MUST present the same value each time, for example by caching the value on first use, to provide consistency within a single execution.
The values for the 'busy' capability MUST be in lower case ('yes', 'no', or 'unknown'), and the values for the 'show' capability MUST also be in lower case ('away', 'chat', 'dnd', 'offline', 'xa', or 'unknown').
Scripts may act on presence information that the message sender is not permitted to see. A sender can potentially use messages to probe the recipient's presence state (e.g., by observing whether an auto-reply is generated). Script authors should carefully consider this aspect of presence-triggered actions.
The 'busy' presence item indicates whether the user is considered busy ('yes'), not busy ('no'), or 'unknown' if it cannot be determined. The meaning of 'busy' is left to the implementation and may be synthesized from other information.
The extension uses the notify_method_capability test from RFC 5435 to test presence information. A Sieve script presents the user's presence URI in the 'notification-uri' parameter and tests a specific notification presence item in the 'notification-capability' parameter against one or more values in the 'key-list' parameter.
The 'show' presence item provides the formal availability status of the user with defined values: 'away' (temporarily away), 'chat' (online and interested in chatting), 'dnd' (Do Not Disturb), 'offline', 'xa' (extended away), or 'unknown'. This mirrors the XMPP presence element defined in RFC 6121 Section 4.7.2.1.
The 'status' presence item is a human-readable, free-form description of the user's availability in natural language with no formal value definition. It is intended for extraction into a variable for use elsewhere rather than direct machine comparison; if the value cannot be determined, leaving it as an empty string is recommended.
This document registers three new notification-capability parameters in the IANA registry: 'busy' (values: 'yes', 'no', 'unknown'), 'show' (values: 'away', 'chat', 'dnd', 'offline', 'xa', 'unknown'), and 'status' (free-form human-readable string). Future extensions adding new presence items should register them similarly using the instructions in RFC 5435 Section 9.3.
A large burst of messages arriving simultaneously and processed by presence-testing Sieve scripts could put unexpectedly heavy load on a shared presence server. Implementations might consider providing options for rate limiting or caching presence tests across Sieve script instances, while respecting access controls.
Cached presence test results MUST NOT be used outside the context in which they were retrieved. For example, presence information cached for a script running on behalf of Adam MUST NOT be used to satisfy the same query in a script running on behalf of Cindy, because the presence server must independently determine Cindy's access rights.
Implementations MUST ensure that users cannot create scripts that access the presence information of others without the proper access controls. Scripts may act on presence information that the sender of the triggering message is not allowed to see, which could enable a sender to probe the recipient's presence by observing whether auto-replies are generated.