draft-ietf-sieve-notify-presence-04.txt   rfc6132.txt 
Sieve working group R. George Internet Engineering Task Force (IETF) R. George
Internet-Draft B. Leiba Request for Comments: 6132 B. Leiba
Intended status: Standards Track Huawei Technologies Category: Standards Track Huawei Technologies
Expires: June 18, 2011 December 15, 2010 ISSN: 2070-1721 July 2011
Sieve Notification Using Presence Information Sieve Notification Using Presence Information
draft-ietf-sieve-notify-presence-04
Abstract Abstract
This is a further extension to the Sieve mail filtering language This is a further extension to the Sieve mail filtering language
Notification extension, defining presence information that may be Notification extension, defining presence information that may be
checked through the notify_method_capability feature. checked through the notify_method_capability feature.
Status of this Memo 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 This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 18, 2011. 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 Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology Used in This Document . . . . . . . . . . . . . . 3 1.1. Terminology Used in This Document . . . . . . . . . . . . . 2
2. Testing Presence Information . . . . . . . . . . . . . . . . . 2
2. Testing presence information . . . . . . . . . . . . . . . . 3 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Sometimes, it's desirable to tailor Sieve [RFC5228] notifications to Sometimes, it's desirable to tailor Sieve [RFC5228] notifications to
a user's current situation. Presence information provides some a user's current situation. Presence information provides some
information about the user that would be useful to have access to in information about the user that would be useful to have access to in
these cases. The Notification extension [RFC5435] defines a these cases. The Notification extension [RFC5435] defines a
mechanism to test for presence (the notify_method_capability mechanism to test for presence (the notify_method_capability
feature), and defines one test for presence (the "online" feature), and defines one test for presence (the "online"
notification-capability, described in Section 5 of RFC 5435). This notification-capability, described in Section 5 of RFC 5435). This
skipping to change at page 3, line 25 skipping to change at page 2, line 38
notification-capability parameters in the IANA registry, allowing notification-capability parameters in the IANA registry, allowing
testing of a wider variety of presence information. testing of a wider variety of presence information.
1.1. Terminology Used in This Document 1.1. Terminology Used in This Document
The upper-case key words "MUST", "MUST NOT", "REQUIRED", "SHALL", The upper-case key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
2. Testing presence information 2. Testing Presence Information
This extension uses the notify_method_capability test, as defined in This extension uses the notify_method_capability test, as defined in
the Sieve [RFC5228] Notify extension [RFC5435], to test presence the Sieve [RFC5228] Notify extension [RFC5435], to test presence
information. When a Sieve event occurs (mail arrives) for a user, a 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 Sieve script running on behalf of that user can present the user's
presence URI (in the "notification-uri" parameter) and test a presence URI (in the "notification-uri" parameter) and test a
specific item of notification presence as defined below (in the specific item of notification presence as defined below (in the
"notification-capability" parameter) against one or more values (in "notification-capability" parameter) against one or more values (in
the "key-list" parameter). the "key-list" parameter).
This document defines an initial set of items of notification This document defines an initial set of items of notification
presence, which may be specified in the notification-capability presence, which may be specified in the notification-capability
parameter. It is expected that future extensions will add additional parameter. It is expected that future extensions will add additional
presence items derived from diverse sources, including calendar presence items derived from diverse sources, including calendar
information, geographic location, and so on. information, geographic location, and so on.
Note that, while the items below are documented as similar to items Note that, while the items below are documented as similar to items
in XMPP, it is not the intent that this extension be tied to XMPP, in Extensible Messaging and Presence Protocol (XMPP) [RFC6121], it is
nor to any particular source of presence, and flexible not the intent that this extension be tied to XMPP, nor to any
implementations will be ready for future extensions. Useful particular source of presence, and flexible implementations will be
informational references for presence data and formats include ready for future extensions. Useful informational references for
Presence Information Data Format (PIDF) [RFC3863], RPID: Rich presence data and formats include Presence Information Data Format
Presence Extensions to PIDF [RFC4480], and GEOPRIV Presence (PIDF) [RFC3863], RPID: Rich Presence Extensions to PIDF [RFC4480],
Information Data Format Location Object (PIDF-LO) [RFC5491]. and GEOPRIV Presence Information Data Format Location Object
(PIDF-LO) [RFC5491].
The script tests the values of notification presence items in the The script tests the values of notification presence items in the
key- list parameter. The values that each item may have are key-list parameter. The values that each item may have are specified
specified in the list below. Note that in addition to the presence in the list below. Note that in addition to the presence values, any
values, any item may have the value "unknown" if it is not possible item may have the value "unknown" if it is not possible to determine
to determine the correct presence value of the item. the correct presence value of the item.
If a particular presence item is tested multiple times within the If a particular presence item is tested multiple times within the
same script execution context, implementations MUST present the same same script execution context, implementations MUST present the same
value each time (for example, by caching the value on first use). value each time (for example, by caching the value on first use).
This provides consistency within a single execution. This provides consistency within a single execution.
Supported presence items are as follows: Supported presence items are as follows:
busy - An indication of whether the user is considered "busy" now busy: An indication of whether the user is considered "busy" now
(the value "yes") or not (the value "no"), or "unknown" if it (the value "yes") or not (the value "no"), or "unknown" if
cannot be determined. The meaning of "busy" is left to the it cannot be determined. The meaning of "busy" is left to
implementation, and may be a state that's synthesized from other the implementation, and may be a state that's synthesized
information (including "show", below). from other information (including "show", below).
show - The availability status of the user, formally specified. Note show: The availability status of the user, formally specified.
that this is similar to the presence element with the same name Note that this is similar to the presence element with the
that's defined in Section 2.2.2.1 of RFC 3921.[RFC3921] The same name that's defined in Section 4.7.2.1 of RFC 6121
value of this item is one of the following: [RFC6121]. The value of this item is one of the following:
away - The user is temporarily away. away: The user is temporarily away.
chat - The user is online and actively interested in chatting. chat: The user is online and actively interested in
chatting.
dnd - Do Not Disturb; the user does not wish to be disturbed dnd: Do Not Disturb; the user does not wish to be
now. disturbed now.
offline - The user is offline. offline: The user is offline.
xa - The user is away for an extended period (xa = "eXtended xa: The user is away for an extended period (xa =
Away"). "eXtended Away").
unknown - The correct presence value could not be determined. unknown: The correct presence value could not be determined.
status - A human-readable description of the user's availability status: A human-readable description of the user's availability
status, in natural language. There is no formal definition for status, in natural language. There is no formal definition
the values this item may take. It is free-form, and may be in for the values this item may take. It is free-form, and may
any language. Direct comparisons against the value of this be in any language. Direct comparisons against the value of
field are unlikely to be useful; rather, it is provided to this field are unlikely to be useful; rather, it is provided
enable extraction of the value into a variable [RFC5229] for use to enable extraction of the value into a variable [RFC5229]
elsewhere (see example 3 in Section 3). Note that this is for use elsewhere (see example 3 in Section 3). Note that
similar to the presence element with the same name that's this is similar to the presence element with the same name
defined in Section 2.2.2.2 of RFC 3921 [RFC3921], and to the that's defined in Section 4.7.2.2 of RFC 6121 [RFC6121], and
<note> element defined in section 4.1.6 of PIDF [RFC3863]. 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 Because this is a free-form value that might be created
by a user, no value, including "unknown", can have any special directly by a user, no value, including "unknown", can have
meaning. If the Sieve processor is unable to determine the any special meaning. If the Sieve processor is unable to
value of this item, it might be best to leave it as an empty determine the value of this item, it might be best to leave
string. In any case, it is not meant for machine-readable it as an empty string. In any case, it is not meant for
processing, beyond possible XML interpretation. machine-readable processing, beyond possible XML
interpretation.
There is no capability string associated with this extension, but There is no capability string associated with this extension, but
this requires support for "enotify".[RFC5435] If the implementation this requires support for "enotify" [RFC5435]. If the implementation
does not support the item being tested (that is, the specified does not support the item being tested (that is, the specified
notification-capability item is not known to the Sieve interpreter), notification-capability item is not known to the Sieve interpreter),
RFC 5435 already specifies that the test fail without an error. RFC 5435 already specifies that the test fail without an error.
Although this feature was conceived to assist in notifications, and Although this feature was conceived to assist in notifications, and
the test requires support of the Sieve Notify feature, it is only a 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 condition test, and any Sieve action can appear inside it. There are
no Sieve actions that conflict with this extension. no Sieve actions that conflict with this extension.
3. Examples 3. Examples
skipping to change at page 6, line 4 skipping to change at page 5, line 23
2. This example will send a notification only if the recipient is 2. This example will send a notification only if the recipient is
not "busy". If the test for "busy" is not supported, this not "busy". If the test for "busy" is not supported, this
example will send a notification. example will send a notification.
require ["enotify"]; require ["enotify"];
if not notify_method_capability "xmpp:tim@example.com" "busy" "yes" if not notify_method_capability "xmpp:tim@example.com" "busy" "yes"
{ {
notify :message "You got mail" notify :message "You got mail"
"xmpp:tim@example.com?message;subject=SIEVE"; "xmpp:tim@example.com?message;subject=SIEVE";
} }
3. This example uses the vacation extension [RFC5230] to generate an 3. This example uses the vacation extension [RFC5230] to generate an
autoreply [I-D.ietf-sieve-autoreply] if the sender is in the auto-reply [RFC6133] if the sender is in the recipient's address
recipient's address book [I-D.ietf-sieve-external-lists] and the book [RFC6134] and the recipient's presence shows "extended
recipient's presence shows "extended away". The variables away". The variables extension [RFC5229] is used to extract the
extension [RFC5229] is used to extract the value of the value of the recipient's presence status message, which will be
recipient's presence status message, which will be used in the used in the response to the sender. If the test for "show" is
response to the sender. If the test for "show" is not supported, not supported, this example will not send an auto-reply.
this example will not send an autoreply.
require ["extlists", "vacation", "enotify", "variables"]; require ["extlists", "vacation", "enotify", "variables"];
if allof ( if allof (
envelope :list "from" "tag:example.com,2009-05-28:mylist", envelope :list "from" ":addrbook:default",
notify_method_capability "xmpp:myjid@example.com" "show" "xa" notify_method_capability "xmpp:myjid@example.com" "show" "xa"
) { ) {
# :matches "*" is used here to extract the value # :matches "*" is used here to extract the value
if notify_method_capability :matches if notify_method_capability :matches
"xmpp:myjid@example.com" "status" "*" { "xmpp:myjid@example.com" "status" "*" {
set "resp_msg" "${1}"; set "resp_msg" "${1}";
} else { } else {
set "resp_msg" "I'm away from email for a while." set "resp_msg" "I'm away from email for a while."
} }
vacation :handle "ext-away" "${resp_msg}"; vacation :handle "ext-away" "${resp_msg}";
} }
4. Security Considerations 4. Security Considerations
Security considerations for Sieve [RFC5228] and the Notify extension Security considerations for Sieve [RFC5228] and the Notify extension
[RFC5435] apply equally here. In addition, implementations MUST [RFC5435] apply equally here. In addition, implementations MUST
ensure that users can not create scripts that access the presence ensure that users cannot create scripts that access the presence
information of others without the proper access controls. information of others without the proper access controls.
In some situations, scripts may act on some of the recipient's In some situations, scripts may act on some of the recipient's
presence information that the sender of the triggering message is not presence information that the sender of the triggering message is not
allowed to see. This can be a benefit to the recipient in many 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 cases, but it can also present an opportunity for a sender to use
messages to probe the recipient's presence (if, for example, messages messages to probe the recipient's presence (if, for example, messages
sometimes result in auto-replies, and sometimes do not). Script sometimes result in auto-replies, and sometimes do not). Script
authors should take care in considering this aspect of presence- authors should take care in considering this aspect of presence-
triggered actions. triggered actions.
It's possible for a large number of messages to arrive at or around 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 the same time and be processed by Sieve scripts that all test
presence. If many of the users share the same presence server, such presence. If many of the users share the same presence server, such
a burst could put an unexpectedly heavy load on the presence server. a burst could put an unexpectedly heavy load on the presence server.
Implementations might consider providing options for rate limiting, Implementations might consider providing options for rate limiting,
or for caching presence tests for periods of time, even across Sieve or for caching presence tests for periods of time, even across Sieve
script instances. 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 5. IANA Considerations
This registers each presence item as a notification-capability This registers each presence item as a notification-capability
parameter. Future extensions that add new presence items should parameter. Future extensions that add new presence items should
register those items similarly, using the instructions in Section 9.3 register those items similarly, using the instructions in Section 9.3
of RFC 5435.[RFC5435] of RFC 5435 [RFC5435].
To: iana@iana.org To: iana@iana.org
Subject: Registration of a new notification-capability parameter Subject: Registration of a new notification-capability parameter
Capability name: busy Capability name: busy
Description: An indication of whether the user is considered "busy" Description: An indication of whether the user is considered "busy"
now (the value "yes") or not (the value "no"). The meaning of 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 "busy" is left to the implementation, and may be a state that's
synthesized from other information. synthesized from other information.
Syntax: Has one of the values "yes", "no", or "unknown". The value Syntax: Has one of the values "yes", "no", or "unknown". The value
MUST be in lower case. MUST be in lower case.
Permanent and readily available reference(s): this RFC
Permanent and readily available reference(s): RFC 6132
Contact information: The Sieve discussion list, <sieve@ietf.org> Contact information: The Sieve discussion list, <sieve@ietf.org>
To: iana@iana.org To: iana@iana.org
Subject: Registration of a new notification-capability parameter Subject: Registration of a new notification-capability parameter
Capability name: show Capability name: show
Description: The availability status of the user. This is similar Description: The availability status of the user. This is similar
to the presence element with the same name that's defined in to the presence element with the same name that's defined in
Section 2.2.2.1 of RFC 3921. Section 4.7.2.1 of RFC 6121.
Syntax: Has one of the values "away", "chat", "dnd", "offline", Syntax: Has one of the values "away", "chat", "dnd", "offline",
"xa", or "unknown". The value MUST be in lower case. "xa", or "unknown". The value MUST be in lower case.
Permanent and readily available reference(s): this RFC Permanent and readily available reference(s): RFC 6132
Contact information: The Sieve discussion list, <sieve@ietf.org> Contact information: The Sieve discussion list, <sieve@ietf.org>
To: iana@iana.org To: iana@iana.org
Subject: Registration of a new notification-capability parameter Subject: Registration of a new notification-capability parameter
Capability name: status Capability name: status
Description: A human-readable description of the user's availability Description: A human-readable description of the user's availability
status. This is similar to the presence element with the same status. This is similar to the presence element with the same
name that's defined in Section 2.2.2.2 of RFC 3921. 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 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 take. It is free-form and may be in any language, and is meant
for human consumption. for human consumption.
Permanent and readily available reference(s): this RFC Permanent and readily available reference(s): RFC 6132
Contact information: The Sieve discussion list, <sieve@ietf.org> Contact information: The Sieve discussion list, <sieve@ietf.org>
6. Acknowledgments 6. Acknowledgments
The authors thank Alexey Melnikov for significant early feedback and The authors thank Alexey Melnikov for significant early feedback and
suggestions. suggestions.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008. Language", RFC 5228, January 2008.
[RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
"Sieve Email Filtering: Extension for Notifications", "Sieve Email Filtering: Extension for Notifications",
RFC 5435, January 2009. RFC 5435, January 2009.
7.2. Informative References [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", RFC
[I-D.ietf-sieve-autoreply] 6121, March 2011.
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] 7.2. Informative References
Melnikov, A. and B. Leiba, "Sieve Extension: Externally
Stored Lists", draft-ietf-sieve-external-lists-02 (work in
progress), May 2010.
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format W., and J. Peterson, "Presence Information Data Format
(PIDF)", RFC 3863, August 2004. (PIDF)", RFC 3863, August 2004.
[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the Presence Rosenberg, "RPID: Rich Presence Extensions to the Presence
Information Data Format (PIDF)", RFC 4480, July 2006. Information Data Format (PIDF)", RFC 4480, July 2006.
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",
RFC 5229, January 2008. RFC 5229, January 2008.
[RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering:
Vacation Extension", RFC 5230, January 2008. Vacation Extension", RFC 5230, January 2008.
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations", Usage Clarification, Considerations, and Recommendations",
RFC 5491, March 2009. 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 Authors' Addresses
Robins George Robins George
Huawei Technologies Huawei Technologies
Bangalore, Karnataka 560071 Bangalore, Karnataka 560071
India India
Phone: +91-080-41117676 Phone: +91-080-41117676
Email: robinsgv@gmail.com EMail: robinsgv@gmail.com
Barry Leiba Barry Leiba
Huawei Technologies Huawei Technologies
Phone: +1 646 827 0648 Phone: +1 646 827 0648
Email: barryleiba@computer.org EMail: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/ URI: http://internetmessagingtechnology.org/
 End of changes. 39 change blocks. 
117 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/