    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.

    George & Leiba               Standards Track                    [Page 1]

    RFC 6132                 Sieve Notify: Presence                July 2011

    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).

    George & Leiba               Standards Track                    [Page 2]

    RFC 6132                 Sieve Notify: Presence                July 2011

       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.

    George & Leiba               Standards Track                    [Page 3]

    RFC 6132                 Sieve Notify: Presence                July 2011

                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.

    George & Leiba               Standards Track                    [Page 4]

    RFC 6132                 Sieve Notify: Presence                July 2011

       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}";
         }

    George & Leiba               Standards Track                    [Page 5]

    RFC 6132                 Sieve Notify: Presence                July 2011

    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.

    George & Leiba               Standards Track                    [Page 6]

    RFC 6132                 Sieve Notify: Presence                July 2011

       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.

    George & Leiba               Standards Track                    [Page 7]

    RFC 6132                 Sieve Notify: Presence                July 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/

    George & Leiba               Standards Track                    [Page 8]