summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6132.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6132.txt')
-rw-r--r--doc/rfc/rfc6132.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc6132.txt b/doc/rfc/rfc6132.txt
new file mode 100644
index 0000000..b428cd5
--- /dev/null
+++ b/doc/rfc/rfc6132.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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]
+