idnits 2.17.1 draft-ietf-sieve-notify-presence-00.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 date (June 23, 2010) is 5054 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 (-04) exists of draft-ietf-sieve-autoreply-00 == Outdated reference: A later version (-10) exists of draft-ietf-sieve-external-lists-02 -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) Summary: 0 errors (**), 0 flaws (~~), 3 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: December 25, 2010 June 23, 2010 7 Sieve Notification Using Presence Information 8 draft-ietf-sieve-notify-presence-00 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 December 25, 2010. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . . 7 65 7.2. Informative References . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 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 specifies testing of a wider variety of presence 79 information. 81 1.1. Terminology Used in This Document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC2119]. 87 2. Testing presence information 89 This extension uses the "notify_method_capability" test, as defined 90 in the Sieve [RFC5228] Notify extension [RFC5435], to test presence 91 information. When a Sieve event occurs (mail arrives) for a user, a 92 Sieve script running on behalf of that user can present the user's 93 presence URI (in the "notification-uri" parameter) and test a 94 specific item of notification presence as defined below (in the 95 "notification-capability" parameter) against one or more values (in 96 the "key-list" parameter). 98 This document defines the following items of notification presence, 99 which may be specified in the notification-capability parameter: 101 busy - An indication of whether the user is considered "busy" now 102 (the value "yes") or not (the value "no"). The meaning of 103 "busy" is left to the implementation, and may be a state that's 104 synthesized from other information (including "show", below). 106 show - The availability status of the user, formally specified. Note 107 that this is similar to the presence element with the same name 108 that's defined in Section 2.2.2.1 of RFC 3921.[RFC3921] The 109 value of this item is one of the following: 111 away - The user is temporarily away. 113 chat - The user is online and actively interested in chatting. 115 dnd - Do Not Disturb; the user should not be disturbed now. 117 offline - The user is offline. 119 xa - The user is away for an extended period (xa = "eXtended 120 Away"). 122 status - A human-readable description of the user's availability 123 status. There is no formal definition for the values this item 124 may take. It is free-form, and may be in any language. Direct 125 comparisons against the value of this field are unlikely to be 126 useful; rather, it is provided to enable extraction of the value 127 into a variable [RFC5229] for use elsewhere (see example 3 in 128 Section 3). Note that this is similar to the presence element 129 with the same name that's defined in Section 2.2.2.2 of RFC 130 3921.[RFC3921] 132 The script tests the values of notification presence items in the 133 key-list parameter. The values that each item may have are specified 134 in the list above; in addition, any item may have the value 135 "unknown", if it is not possible to determine the correct value of 136 the item. 138 There is no capability string associated with this extension, but 139 this requires support for "enotify".[RFC5435] If the implementation 140 does not support the item being tested, RFC 5435 already specifies 141 that the test must fail without an error. 143 Although this feature was conceived to assist in notifications, and 144 the test requires support of the Sieve Notify feature, it is only a 145 condition test, and any Sieve action can appear inside it. There are 146 no Sieve actions that conflict with this extension. 148 3. Examples 150 1. This example will send a notification only if the recipient is 151 not "busy". If the test for "busy" is not supported, this 152 example WILL NOT send a notification. 154 require ["enotify"]; 156 if notify_method_capability "xmpp:tim@example.com" "busy" "no" 157 { 158 notify :message "You got mail" 159 "xmpp:tim@example.com?message;subject=SIEVE"; 160 } 162 2. This example will send a notification only if the recipient is 163 not "busy". If the test for "busy" is not supported, this 164 example WILL send a notification. 166 require ["enotify"]; 168 if not notify_method_capability "xmpp:tim@example.com" "busy" "yes" 169 { 170 notify :message "You got mail" 171 "xmpp:tim@example.com?message;subject=SIEVE"; 172 } 174 3. This example uses the vacation extension [RFC5230] to generate an 175 autoreply [I-D.ietf-sieve-autoreply] if the sender is in the 176 recipient's address book [I-D.ietf-sieve-external-lists] and the 177 recipient's presence shows "extended away". The variables 178 extension [RFC5229] is used to extract the value of the 179 recipient's presence status message, which will be used in the 180 response to the sender. If the test for "show" is not supported, 181 this example WILL NOT send an autoreply. 183 require ["extlists", "vacation", "enotify", "variables"]; 185 if allof ( 186 envelope :list "from" "tag:example.com,2009-05-28:mylist", 187 notify_method_capability "xmpp:myjid@example.com" "show" "xa" 188 ) { 189 # :matches "*" is used here to extract the value 190 if notify_method_capability :matches 191 "xmpp:myjid@example.com" "status" "*" { 192 set "resp_msg" "${1}"; 193 } else { 194 set "resp_msg" "I'm away from email for a while." 195 } 196 vacation :handle "ext-away" "${resp_msg}"; 197 } 199 4. Security Considerations 201 Security considerations for Sieve [RFC5228] and the Notify extension 202 [RFC5435] apply equally here. In addition, implementations MUST 203 ensure that users can not create scripts that access the presence 204 information of others without the proper access controls. 206 5. IANA Considerations 208 This registers each presence item as a notification-capability 209 parameter. Future extensions that add new presence items should 210 register those items similarly, using the instructions in Section 9.3 211 of RFC 5435.[RFC5435] 213 To: iana@iana.org 214 Subject: Registration of a new notification-capability parameter 215 Capability name: busy 216 Description: An indication of whether the user is considered "busy" 217 now (the value "yes") or not (the value "no"). The meaning of 218 "busy" is left to the implementation, and may be a state that's 219 synthesized from other information. 220 Syntax: Has one of the values "yes", "no", or "unknown". The value 221 MUST be in lower case. 222 Permanent and readily available reference(s): this RFC 223 Contact information: The Sieve discussion list, 225 To: iana@iana.org 226 Subject: Registration of a new notification-capability parameter 227 Capability name: show 228 Description: The availability status of the user. This is similar 229 to the presence element with the same name that's defined in 230 Section 2.2.2.1 of RFC 3921. 231 Syntax: Has one of the values "away", "chat", "dnd", "offline", 232 "xa", or "unknown". The value MUST be in lower case. 233 Permanent and readily available reference(s): this RFC 234 Contact information: The Sieve discussion list, 236 6. Acknowledgments 238 The authors thank Alexey Melnikov for significant early feedback and 239 suggestions. 241 7. References 242 7.1. Normative References 244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 245 Requirement Levels", BCP 14, RFC 2119, March 1997. 247 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 248 Language", RFC 5228, January 2008. 250 [RFC5435] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, 251 "Sieve Email Filtering: Extension for Notifications", 252 RFC 5435, January 2009. 254 7.2. Informative References 256 [I-D.ietf-sieve-autoreply] 257 George, R., Leiba, B., and A. Melnikov, "Sieve Email 258 Filtering: Use of Presence Information with Auto Responder 259 functionality", draft-ietf-sieve-autoreply-00 (work in 260 progress), June 2010. 262 [I-D.ietf-sieve-external-lists] 263 Melnikov, A. and B. Leiba, "Sieve Extension: Externally 264 Stored Lists", draft-ietf-sieve-external-lists-02 (work in 265 progress), May 2010. 267 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 268 Protocol (XMPP): Instant Messaging and Presence", 269 RFC 3921, October 2004. 271 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 272 RFC 5229, January 2008. 274 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 275 Vacation Extension", RFC 5230, January 2008. 277 Authors' Addresses 279 Robins George 280 Huawei Technologies 281 Huawei Base, Bantian, Longgang District 282 Shenzhen, Guangdong 518129 283 P. R. China 285 Phone: +86-755-28788314 286 Email: robinsg@huawei.com 287 Barry Leiba 288 Huawei Technologies 290 Phone: +1 646 827 0648 291 Email: barryleiba@computer.org 292 URI: http://internetmessagingtechnology.org/