idnits 2.17.1 draft-george-sieve-notify-presence-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Line 264 has weird spacing: '...sponder funct...' -- The document date (February 4, 2010) is 5188 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) == Outdated reference: A later version (-01) exists of draft-george-sieve-autoreply-00 == Outdated reference: A later version (-02) exists of draft-melnikov-sieve-external-lists-01 -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 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: August 8, 2010 February 4, 2010 7 Sieve Notification Using Presence Information 8 draft-george-sieve-notify-presence-01 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 to IETF 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), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 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 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 8, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology Used in This Document . . . . . . . . . . . . . . 3 59 2. Testing presence information . . . . . . . . . . . . . . . . 3 61 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 7 71 7.2. Informative References . . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Sometimes, it's desirable to tailor Sieve [RFC5228] notifications to 78 a user's current situation. Presence information provides some 79 information about the user that would be useful to have access to in 80 these cases. The Notification extension [RFC5435] defines a 81 mechanism to test for presence (the notify_method_capability 82 feature), and defines one test for presence (the "online" 83 notification-capability, described in Section 5 of RFC 5435). This 84 extension specifies testing of a wider variety of presence 85 information. 87 1.1. Terminology Used in This Document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. Testing presence information 95 This extension uses the "notify_method_capability" test, as defined 96 in the Sieve [RFC5228] Notify extension [RFC5435], to test presence 97 information. When a Sieve event occurs (mail arrives) for a user, a 98 Sieve script running on behalf of that user can present the user's 99 presence URI (in the "notification-uri" parameter) and test a 100 specific item of notification presence as defined below (in the 101 "notification-capability" parameter) against one or more values (in 102 the "key-list" parameter). 104 This document defines the following items of notification presence, 105 which may be specified in the notification-capability parameter: 107 busy - An indication of whether the user is considered "busy" now 108 (the value "yes") or not (the value "no"). The meaning of 109 "busy" is left to the implementation, and may be a state that's 110 synthesized from other information (including "show", below). 112 show - The availability status of the user, formally specified. Note 113 that this is similar to the presence element with the same name 114 that's defined in Section 2.2.2.1 of RFC 3921.[RFC3921] The 115 value of this item is one of the following: 117 away - The user is temporarily away. 119 chat - The user is online and actively interested in chatting. 121 dnd - Do Not Disturb; the user should not be disturbed now. 123 offline - The user is offline. 125 xa - The user is away for an extended period (xa = "eXtended 126 Away"). 128 status - A human-readable description of the user's availability 129 status. There is no formal definition for the values this item 130 may take. It is free-form, and may be in any language. Direct 131 comparisons against the value of this field are unlikely to be 132 useful; rather, it is provided to enable extraction of the value 133 into a variable [RFC5229] for use elsewhere (see example 3 in 134 Section 3). Note that this is similar to the presence element 135 with the same name that's defined in Section 2.2.2.2 of RFC 136 3921.[RFC3921] 138 The script tests the values of notification presence items in the 139 key-list parameter. The values that each item may have are specified 140 in the list above; in addition, any item may have the value 141 "unknown", if it is not possible to determine the correct value of 142 the item. 144 There is no capability string associated with this extension, but 145 this requires support for "enotify".[RFC5435] If the implementation 146 does not support the item being tested, RFC 5435 already specifies 147 that the test must fail without an error. 149 Although this feature was conceived to assist in notifications, and 150 the test requires support of the Sieve Notify feature, it is only a 151 condition test, and any Sieve action can appear inside it. There are 152 no Sieve actions that conflict with this extension. 154 3. Examples 156 1. This example will send a notification only if the recipient is 157 not "busy". If the test for "busy" is not supported, this 158 example WILL NOT send a notification. 160 require ["enotify"]; 162 if notify_method_capability "xmpp:tim@example.com" "busy" "no" 163 { 164 notify :message "You got mail" 165 "xmpp:tim@example.com?message;subject=SIEVE"; 166 } 168 2. This example will send a notification only if the recipient is 169 not "busy". If the test for "busy" is not supported, this 170 example WILL send a notification. 172 require ["enotify"]; 174 if not notify_method_capability "xmpp:tim@example.com" "busy" "yes" 175 { 176 notify :message "You got mail" 177 "xmpp:tim@example.com?message;subject=SIEVE"; 178 } 180 3. This example uses the vacation extension [RFC5230] to generate an 181 autoreply [I-D.george-sieve-autoreply] if the sender is in the 182 recipient's address book [I-D.melnikov-sieve-external-lists] and 183 the recipient's presence shows "extended away". The variables 184 extension [RFC5229] is used to extract the value of the 185 recipient's presence status message, which will be used in the 186 response to the sender. If the test for "show" is not supported, 187 this example WILL NOT send an autoreply. 189 require ["extlists", "vacation", "enotify", "variables"]; 191 if allof ( 192 envelope :list "from" "tag:example.com,2009-05-28:mylist", 193 notify_method_capability "xmpp:myjid@example.com" "show" "xa" 194 ) { 195 # :matches "*" is used here to extract the value 196 if notify_method_capability :matches 197 "xmpp:myjid@example.com" "status" "*" { 198 set "resp_msg" "${1}"; 199 } else { 200 set "resp_msg" "I'm away from email for a while." 201 } 202 vacation :handle "ext-away" "${resp_msg}"; 203 } 205 4. Security Considerations 207 Security considerations for Sieve [RFC5228] and the Notify extension 208 [RFC5435] apply equally here. In addition, implementations MUST 209 ensure that users can not create scripts that access the presence 210 information of others without the proper access controls. 212 5. IANA Considerations 214 This registers each presence item as a notification-capability 215 parameter. Future extensions that add new presence items should 216 register those items similarly, using the instructions in Section 9.3 217 of RFC 5435.[RFC5435] 219 To: iana@iana.org 220 Subject: Registration of a new notification-capability parameter 221 Capability name: busy 222 Description: An indication of whether the user is considered "busy" 223 now (the value "yes") or not (the value "no"). The meaning of 224 "busy" is left to the implementation, and may be a state that's 225 synthesized from other information. 226 Syntax: Has one of the values "yes", "no", or "unknown". The value 227 MUST be in lower case. 228 Permanent and readily available reference(s): this RFC 229 Contact information: The Sieve discussion list, 231 To: iana@iana.org 232 Subject: Registration of a new notification-capability parameter 233 Capability name: show 234 Description: The availability status of the user. This is similar 235 to the presence element with the same name that's defined in 236 Section 2.2.2.1 of RFC 3921. 237 Syntax: Has one of the values "away", "chat", "dnd", "offline", 238 "xa", or "unknown". The value MUST be in lower case. 239 Permanent and readily available reference(s): this RFC 240 Contact information: The Sieve discussion list, 242 6. Acknowledgments 244 The authors thank Alexey Melnikov for significant early feedback and 245 suggestions. 247 7. References 248 7.1. Normative References 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, March 1997. 253 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 254 Language", RFC 5228, January 2008. 256 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 257 "Sieve Email Filtering: Extension for Notifications", 258 RFC 5435, January 2009. 260 7.2. Informative References 262 [I-D.george-sieve-autoreply] 263 George, R. and A. Melnikov, "Sieve Email Filtering: Use of 264 Presence Information with Auto Responder functionality", 265 draft-george-sieve-autoreply-00 (work in progress), 266 June 2009. 268 [I-D.melnikov-sieve-external-lists] 269 Melnikov, A., "Sieve Extension: Externally Stored Lists", 270 draft-melnikov-sieve-external-lists-01 (work in progress), 271 July 2007. 273 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 274 Protocol (XMPP): Instant Messaging and Presence", 275 RFC 3921, October 2004. 277 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 278 RFC 5229, January 2008. 280 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 281 Vacation Extension", RFC 5230, January 2008. 283 Authors' Addresses 285 Robins George 286 Huawei Technologies 287 Huawei Base, Bantian, Longgang District 288 Shenzhen, Guangdong 518129 289 P. R. China 291 Phone: +86-755-28788314 292 Email: robinsg@huawei.com 293 Barry Leiba 294 Huawei Technologies 296 Phone: +1 646 827 0648 297 Email: barryleiba@computer.org 298 URI: http://internetmessagingtechnology.org/