idnits 2.17.1 draft-ietf-sieve-notify-01.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 12. -- Found old boilerplate from RFC 3978, Section 5.5 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 399. ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 441 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 13 instances of too long lines in the document, the longest one being 10 characters in excess of 72. 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 (October 2005) is 6767 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) == Unused Reference: 'ABNF' is defined on line 330, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- No information found for draft-ietf-sieve-3028bis-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SIEVE' -- No information found for draft-ietf-sieve-variables-XX - is the name correct? -- No information found for draft-saintandre-xmpp-uri-XX - is the name correct? -- No information found for draft-wilde-sms-uri-XX - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Alexey Melnikov 2 Document: draft-ietf-sieve-notify-01.txt Editor 3 Expires: April 2006 October 2005 5 Sieve -- An extension for providing instant notifications 7 Status of this Memo 9 By submitting this Internet-Draft, each author represents that any 10 applicable patent or other IPR claims of which he or she is aware 11 have been or will be disclosed, and any of which he or she becomes 12 aware will be disclosed, in accordance with Section 6 of BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in 23 progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). 37 Abstract 39 Users go to great lengths to be notified as quickly as possible that 40 they have received new mail. Most of these methods involve polling 41 to check for new messages periodically. A push method handled by the 42 final delivery agent gives users quicker notifications and saves 43 server resources. This document does not specify the notification 44 method but is expected that using existing instant messaging 45 infrastructure such as Zephyr, Jabber, or SMS messages will be popular. 46 This draft describes an extension to the Sieve mail filtering 47 language that allows users to give specific rules for how and when 48 notifications should be sent. 50 1. Introduction 52 This is an extension to the Sieve language defined by [SIEVE] for 53 providing instant notifications. It defines the new action "notify". 55 This document does not dictate the notification method used. 56 Examples of possible notification methods are Zephyr and Jabber. The 57 available method shall be site-defined. 59 Conventions for notations are as in [SIEVE] section 1.1, including 60 use of [KEYWORDS]. 62 1.1. Conventions Used in This Document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [KEYWORDS]. 67 2. Capability Identifier 69 The capability string associated with the extension defined in this 70 document is "notify". 72 3. Actions 74 3.1. Notify action 76 Usage: notify [":method" string] 77 [":id" string] 78 [":priority" <"1" / "2" / "3">] 79 [":message" string] 81 The Notify action specifies that a notification should be sent to 82 the user upon successful handling of this message. 84 The format of the notification is implementation-defined and 85 is also affected by the notification method used (see below). However, 86 all content specified in the notify action SHOULD be included. 87 It is RECOMMENDED that a timestamp is included in the notification. 88 Implementations SHOULD NOT include extraneous information. 90 The :method tag identifies the notification method that will be 91 used, it is an URI. For examples, the notification method can 92 be an SMS URI [SMS-URI] containing a phone number, or an XMPP [XMPP] 93 URI containing Jabber identifier [XMPP-URI]. 94 If the :method tag is not specified, the default 95 implementation defined notification method is used. The 96 possible values of this will be site-specific. If an URI schema is 97 specified that the implementation does not support, the notification 98 MUST be ignored. An implementation may treat this as a warning 99 condition (e.g. it may log a warning), however this is not 100 a fatal error and execution of the SIEVE script MUST continue. 101 If the :method tag contains a supported URI schema, then the URI MUST 102 be checked for syntactic validity. An invalid URI syntax or an unsupported URI 103 extension MUST cause an error. An implementation MAY enforce 104 other semantical restrictions on URIs, for example an SMS URI can only 105 contain phone numbers in a particular geographical reason. Violation 106 of such semantical restrictions MUST also cause an error. 108 The :id tag can be used to give the notify action an unique 109 identifier. This identifier can be used later in the script to 110 cancel the specific notify. The string may have any value and SHOULD 111 NOT be included in the notification. 113 The :priority tag specifies the importance of the notification. 114 The :priority tag is followed by a numeric value represented 115 as a string: "1" (very important), "2" (normal importance), 116 and "3" (not very important). If no priority is given, 117 a default priority of "2" SHOULD be 118 assumed. Some notification methods allow users to specify their 119 state of activity (for example "busy" or "away from keyboard"). If 120 the notification method provides this information it SHOULD be used 121 to selectively send notifications. If, for example, the user marks 122 herself as "busy", an implementation SHOULD NOT send a notification 123 for a new mailing list message with a priority of "3", however the 124 user should be notified of a high priority action. If the 125 notification method allows users to filter messages based upon 126 certain parameters in the message, users should be able to filter 127 based upon priority. If the notification method does not support 128 priority, then this parameter MUST be ignored. 129 <> 131 The :message tag specifies the message data to be included in the 132 notification. The entirety of the string SHOULD be sent but 133 implementations MAY shorten the message for technical or aesthetic 134 reasons. If the message parameter is absent, a default message 135 containing the value of the From header field and the value of the 136 Subject header field will be used. Note that the notification 137 method (the ":method" tag) may affect how this information is 138 formatted. 139 The implementation of a notification method MAY modify the 140 final notification, e.g. truncating it, if it exceeds a length limit, 141 or modify characters that can not be represented in the 142 target character set. Allowed modifications should be documented 143 in a standard track or an informational document. 145 In order to construct more complex messages 146 the notify extension can be used together with the Sieve variables 147 extension [VARIABLES], as shown at the end of this section. 149 <> 157 If there are errors sending the notification, the Sieve interpreter 158 SHOULD ignore the notification and not retry indefinitely. 160 This action MUST NOT cancel the implicit keep. 162 Example: 163 require ["notify", "fileinto", "variables"]; 165 if header :contains "from" "boss@example.org" { 166 notify :priority "1" :message "This is probably very important"; 167 # Don't send any further notifications 168 stop; 169 } 171 if header :contains "to" "sievemailinglist@example.org" { 172 # :matches is used to get the value of the Subject header 173 if header :matches "Subject" "*" { 174 set "subject" "${1}"; 175 } 177 # :matches is used to get the value of the From header 178 if header :matches "From" "*" { 179 set "from" "${1}"; 180 } 182 notify :priority "3" :message "[SIEVE] ${from}: ${subject}"; 183 fileinto "INBOX.sieve"; 184 } 186 Example: 187 require ["notify", "fileinto", "variables", "envelope"]; 189 if header :matches "from" "*@*.example.org" { 190 # :matches is used to get the MAIL FROM address 191 if envelope :all :matches "from" "*" { 192 set "env_from" " [really: ${1}]"; 193 } 195 # :matches is used to get the value of the Subject header 196 if header :matches "Subject" "*" { 197 set "subject" "${1}"; 198 } 200 # :matches is used to get the address from the From header 201 if address :matches :all "from" "*" { 202 set "from_addr" "${1}"; 203 } 205 notify :message "${from_addr}${env_from}: ${subject}"; 206 } 208 3.2. Denotify Action 210 Usage: denotify [MATCH-TYPE string] [":priority" <"1" / "2" / "3">] 212 The denotify action can be used to cancel previous notifications. 213 If the priority is specified, then 214 only cancel those notifications with the specified priority. If a 215 MATCH-TYPE with a string is specified, then only those notifications 216 whose :id tag matches the specified string using the match-type 217 operator are canceled. The ascii-casemap comparator MUST be used. 219 If no notifications exist that match the search criteria, then the 220 denotify has no effect. A denotify only cancels notifications that 221 have already been requested. It is not possible to preemptively 222 cancel a notification. 224 The sequence: 226 denotify; 227 notify; 229 will still generate a notification. The denotify does not cancel 230 the notify. 232 The following table shows which notifies would get cancelled: 234 # what is cancelled 235 denotify # all notifications 236 denotify :matches "*" # all notifications with :id tag 237 denotify :priority "1" # all high priority notifications 238 denotify :is "foobar" # all notifications with id "foobar" 239 denotify :matches "foo*" :priority "2" # all normal priority 240 # notifications with id that 241 # starts with "foo" 243 Example: 245 require ["notify", "variables"]; 247 notify :method "xmpp:tim@example.com?You%20got%20mail&subject=SIEVE" 248 :id "foobar"; 250 if header :contains "from" "boss@example.org" { 251 # :matches is used to get the value of the Subject header 252 if header :matches "Subject" "*" { 253 set "subject" "${1}"; 254 } 256 notify :method "sms:+14085551212" :id "foobar" 257 :priority "1" :message "BOSS: ${subject}"; 258 } 260 if header :contains "to" "sievemailinglist@example.org" { 261 denotify :is "foobar"; 262 } 264 if header :contains "subject" "FYI:" { 265 # don't need high priority notification for 266 # a 'for your information' 267 denotify :is "foobar" :priority "1"; 268 } 270 4. Interaction with Other Sieve Actions 272 The notify action MUST NOT cancel the implicit keep. 274 The notify action is compatible with all actions. 275 Multiple executed notify actions are allowed. 276 <> 278 The denotify action MUST NOT affect any actions other than the 279 notify action. 281 5. Security Considerations 283 Security considerations are discussed in [SIEVE]. Additionally 284 implementations must be careful to follow the security 285 considerations of the specific notification methods. It is believed 286 that this extension does not introduce any additional security 287 concerns. 289 The notify action is potentially very dangerous. The path the 290 notification takes through the network may not be secure. An error 291 in the options string may cause the message to be transmitted to 292 someone it was not intended for. 294 Just because a notification is received doesn't mean it was sent by 295 the sieve implementation. It might be possible to forge 296 notifications with some notification methods. 298 6. IANA Considerations 300 The following template specifies the IANA registration of the 301 variables Sieve extension specified in this document: 303 To: iana@iana.org 304 Subject: Registration of new Sieve extension 305 Capability name: notify 306 Capability keyword: notify 307 Capability arguments: N/A 308 Standards Track/IESG-approved experimental RFC number: 309 this RFC 310 Person and email address to contact for further information: 311 Alexey Melnikov 313 This information should be added to the list of sieve extensions 314 given on http://www.iana.org/assignments/sieve-extensions. 316 7. Acknowledgments 318 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Barry 319 Leiba, Cyrus Daboo, Nigel Swinson, Kjetil Torgrim Homme, 320 Michael Haardt, Mark E. Mallett and Ned Freed for help with 321 this document. 323 8. References 325 8.1. Normative References 327 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 331 Specifications: ABNF", RFC 4234, October 2005. 333 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 334 Language", work in progress, draft-ietf-sieve-3028bis-XX.txt. 336 8.2. Informative References 338 [VARIABLES] Homme, K., "Sieve Extension: Variables", work in 339 progress, draft-ietf-sieve-variables-XX.txt. 341 [XMPP] 343 [XMPP-URI] Saint-Andre, P., "A Uniform Resource Identifier (URI) 344 Scheme for the Extensible Messaging and Presence Protocol (XMPP)", 345 work in progress, draft-saintandre-xmpp-uri-XX.txt. 347 [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short 348 Message Service", work in progress, draft-wilde-sms-uri-XX.txt. 350 9. Author's and Editor's Addresses 352 Tim Martin 353 Mirapoint Inc. 354 909 Hermosa Court 355 Sunnyvale, CA 94085 357 Phone: (408) 720-3835 358 EMail: tmartin@mirapoint.com 360 Wolfgang Segmuller 361 IBM T.J. Watson Research Center 362 30 Saw Mill River Rd 363 Hawthorne, NY 10532 365 Phone: (914) 784-7408 366 Email: whs@watson.ibm.com 368 Alexey Melnikov (Editor) 369 Isode Limited 370 5 Castle Business Village 371 36 Station Road 372 Hampton, Middlesex 373 TW12 2BX, UK 375 Email: Alexey.Melnikov@isode.com 377 Intellectual Property Statement 379 The IETF takes no position regarding the validity or scope of any 380 Intellectual Property Rights or other rights that might be claimed to 381 pertain to the implementation or use of the technology described in 382 this document or the extent to which any license under such rights 383 might or might not be available; nor does it represent that it has 384 made any independent effort to identify any such rights. Information 385 on the procedures with respect to rights in RFC documents can be 386 found in BCP 78 and BCP 79. 388 Copies of IPR disclosures made to the IETF Secretariat and any 389 assurances of licenses to be made available, or the result of an 390 attempt made to obtain a general license or permission for the use of 391 such proprietary rights by implementers or users of this 392 specification can be obtained from the IETF on-line IPR repository at 393 http://www.ietf.org/ipr. 395 The IETF invites any interested party to bring to its attention any 396 copyrights, patents or patent applications, or other proprietary 397 rights that may cover technology that may be required to implement 398 this standard. Please address the information to the IETF at 399 ietf-ipr@ietf.org. 401 Disclaimer of Validity 403 This document and the information contained herein are provided on an 404 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 405 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 406 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 407 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 408 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 409 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 411 Copyright Statement 413 Copyright (C) The Internet Society (2005). This document is subject 414 to the rights, licenses and restrictions contained in BCP 78, and 415 except as set forth therein, the authors retain all their rights. 417 Acknowledgment 419 Funding for the RFC Editor function is currently provided by the 420 Internet Society.