Sieve working group R. George Internet-Draft B. Leiba Intended status: Standards Track Huawei Technologies Expires: August 8, 2010 February 4, 2010 Sieve Notification Using Presence Information draft-george-sieve-notify-presence-01 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 to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 8, 2010. 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 George & Leiba Expires August 8, 2010 [Page 1]
Internet-Draft Sieve Notify: Presence February 2010 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology Used in This Document . . . . . . . . . . . . . . 3 2. Testing presence information . . . . . . . . . . . . . . . . 3 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 George & Leiba Expires August 8, 2010 [Page 2]
Internet-Draft Sieve Notify: Presence February 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 specifies testing of a wider variety of presence information. 1.1. Terminology Used in This Document The 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 the following items of notification presence, which may be specified in the notification-capability parameter: busy - 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 (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. George & Leiba Expires August 8, 2010 [Page 3]
Internet-Draft Sieve Notify: Presence February 2010 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"). 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] 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 above; in addition, any item may have the value "unknown", if it is not possible to determine the correct value of the item. 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, RFC 5435 already specifies that the test must 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" George & Leiba Expires August 8, 2010 [Page 4]
Internet-Draft Sieve Notify: Presence February 2010 "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.george-sieve-autoreply] if the sender is in the recipient's address book [I-D.melnikov-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. 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}"; } George & Leiba Expires August 8, 2010 [Page 5]
Internet-Draft Sieve Notify: Presence February 2010 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. 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): 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> 6. Acknowledgments The authors thank Alexey Melnikov for significant early feedback and suggestions. 7. References George & Leiba Expires August 8, 2010 [Page 6]
Internet-Draft Sieve Notify: Presence February 2010 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. 7.2. Informative References [I-D.george-sieve-autoreply] George, R. and A. Melnikov, "Sieve Email Filtering: Use of Presence Information with Auto Responder functionality", draft-george-sieve-autoreply-00 (work in progress), June 2009. [I-D.melnikov-sieve-external-lists] Melnikov, A., "Sieve Extension: Externally Stored Lists", draft-melnikov-sieve-external-lists-01 (work in progress), July 2007. [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004. [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 Huawei Base, Bantian, Longgang District Shenzhen, Guangdong 518129 P. R. China Phone: +86-755-28788314 Email: robinsg@huawei.com George & Leiba Expires August 8, 2010 [Page 7]
Internet-Draft Sieve Notify: Presence February 2010 Barry Leiba Huawei Technologies Phone: +1 646 827 0648 Email: barryleiba@computer.org URI: http://internetmessagingtechnology.org/ George & Leiba Expires August 8, 2010 [Page 8]