diff options
author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
---|---|---|
committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6132.txt | |
parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6132.txt')
-rw-r--r-- | doc/rfc/rfc6132.txt | 451 |
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] + |