Sieve Presence: Sieve Notification Using Presence Information
Lets a Sieve mail filter check whether you are busy, away or offline before it decides how to notify you.
George, R. and B. Leiba, "Sieve Notification Using Presence Information", RFC 6132, DOI 10.17487/RFC6132, July 2011, <https://www.rfc-editor.org/info/rfc6132>.
@misc{rfc6132,
series = {Request for Comments},
number = 6132,
howpublished = {RFC 6132},
publisher = {RFC Editor},
doi = {10.17487/RFC6132},
url = {https://www.rfc-editor.org/info/rfc6132},
author = {R. George and B. Leiba},
title = {{Sieve Notification Using Presence Information}},
pagetotal = 8,
year = 2011,
month = jul,
} RFC text
Contents
Internet Engineering Task Force (IETF) R. George
Request for Comments: 6132 B. Leiba
Category: Standards Track Huawei Technologies
ISSN: 2070-1721 July 2011
Sieve Notification Using Presence Information
Abstract
This is a further extension to the Sieve mail filtering language
Notification extension, defining presence information that may be
checked through the notify_method_capability feature.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6132.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology Used in This Document . . . . . . . . . . . . . 2
2. Testing Presence Information . . . . . . . . . . . . . . . . . 2
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
1. Introduction
Sometimes, it's desirable to tailor Sieve [RFC5228] notifications to
a user's current situation. Presence information provides some
information about the user that would be useful to have access to in
these cases. The Notification extension [RFC5435] defines a
mechanism to test for presence (the notify_method_capability
feature), and defines one test for presence (the "online"
notification-capability, described in Section 5 of RFC 5435). This
extension defines more presence tests by registering additional
notification-capability parameters in the IANA registry, allowing
testing of a wider variety of presence information.
1.1. Terminology Used in This Document
The upper-case key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. Testing Presence Information
This extension uses the notify_method_capability test, as defined in
the Sieve [RFC5228] Notify extension [RFC5435], to test presence
information. When a Sieve event occurs (mail arrives) for a user, a
Sieve script running on behalf of that user can present the user's
presence URI (in the "notification-uri" parameter) and test a
specific item of notification presence as defined below (in the
"notification-capability" parameter) against one or more values (in
the "key-list" parameter).
This document defines an initial set of items of notification
presence, which may be specified in the notification-capability
parameter. It is expected that future extensions will add additional
presence items derived from diverse sources, including calendar
information, geographic location, and so on.
Note that, while the items below are documented as similar to items
in Extensible Messaging and Presence Protocol (XMPP) [RFC6121], it is
not the intent that this extension be tied to XMPP, nor to any
particular source of presence, and flexible implementations will be
ready for future extensions. Useful informational references for
presence data and formats include Presence Information Data Format
(PIDF) [RFC3863], RPID: Rich Presence Extensions to PIDF [RFC4480],
and GEOPRIV Presence Information Data Format Location Object
(PIDF-LO) [RFC5491].
The script tests the values of notification presence items in the
key-list parameter. The values that each item may have are specified
in the list below. Note that in addition to the presence values, any
item may have the value "unknown" if it is not possible to determine
the correct presence value of the item.
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).
This provides consistency within a single execution.
Supported presence items are as follows:
busy: An indication of whether the user is considered "busy" now
(the value "yes") or not (the value "no"), or "unknown" if
it cannot be determined. The meaning of "busy" is left to
the implementation, and may be a state that's synthesized
from other information (including "show", below).
show: The availability status of the user, formally specified.
Note that this is similar to the presence element with the
same name that's defined in Section 4.7.2.1 of RFC 6121
[RFC6121]. The value of this item is one of the following:
away: The user is temporarily away.
chat: The user is online and actively interested in
chatting.
dnd: Do Not Disturb; the user does not wish to be
disturbed now.
offline: The user is offline.
xa: The user is away for an extended period (xa =
"eXtended Away").
unknown: The correct presence value could not be determined.
status: A human-readable description of the user's availability
status, in natural language. There is no formal definition
for the values this item may take. It is free-form, and may
be in any language. Direct comparisons against the value of
this field are unlikely to be useful; rather, it is provided
to enable extraction of the value into a variable [RFC5229]
for use elsewhere (see example 3 in Section 3). Note that
this is similar to the presence element with the same name
that's defined in Section 4.7.2.2 of RFC 6121 [RFC6121], and
to the <note> element defined in section 4.1.6 of PIDF
[RFC3863].
Because this is a free-form value that might be created
directly by a user, no value, including "unknown", can have
any special meaning. If the Sieve processor is unable to
determine the value of this item, it might be best to leave
it as an empty string. In any case, it is not meant for
machine-readable processing, beyond possible XML
interpretation.
There is no capability string associated with this extension, but
this requires support for "enotify" [RFC5435]. If the implementation
does not support the item being tested (that is, the specified
notification-capability item is not known to the Sieve interpreter),
RFC 5435 already specifies that the test fail without an error.
Although this feature was conceived to assist in notifications, and
the test requires support of the Sieve Notify feature, it is only a
condition test, and any Sieve action can appear inside it. There are
no Sieve actions that conflict with this extension.
3. Examples
1. This example will send a notification only if the recipient is
not "busy". If the test for "busy" is not supported, this
example will not send a notification.
require ["enotify"];
if notify_method_capability "xmpp:tim@example.com" "busy" "no"
{
notify :message "You got mail"
"xmpp:tim@example.com?message;subject=SIEVE";
}
2. This example will send a notification only if the recipient is
not "busy". If the test for "busy" is not supported, this
example will send a notification.
require ["enotify"];
if not notify_method_capability "xmpp:tim@example.com" "busy" "yes"
{
notify :message "You got mail"
"xmpp:tim@example.com?message;subject=SIEVE";
}
3. This example uses the vacation extension [RFC5230] to generate an
auto-reply [RFC6133] if the sender is in the recipient's address
book [RFC6134] and the recipient's presence shows "extended
away". The variables extension [RFC5229] is used to extract the
value of the recipient's presence status message, which will be
used in the response to the sender. If the test for "show" is
not supported, this example will not send an auto-reply.
require ["extlists", "vacation", "enotify", "variables"];
if allof (
envelope :list "from" ":addrbook:default",
notify_method_capability "xmpp:myjid@example.com" "show" "xa"
) {
# :matches "*" is used here to extract the value
if notify_method_capability :matches
"xmpp:myjid@example.com" "status" "*" {
set "resp_msg" "${1}";
} else {
set "resp_msg" "I'm away from email for a while."
}
vacation :handle "ext-away" "${resp_msg}";
}
4. Security Considerations
Security considerations for Sieve [RFC5228] and the Notify extension
[RFC5435] apply equally here. In addition, implementations MUST
ensure that users cannot create scripts that access the presence
information of others without the proper access controls.
In some situations, scripts may act on some of the recipient's
presence information that the sender of the triggering message is not
allowed to see. This can be a benefit to the recipient in many
cases, but it can also present an opportunity for a sender to use
messages to probe the recipient's presence (if, for example, messages
sometimes result in auto-replies, and sometimes do not). Script
authors should take care in considering this aspect of presence-
triggered actions.
It's possible for a large number of messages to arrive at or around
the same time and be processed by Sieve scripts that all test
presence. If many of the users share the same presence server, such
a burst could put an unexpectedly heavy load on the presence server.
Implementations might consider providing options for rate limiting,
or for caching presence tests for periods of time, even across Sieve
script instances. When caching presence tests, the server must be
careful not to violate access controls that the presence server might
have. Thus, cached results MUST NOT be used outside the context in
which they were retrieved. If, for example, a script running on
behalf of Adam requests presence information for Barbara, that
information MAY be cached for a future script running on behalf of
Adam, but MUST NOT be used to satisfy the same query in a script
running on behalf of Cindy -- because the presence server will have
to decide whether Cindy has access to that information.
5. IANA Considerations
This registers each presence item as a notification-capability
parameter. Future extensions that add new presence items should
register those items similarly, using the instructions in Section 9.3
of RFC 5435 [RFC5435].
To: iana@iana.org
Subject: Registration of a new notification-capability parameter
Capability name: busy
Description: An indication of whether the user is considered "busy"
now (the value "yes") or not (the value "no"). The meaning of
"busy" is left to the implementation, and may be a state that's
synthesized from other information.
Syntax: Has one of the values "yes", "no", or "unknown". The value
MUST be in lower case.
Permanent and readily available reference(s): RFC 6132
Contact information: The Sieve discussion list, <sieve@ietf.org>
To: iana@iana.org
Subject: Registration of a new notification-capability parameter
Capability name: show
Description: The availability status of the user. This is similar
to the presence element with the same name that's defined in
Section 4.7.2.1 of RFC 6121.
Syntax: Has one of the values "away", "chat", "dnd", "offline",
"xa", or "unknown". The value MUST be in lower case.
Permanent and readily available reference(s): RFC 6132
Contact information: The Sieve discussion list, <sieve@ietf.org>
To: iana@iana.org
Subject: Registration of a new notification-capability parameter
Capability name: status
Description: A human-readable description of the user's availability
status. This is similar to the presence element with the same
name that's defined in Section 4.7.2.2 of RFC 6121.
Syntax: There is no formal definition for the values this item may
take. It is free-form and may be in any language, and is meant
for human consumption.
Permanent and readily available reference(s): RFC 6132
Contact information: The Sieve discussion list, <sieve@ietf.org>
6. Acknowledgments
The authors thank Alexey Melnikov for significant early feedback and
suggestions.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008.
[RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
"Sieve Email Filtering: Extension for Notifications",
RFC 5435, January 2009.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", RFC
6121, March 2011.
7.2. Informative References
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004.
[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the Presence
Information Data Format (PIDF)", RFC 4480, July 2006.
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",
RFC 5229, January 2008.
[RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering:
Vacation Extension", RFC 5230, January 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009.
[RFC6133] George, R., Leiba, B., and A. Melnikov, "Sieve Email
Filtering: Use of Presence Information with Auto-Responder
Functionality", RFC 6134, July 2011.
[RFC6134] Melnikov, A. and B. Leiba, "Sieve Extension: Externally
Stored Lists", RFC 6134, July 2011.
Authors' Addresses
Robins George
Huawei Technologies
Bangalore, Karnataka 560071
India
Phone: +91-080-41117676
EMail: robinsgv@gmail.com
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
AI ELI5
On this page
§1Why Presence Matters to Sieve
Sieve (RFC 5228) is a mail filtering language. Its Notification extension (RFC 5435) can send alerts when mail arrives, and already defines a way to test presence: the notify_method_capability test, with one test, the "online" notification-capability.
RFC 6132 adds more presence tests by registering extra notification-capability parameters in the IANA registry. The goal is to tailor notifications to a user's current situation.
A mail filter can already send you a ping. This lets it first check whether you are in the mood to be pinged.
§2Testing Presence Items
When mail arrives, a script running for the user passes the user's presence URI in the notification-uri parameter, names an item in notification-capability and compares it with values in key-list. Any item may also have the value unknown if it cannot be determined.
If a script tests the same item more than once in one execution, implementations MUST give the same value each time, for example by caching it on first use. There is no capability string for this extension, but it requires support for enotify. If the interpreter does not know the item, RFC 5435 already says the test fails without an error.
It is only a condition test, so any Sieve action can appear inside it. The RFC says it is not tied to XMPP (RFC 6121) or any particular presence source, and expects future extensions to add items such as calendar or location data.
The filter asks one question about you, gets one answer, and sticks to that answer for the rest of the check, so it does not change its mind halfway.
§3The Three Presence Items
busy says whether the user is considered busy now, with values yes, no or unknown. What busy means is left to the implementation and may be derived from other information, including show.
show is the formal availability status, similar to the element of the same name in RFC 6121. Its values are away, chat, dnd (do not disturb), offline, xa (extended away) and unknown.
status is a free-form, human-readable description in any language. Comparing it directly is unlikely to be useful, so it is meant to be pulled into a variable (RFC 5229) and reused, for example in an auto-reply. Because users may write it, no value, including unknown, has special meaning. An empty string may be best when it cannot be determined.
There are three signs: a yes or no busy sign, a menu of moods like away or do not disturb, and a sticky note you write yourself.
- awayAway — The user is temporarily away.
- chatChat — Online and actively interested in chatting.
- dndDo not disturb — The user does not wish to be disturbed now.
- offlineOffline — The user is offline.
- xaExtended away — Away for an extended period.
- unknownUnknown — The correct value could not be determined.
§4Example Scripts
The first example sends an XMPP notification only if the recipient is not busy, and sends nothing if the busy test is unsupported. The second flips the logic with not and "yes", so a notification is sent when busy is unsupported.
The third uses the vacation extension (RFC 5230) to auto-reply when the sender is in the recipient's address book (RFC 6134) and the recipient's show is xa. It uses the variables extension to put the status text into the reply, with a fallback message if none is available.
One rule says only ping me when I am free. Another says if I am away, send a friend an automatic note with my own words.
require ["enotify"];
if notify_method_capability "xmpp:tim@example.com" "busy" "no"
{
notify :message "You got mail"
"xmpp:tim@example.com?message;subject=SIEVE";
}§5Privacy and Load Risks
Security considerations for Sieve and the Notify extension apply. Implementations MUST ensure users cannot write scripts that read other people's presence information without proper access controls.
A script can act on presence that the message sender is not allowed to see. A sender could then probe the recipient's presence if messages sometimes trigger auto-replies and sometimes do not.
Many messages arriving at once could overload a shared presence server. Implementations might add rate limiting or caching. Cached results MUST NOT be used outside the context in which they were retrieved: a result fetched for Adam's script about Barbara may be reused for Adam, but not for Cindy.
Your busy sign should be seen only by people allowed to see it. Someone could also learn when you are away by noticing when you stop answering, so be careful with auto-replies.
§6IANA Registrations
The RFC registers busy, show and status as notification-capability parameters. For busy and show, the value MUST be lower case. Future presence items should be registered the same way, following Section 9.3 of RFC 5435. The contact for all three is the Sieve discussion list.
The three signs are written in an official list so every mail system uses the same names.