Sieve working group R. George
Internet-Draft B. Leiba
Intended status: Standards Track Huawei Technologies
Expires: June 1, 2011 November 28, 2010
Sieve Notification Using Presence Information
draft-ietf-sieve-notify-presence-03
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 1, 2011.
Copyright Notice
Copyright (c) 2010 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.
George & Leiba Expires June 1, 2011 [Page 1]
Internet-Draft Sieve Notify: Presence November 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology Used in This Document . . . . . . . . . . . . . . 3
2. Testing presence information . . . . . . . . . . . . . . . . 3
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
George & Leiba Expires June 1, 2011 [Page 2]
Internet-Draft Sieve Notify: Presence November 2010
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 a set of items of notification presence, which
may be specified in the notification-capability parameter. 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:
George & Leiba Expires June 1, 2011 [Page 3]
Internet-Draft Sieve Notify: Presence November 2010
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 2.2.2.1 of RFC 3921.[RFC3921] 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 should not 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. 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 2.2.2.2 of RFC
3921.[RFC3921]
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.
George & Leiba Expires June 1, 2011 [Page 4]
Internet-Draft Sieve Notify: Presence November 2010
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
autoreply [I-D.ietf-sieve-autoreply] if the sender is in the
recipient's address book [I-D.ietf-sieve-external-lists] 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 autoreply.
George & Leiba Expires June 1, 2011 [Page 5]
Internet-Draft Sieve Notify: Presence November 2010
require ["extlists", "vacation", "enotify", "variables"];
if allof (
envelope :list "from" "tag:example.com,2009-05-28:mylist",
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 can not 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.
5. IANA Considerations
This registers each presence item as a notification-capability
George & Leiba Expires June 1, 2011 [Page 6]
Internet-Draft Sieve Notify: Presence November 2010
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): this RFC
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 2.2.2.1 of RFC 3921.
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): this RFC
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 2.2.2.2 of RFC 3921.
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): this RFC
Contact information: The Sieve discussion list, <sieve@ietf.org>
6. Acknowledgments
The authors thank Alexey Melnikov for significant early feedback and
suggestions.
7. References
George & Leiba Expires June 1, 2011 [Page 7]
Internet-Draft Sieve Notify: Presence November 2010
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 3921, October 2004.
[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.
7.2. Informative References
[I-D.ietf-sieve-autoreply]
George, R., Leiba, B., and A. Melnikov, "Sieve Email
Filtering: Use of Presence Information with Auto Responder
functionality", draft-ietf-sieve-autoreply-02 (work in
progress), October 2010.
[I-D.ietf-sieve-external-lists]
Melnikov, A. and B. Leiba, "Sieve Extension: Externally
Stored Lists", draft-ietf-sieve-external-lists-02 (work in
progress), May 2010.
[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.
Authors' Addresses
Robins George
Huawei Technologies
Bangalore, Karnataka 560071
India
Phone: +91-080-41117676
Email: robinsgv@gmail.com
George & Leiba Expires June 1, 2011 [Page 8]
Internet-Draft Sieve Notify: Presence November 2010
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
George & Leiba Expires June 1, 2011 [Page 9]