idnits 2.17.1 draft-ietf-sieve-notify-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 421. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 428. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 434. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 4, 2006) is 6649 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 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov, Ed. 3 Internet-Draft Isode Limited 4 Expires: August 8, 2006 B. Leiba, Ed. 5 W. Segmuller 6 IBM T.J. Watson Research Center 7 T. Martin 8 Mirapoint Inc. 9 February 4, 2006 11 Sieve Extension: Notifications 12 draft-ietf-sieve-notify-02 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of 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, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 Users go to great lengths to be notified as quickly as possible that 46 they have received new mail. Most of these methods involve polling 47 to check for new messages periodically. A push method handled by the 48 final delivery agent gives users quicker notifications and saves 49 server resources. This document does not specify the notification 50 method but is expected that using existing instant messaging 51 infrastructure such as Zephyr, Jabber, or SMS messages will be 52 popular. This draft describes an extension to the Sieve mail 53 filtering language that allows users to give specific rules for how 54 and when notifications should be sent. 56 Note 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1 Conventions used in this document . . . . . . . . . . . . . 3 63 2. Capability Identifier . . . . . . . . . . . . . . . . . . . 4 65 3. Notify Action . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1 Notify Action Syntax and Semantics . . . . . . . . . . . . . 5 67 3.2 Notify tag ":method" . . . . . . . . . . . . . . . . . . . . 5 68 3.3 Notify tag ":priority" . . . . . . . . . . . . . . . . . . . 6 69 3.4 Notify tag ":message" . . . . . . . . . . . . . . . . . . . 6 70 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4. Test valid_notif_method . . . . . . . . . . . . . . . . . . 9 74 5. Interactions with Other Sieve Actions . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . 11 78 7. Extensions to ManageSieve protocol . . . . . . . . . . . . . 12 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 86 10.2 Non-Normative References . . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 90 Intellectual Property and Copyright Statements . . . . . . . 17 92 1. Introduction 94 This is an extension to the Sieve language defined by [Sieve] for 95 providing instant notifications. It defines the new action "notify". 97 This document does not dictate the notification method used. 98 Examples of possible notification methods are Zephyr and Jabber. The 99 available methods shall be site-defined. 101 1.1 Conventions used in this document 103 Conventions for notations are as in [Sieve] section 1.1, including 104 the use of [Kwds] and the use of [ABNF]. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [Kwds]. 110 2. Capability Identifier 112 The capability string associated with the extension defined in this 113 document is "notify". 115 3. Notify Action 117 3.1 Notify Action Syntax and Semantics 119 Usage: notify [":method" string] 120 [":priority" <"1" / "2" / "3">] 121 [":message" string] 123 The Notify action specifies that a notification should be sent to the 124 user. The format of the notification is implementation-defined and 125 is also affected by the notification method used (see below). 126 However, all content specified in the notify action SHOULD be 127 included. It is RECOMMENDED that a timestamp be included in the 128 notification. Implementations SHOULD NOT include extraneous 129 information. 131 If there are errors sending the notification, the Sieve interpreter 132 SHOULD ignore the notification and not retry indefinitely. 133 [[Barry 4: Does this really belong here? Shouldn't we push the 134 question of error recovery to the individual methods?]] 136 3.2 Notify tag ":method" 138 The :method tag identifies the notification method that will be used; 139 it is a URI. For example, the notification method can be an SMS URI 140 [SMS-URI] containing a phone number, or an XMPP [XMPP] URI containing 141 a Jabber identifier [XMPP-URI]. If the :method tag is not specified, 142 a default implementation-defined notification method is used, and if 143 there is no default method defined, the notification is ignored. 144 Implementations MUST NOT generate an error condition for lack of a 145 default notification method, and execution of the script MUST 146 continue. 148 The supported URI values will be site-specific. If an URI schema is 149 specified that the implementation does not support, the notification 150 MUST cause an error condition. Sieve scripts can check the supported 151 methods using the "valid_notif_method" test to be sure that they only 152 use supported ones, to avoid such error conditions. If the :method 153 tag contains a supported URI schema, then the URI MUST be checked for 154 syntactic validity. An invalid URI syntax or an unsupported URI 155 extension MUST cause an error. An implementation MAY enforce other 156 semantic restrictions on URIs -- for example an SMS URI can only 157 contain phone numbers in a particular geographical region. Violation 158 of such semantic restrictions MUST also cause an error. 159 [[Barry 1: "MUST" seems silly here, since the whole sentence is a 160 "MAY".]] 162 3.3 Notify tag ":priority" 164 The :priority tag specifies the importance of the notification. The 165 :priority tag is followed by a numeric value represented as a string: 166 "1" (high importance), "2" (normal importance), and "3" (low 167 importance). If no priority is given, a default priority of "2" 168 SHOULD be assumed. Some notification methods allow users to specify 169 their state of activity (for example "busy" or "away from keyboard"). 170 If the notification method provides this information it SHOULD be 171 used to selectively send notifications. If, for example, the user 172 marks herself as "busy", a notification method can require that a 173 notification with a priority of "3" is not to be sent, however the 174 user should be notified of a higher priority notifications. If the 175 notification method allows users to filter messages based upon 176 certain parameters in the message, users SHOULD be able to filter 177 based upon priority. If the notification method does not support 178 priority, then this parameter MUST be ignored. 179 [[Alexey 1: Should we keep using "high", "normal" and "low" 180 instead?]] 181 [[Barry 3.5: Why do we call this "priority", and then explain it as 182 "importance"? Shouldn't we just call it "importance"?]] 184 3.4 Notify tag ":message" 186 The :message tag specifies the message data to be included in the 187 notification. The entirety of the string SHOULD be sent but 188 implementations MAY shorten the message for technical or aesthetic 189 reasons. If the message parameter is absent, a default message 190 containing the value of the From header field and the value of the 191 Subject header field will be used. Note that the notification method 192 (the ":method" tag) may affect how this information is formatted. 194 The implementation of a notification method MAY modify the final 195 notification text -- for example, truncating it if it exceeds a 196 length limit, or modifying characters that can not be represented in 197 the target character set. Allowed modifications should be documented 198 in a standards-track or informational document. 200 In order to construct more complex messages the notify extension can 201 be used together with the Sieve variables extension [Variables], as 202 shown in the examples below. 204 [[Note 2: Open issue:]] The previous version of this draft has 205 defined the two variables that can't be currently represented: 207 $text$ - the first text/* part 208 $text[n]$ - the first n bytes of the first text/* part 210 3.5 Examples 212 Example 1: 213 require ["notify", "fileinto", "variables"]; 215 if header :contains "from" "boss@example.org" { 216 notify :priority "1" 217 :message "This is probably very important"; 218 # Don't send any further notifications 219 stop; 220 } 222 if header :contains "to" "sievemailinglist@example.org" { 223 # :matches is used to get the value of the Subject header 224 if header :matches "Subject" "*" { 225 set "subject" "${1}"; 226 } 228 # :matches is used to get the value of the From header 229 if header :matches "From" "*" { 230 set "from" "${1}"; 231 } 233 notify :priority "3" 234 :message "[SIEVE] ${from}: ${subject}"; 235 fileinto "INBOX.sieve"; 236 } 238 Example 2: 239 require ["notify", "fileinto", "variables", "envelope"]; 241 if header :matches "from" "*@*.example.org" { 242 # :matches is used to get the MAIL FROM address 243 if envelope :all :matches "from" "*" { 244 set "env_from" " [really: ${1}]"; 245 } 247 # :matches is used to get the value of the Subject header 248 if header :matches "Subject" "*" { 249 set "subject" "${1}"; 250 } 252 # :matches is used to get the address from the From header 253 if address :matches :all "from" "*" { 254 set "from_addr" "${1}"; 255 } 257 notify :message "${from_addr}${env_from}: ${subject}"; 258 } 260 4. Test valid_notif_method 262 Usage: valid_notif_method 264 The "valid_notif_method" test is true if the notification methods 265 listed in the notification-uris argument are supported and they are 266 syntactically and semantically valid. All of the notification 267 methods must be supported and valid or the test is false. 269 [[Alexey 2: The text must be clear that this test performs exactly 270 the same checks as done during notify :method parameter 271 verificiation.]] 273 Example: if valid_notif_method ["mailto:", 274 "http://gw.example.net/notify?test"] { 275 stop; 276 } 278 5. Interactions with Other Sieve Actions 280 The notify action is compatible with all other actions, and does not 281 affect the operation of other actions. In particular, the notify 282 action MUST NOT cancel the implicit keep. 284 Multiple executed notify actions are allowed. 285 [[Note 3: Add text about suppression of identical notifications.]] 287 6. Security Considerations 289 Security considerations are discussed in [Sieve]. Additionally, 290 implementations must be careful to follow the security considerations 291 of the specific notification methods. 293 The notify action is potentially very dangerous. The path the 294 notification takes through the network may not be secure. An error 295 in the options string may cause the message to be transmitted to 296 someone it was not intended for, or may expose information to 297 eavesdroppers. 299 Just because a notification is received doesn't mean it was sent by 300 the Sieve implementation. It might be possible to forge 301 notifications with some notification methods. 303 7. Extensions to ManageSieve protocol 305 A ManageSieve [ManageSieve] server that supports the "notify" 306 extension MUST advertise the NOTIFY capability, that has a single 307 mandatory parameter. The parameter is a string containing space 308 separated list of URI schema parts for supported nofication methods. 310 Example: 311 S: "NOTIFY" "xmpp mailto" 313 8. IANA Considerations 315 The following template specifies the IANA registration of the 316 variables Sieve extension specified in this document: 318 To: iana@iana.org 319 Subject: Registration of new Sieve extension 320 Capability name: notify 321 Capability keyword: notify 322 Capability arguments: N/A 323 Standards Track/IESG-approved experimental RFC number: this RFC 324 Person and email address to contact for further information: 325 Alexey Melnikov 327 This information should be added to the list of sieve extensions 328 given on http://www.iana.org/assignments/sieve-extensions. 330 9. Acknowledgements 332 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus 333 Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. 334 Mallett and Ned Freed for help with this document. 336 10. References 338 10.1 Normative References 340 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 341 Specifications: ABNF", RFC 4234, October 2005. 343 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", RFC 2119, March 1997. 346 [ManageSieve] 347 Martin, T. and A. Melnikov, "A Protocol for Remotely 348 Managing Sieve Scripts", work in 349 progress, draft-martin-managesieve, February 2006. 351 [Sieve] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 352 Language", work in progress, draft-ietf-sieve-3028bis, 353 July 2005. 355 10.2 Non-Normative References 357 [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short 358 Message Service", work in progress, draft-wilde-sms-uri, 359 August 2005. 361 [Variables] 362 Homme, K., "Sieve Extension: Variables", work in 363 progress, draft-ietf-sieve-variables, October 2005. 365 [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence 366 Protocol (XMPP): Core", RFC 3920, October 2004. 368 [XMPP-URI] 369 Saint-Andre, P., "Internationalized Resource Identifiers 370 (IRIs) and Uniform Resource Identifiers (URIs) for the 371 Extensible Messaging and Presence Protocol (XMPP)", work 372 in progress, draft-saintandre-xmpp-iri, September 2005. 374 Authors' Addresses 376 Alexey Melnikov (editor) 377 Isode Limited 378 5 Castle Business Village 379 36 Station Road 380 Hampton, Middlesex TW12 2BX 381 UK 383 Email: Alexey.Melnikov@isode.com 385 Barry Leiba (editor) 386 IBM T.J. Watson Research Center 387 19 Skyline Drive 388 Hawthorne, NY 10532 389 US 391 Phone: +1 914 784 7941 392 Email: leiba@watson.ibm.com 394 Wolfgang Segmuller 395 IBM T.J. Watson Research Center 396 19 Skyline Drive 397 Hawthorne, NY 10532 398 US 400 Phone: +1 914 784 7408 401 Email: werewolf@us.ibm.com 403 Tim Martin 404 Mirapoint Inc. 405 909 Hermosa Court 406 Sunnyvale, CA 94085 407 US 409 Phone: +1 409 720 3835 410 Email: tmartin@mirapoint.com 412 Intellectual Property Statement 414 The IETF takes no position regarding the validity or scope of any 415 Intellectual Property Rights or other rights that might be claimed to 416 pertain to the implementation or use of the technology described in 417 this document or the extent to which any license under such rights 418 might or might not be available; nor does it represent that it has 419 made any independent effort to identify any such rights. Information 420 on the procedures with respect to rights in RFC documents can be 421 found in BCP 78 and BCP 79. 423 Copies of IPR disclosures made to the IETF Secretariat and any 424 assurances of licenses to be made available, or the result of an 425 attempt made to obtain a general license or permission for the use of 426 such proprietary rights by implementers or users of this 427 specification can be obtained from the IETF on-line IPR repository at 428 http://www.ietf.org/ipr. 430 The IETF invites any interested party to bring to its attention any 431 copyrights, patents or patent applications, or other proprietary 432 rights that may cover technology that may be required to implement 433 this standard. Please address the information to the IETF at 434 ietf-ipr@ietf.org. 436 Disclaimer of Validity 438 This document and the information contained herein are provided on an 439 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 440 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 441 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 442 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 443 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 444 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 446 Copyright Statement 448 Copyright (C) The Internet Society (2006). This document is subject 449 to the rights, licenses and restrictions contained in BCP 78, and 450 except as set forth therein, the authors retain all their rights. 452 Acknowledgment 454 Funding for the RFC Editor function is currently provided by the 455 Internet Society.