idnits 2.17.1 draft-ietf-sieve-notify-presence-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (December 15, 2010) is 4874 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3921 (Obsoleted by RFC 6121) == Outdated reference: A later version (-04) exists of draft-ietf-sieve-autoreply-02 == Outdated reference: A later version (-10) exists of draft-ietf-sieve-external-lists-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve working group R. George 3 Internet-Draft B. Leiba 4 Intended status: Standards Track Huawei Technologies 5 Expires: June 18, 2011 December 15, 2010 7 Sieve Notification Using Presence Information 8 draft-ietf-sieve-notify-presence-04 10 Abstract 12 This is a further extension to the Sieve mail filtering language 13 Notification extension, defining presence information that may be 14 checked through the notify_method_capability feature. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on June 18, 2011. 33 Copyright Notice 35 Copyright (c) 2010 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Terminology Used in This Document . . . . . . . . . . . . . . 3 53 2. Testing presence information . . . . . . . . . . . . . . . . 3 55 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 8 65 7.2. Informative References . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 9 69 1. Introduction 71 Sometimes, it's desirable to tailor Sieve [RFC5228] notifications to 72 a user's current situation. Presence information provides some 73 information about the user that would be useful to have access to in 74 these cases. The Notification extension [RFC5435] defines a 75 mechanism to test for presence (the notify_method_capability 76 feature), and defines one test for presence (the "online" 77 notification-capability, described in Section 5 of RFC 5435). This 78 extension defines more presence tests by registering additional 79 notification-capability parameters in the IANA registry, allowing 80 testing of a wider variety of presence information. 82 1.1. Terminology Used in This Document 84 The upper-case key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 85 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 86 "OPTIONAL" in this document are to be interpreted as described in 87 [RFC2119]. 89 2. Testing presence information 91 This extension uses the notify_method_capability test, as defined in 92 the Sieve [RFC5228] Notify extension [RFC5435], to test presence 93 information. When a Sieve event occurs (mail arrives) for a user, a 94 Sieve script running on behalf of that user can present the user's 95 presence URI (in the "notification-uri" parameter) and test a 96 specific item of notification presence as defined below (in the 97 "notification-capability" parameter) against one or more values (in 98 the "key-list" parameter). 100 This document defines an initial set of items of notification 101 presence, which may be specified in the notification-capability 102 parameter. It is expected that future extensions will add additional 103 presence items derived from diverse sources, including calendar 104 information, geographic location, and so on. 106 Note that, while the items below are documented as similar to items 107 in XMPP, it is not the intent that this extension be tied to XMPP, 108 nor to any particular source of presence, and flexible 109 implementations will be ready for future extensions. Useful 110 informational references for presence data and formats include 111 Presence Information Data Format (PIDF) [RFC3863], RPID: Rich 112 Presence Extensions to PIDF [RFC4480], and GEOPRIV Presence 113 Information Data Format Location Object (PIDF-LO) [RFC5491]. 115 The script tests the values of notification presence items in the 116 key- list parameter. The values that each item may have are 117 specified in the list below. Note that in addition to the presence 118 values, any item may have the value "unknown" if it is not possible 119 to determine the correct presence value of the item. 121 If a particular presence item is tested multiple times within the 122 same script execution context, implementations MUST present the same 123 value each time (for example, by caching the value on first use). 124 This provides consistency within a single execution. 126 Supported presence items are as follows: 128 busy - An indication of whether the user is considered "busy" now 129 (the value "yes") or not (the value "no"), or "unknown" if it 130 cannot be determined. The meaning of "busy" is left to the 131 implementation, and may be a state that's synthesized from other 132 information (including "show", below). 134 show - The availability status of the user, formally specified. Note 135 that this is similar to the presence element with the same name 136 that's defined in Section 2.2.2.1 of RFC 3921.[RFC3921] The 137 value of this item is one of the following: 139 away - The user is temporarily away. 141 chat - The user is online and actively interested in chatting. 143 dnd - Do Not Disturb; the user does not wish to be disturbed 144 now. 146 offline - The user is offline. 148 xa - The user is away for an extended period (xa = "eXtended 149 Away"). 151 unknown - The correct presence value could not be determined. 153 status - A human-readable description of the user's availability 154 status, in natural language. There is no formal definition for 155 the values this item may take. It is free-form, and may be in 156 any language. Direct comparisons against the value of this 157 field are unlikely to be useful; rather, it is provided to 158 enable extraction of the value into a variable [RFC5229] for use 159 elsewhere (see example 3 in Section 3). Note that this is 160 similar to the presence element with the same name that's 161 defined in Section 2.2.2.2 of RFC 3921 [RFC3921], and to the 162 element defined in section 4.1.6 of PIDF [RFC3863]. 164 Because this is a free-form value that might be created directly 165 by a user, no value, including "unknown", can have any special 166 meaning. If the Sieve processor is unable to determine the 167 value of this item, it might be best to leave it as an empty 168 string. In any case, it is not meant for machine-readable 169 processing, beyond possible XML interpretation. 171 There is no capability string associated with this extension, but 172 this requires support for "enotify".[RFC5435] If the implementation 173 does not support the item being tested (that is, the specified 174 notification-capability item is not known to the Sieve interpreter), 175 RFC 5435 already specifies that the test fail without an error. 177 Although this feature was conceived to assist in notifications, and 178 the test requires support of the Sieve Notify feature, it is only a 179 condition test, and any Sieve action can appear inside it. There are 180 no Sieve actions that conflict with this extension. 182 3. Examples 184 1. This example will send a notification only if the recipient is 185 not "busy". If the test for "busy" is not supported, this 186 example will not send a notification. 188 require ["enotify"]; 190 if notify_method_capability "xmpp:tim@example.com" "busy" "no" 191 { 192 notify :message "You got mail" 193 "xmpp:tim@example.com?message;subject=SIEVE"; 194 } 196 2. This example will send a notification only if the recipient is 197 not "busy". If the test for "busy" is not supported, this 198 example will send a notification. 200 require ["enotify"]; 202 if not notify_method_capability "xmpp:tim@example.com" "busy" "yes" 203 { 204 notify :message "You got mail" 205 "xmpp:tim@example.com?message;subject=SIEVE"; 207 } 209 3. This example uses the vacation extension [RFC5230] to generate an 210 autoreply [I-D.ietf-sieve-autoreply] if the sender is in the 211 recipient's address book [I-D.ietf-sieve-external-lists] and the 212 recipient's presence shows "extended away". The variables 213 extension [RFC5229] is used to extract the value of the 214 recipient's presence status message, which will be used in the 215 response to the sender. If the test for "show" is not supported, 216 this example will not send an autoreply. 218 require ["extlists", "vacation", "enotify", "variables"]; 220 if allof ( 221 envelope :list "from" "tag:example.com,2009-05-28:mylist", 222 notify_method_capability "xmpp:myjid@example.com" "show" "xa" 223 ) { 224 # :matches "*" is used here to extract the value 225 if notify_method_capability :matches 226 "xmpp:myjid@example.com" "status" "*" { 227 set "resp_msg" "${1}"; 228 } else { 229 set "resp_msg" "I'm away from email for a while." 230 } 231 vacation :handle "ext-away" "${resp_msg}"; 232 } 234 4. Security Considerations 236 Security considerations for Sieve [RFC5228] and the Notify extension 237 [RFC5435] apply equally here. In addition, implementations MUST 238 ensure that users can not create scripts that access the presence 239 information of others without the proper access controls. 241 In some situations, scripts may act on some of the recipient's 242 presence information that the sender of the triggering message is not 243 allowed to see. This can be a benefit to the recipient in many 244 cases, but it can also present an opportunity for a sender to use 245 messages to probe the recipient's presence (if, for example, messages 246 sometimes result in auto-replies, and sometimes do not). Script 247 authors should take care in considering this aspect of presence- 248 triggered actions. 250 It's possible for a large number of messages to arrive at or around 251 the same time and be processed by Sieve scripts that all test 252 presence. If many of the users share the same presence server, such 253 a burst could put an unexpectedly heavy load on the presence server. 254 Implementations might consider providing options for rate limiting, 255 or for caching presence tests for periods of time, even across Sieve 256 script instances. 258 5. IANA Considerations 260 This registers each presence item as a notification-capability 261 parameter. Future extensions that add new presence items should 262 register those items similarly, using the instructions in Section 9.3 263 of RFC 5435.[RFC5435] 265 To: iana@iana.org 266 Subject: Registration of a new notification-capability parameter 267 Capability name: busy 268 Description: An indication of whether the user is considered "busy" 269 now (the value "yes") or not (the value "no"). The meaning of 270 "busy" is left to the implementation, and may be a state that's 271 synthesized from other information. 272 Syntax: Has one of the values "yes", "no", or "unknown". The value 273 MUST be in lower case. 274 Permanent and readily available reference(s): this RFC 275 Contact information: The Sieve discussion list, 277 To: iana@iana.org 278 Subject: Registration of a new notification-capability parameter 279 Capability name: show 280 Description: The availability status of the user. This is similar 281 to the presence element with the same name that's defined in 282 Section 2.2.2.1 of RFC 3921. 283 Syntax: Has one of the values "away", "chat", "dnd", "offline", 284 "xa", or "unknown". The value MUST be in lower case. 285 Permanent and readily available reference(s): this RFC 286 Contact information: The Sieve discussion list, 288 To: iana@iana.org 289 Subject: Registration of a new notification-capability parameter 290 Capability name: status 291 Description: A human-readable description of the user's availability 292 status. This is similar to the presence element with the same 293 name that's defined in Section 2.2.2.2 of RFC 3921. 294 Syntax: There is no formal definition for the values this item may 295 take. It is free-form and may be in any language, and is meant 296 for human consumption. 297 Permanent and readily available reference(s): this RFC 298 Contact information: The Sieve discussion list, 300 6. Acknowledgments 302 The authors thank Alexey Melnikov for significant early feedback and 303 suggestions. 305 7. References 307 7.1. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, March 1997. 312 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 313 Protocol (XMPP): Instant Messaging and Presence", 314 RFC 3921, October 2004. 316 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 317 Language", RFC 5228, January 2008. 319 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 320 "Sieve Email Filtering: Extension for Notifications", 321 RFC 5435, January 2009. 323 7.2. Informative References 325 [I-D.ietf-sieve-autoreply] 326 George, R., Leiba, B., and A. Melnikov, "Sieve Email 327 Filtering: Use of Presence Information with Auto Responder 328 functionality", draft-ietf-sieve-autoreply-02 (work in 329 progress), October 2010. 331 [I-D.ietf-sieve-external-lists] 332 Melnikov, A. and B. Leiba, "Sieve Extension: Externally 333 Stored Lists", draft-ietf-sieve-external-lists-02 (work in 334 progress), May 2010. 336 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 337 W., and J. Peterson, "Presence Information Data Format 338 (PIDF)", RFC 3863, August 2004. 340 [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. 341 Rosenberg, "RPID: Rich Presence Extensions to the Presence 342 Information Data Format (PIDF)", RFC 4480, July 2006. 344 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 345 RFC 5229, January 2008. 347 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 348 Vacation Extension", RFC 5230, January 2008. 350 [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 351 Presence Information Data Format Location Object (PIDF-LO) 352 Usage Clarification, Considerations, and Recommendations", 353 RFC 5491, March 2009. 355 Authors' Addresses 357 Robins George 358 Huawei Technologies 359 Bangalore, Karnataka 560071 360 India 362 Phone: +91-080-41117676 363 Email: robinsgv@gmail.com 365 Barry Leiba 366 Huawei Technologies 368 Phone: +1 646 827 0648 369 Email: barryleiba@computer.org 370 URI: http://internetmessagingtechnology.org/