idnits 2.17.1 draft-ietf-sieve-notify-00.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 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 382. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 395. ** 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 437 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 4 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 (September 2005) is 6791 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 325, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- 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-00.txt Editor 3 Expires March 2006 September 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 preferences for 48 notification of Sieve actions. 50 1. Introduction 52 This is an extension to the Sieve language defined by [SIEVE] for 53 providing instant notifications of sieve actions that have been 54 preformed. It defines the new action "notify". 56 This document does not dictate the notification method used. 57 Examples of possible notification methods are Zephyr and Jabber. The 58 method shall be site-defined. 60 Sieve interpreters for which notifications are impractical or is not 61 possible SHOULD ignore this extension. 63 Conventions for notations are as in [SIEVE] section 1.1, including 64 use of [KEYWORDS]. 66 1.1. Conventions Used in This Document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in [KEYWORDS]. 71 2. Capability Identifier 73 The capability string associated with the extension defined in this 74 document is "notify". 76 3. Actions 78 3.1. Notify action 80 Usage: notify [":method" string] 81 [":id" string] 82 [<":low" / ":normal" / ":high">] 83 [":message" string] 85 The Notify action specifies that a notification should be sent to 86 the user upon successful handling of this message. 88 The format of the notification is implementation-defined. However, 89 all content specified in the notify action, including Sieve actions 90 taken on the message, SHOULD be included. If errors occurred in 91 another action they SHOULD be reported in the notification. In 92 addition, if the notification method does not provide a timestamp, 93 one SHOULD be appended to the notification. Implementations SHOULD 94 NOT include extraneous information. 96 The :method tag identifies the notification method that will be 97 used, it is an URI. For examples, the notification method can 98 be an SMS URI [SMS-URI] containing a phone number, or an XMPP [XMPP] 99 URI containing Jabber identifier [XMPP-URI]. 100 If the :method tag is not specified, the default 101 implementation defined notification method is used. The 102 possible values of this will be site-specific. If an URI schema is 103 specified that the implementation does not support, the notification 104 MUST be ignored. An implementation treats this as a warning 105 condition and execution of the sieve script MUST continue. 107 The :id tag can be used to give the notify action an unique 108 identifier. This identifier can be used later in the script to 109 cancel the specific notify. The string may have any value and SHOULD 110 NOT be included in the notification. 112 The priority parameter specifies the importance of the notification. 113 The priority parameter has the following values: ":high" (very 114 important), ":normal", and ":low" (not very important). If no 115 priority is given, a default priority of ":normal" SHOULD be 116 assumed. Some notification methods allow users to specify their 117 state of activity (for example "busy" or "away from keyboard"). If 118 the notification method provides this information it SHOULD be used 119 to selectively send notifications. If, for example, the user marks 120 herself as "busy", an implementation SHOULD NOT send a notification 121 for a new mailing list message with a priority of :low, however the 122 user should be notified of a high priority action. If the 123 notification method allows users to filter messages based upon 124 certain parameters in the message, users should be able to filter 125 based upon priority. If the notification method does not support 126 priority, then this parameter MUST be ignored. 128 The :message tag specifies the message data to be included in the 129 notification. The entirety of the string SHOULD be sent but 130 implementations MAY shorten the message for technical or aesthetic 131 reasons. If the message parameter is absent, a default message 132 containing the value of the From header field and the value of the 133 Subject header field will be used. Note that the notification 134 method (the ":method" tag) may affect how this information is 135 formatted. 136 In order to construct more complex messages 137 the notify extension can be used together with the Sieve variables 138 extension [VARIABLES], as shown at the end of this section. 140 <> 148 If there are errors sending the notification, the Sieve interpreter 149 SHOULD ignore the notification and not retry indefinitely. 151 This action MUST NOT cancel the implicit keep. 153 Example: 154 require ["notify", "fileinto", "variables"]; 156 if header :contains "from" "boss@example.org" { 157 notify :high :message "This is probably very important"; 158 # Don't send any further notifications 159 stop; 160 } 162 if header :contains "to" "sievemailinglist@example.org" { 163 # :matches is used to get the value of the Subject header 164 if header :matches "Subject" "*" { 165 set "subject" "${1}"; 166 } 168 # :matches is used to get the value of the From header 169 if header :matches "From" "*" { 170 set "from" "${1}"; 171 } 173 notify :low :message "[SIEVE] ${from}: ${subject}"; 174 fileinto "INBOX.sieve"; 175 } 177 Example: 178 require ["notify", "fileinto", "variables", "envelope"]; 180 if header :matches "from" "*@*.example.org" { 181 # :matches is used to get the MAIL FROM address 182 if envelope :all :matches "from" "*" { 183 set "env_from" " [really: ${1}]"; 184 } 186 # :matches is used to get the value of the Subject header 187 if header :matches "Subject" "*" { 188 set "subject" "${1}"; 189 } 191 # :matches is used to get the address from the From header 192 if address :matches :all "from" "*" { 193 set "from_addr" "${1}"; 194 } 196 notify :message "${from_addr}${env_from}: ${subject}"; 197 } 199 3.2. Denotify Action 201 Usage: denotify [MATCH-TYPE string] [<":low" / ":normal" / ":high">] 203 The denotify action can be used to cancel a previous notification. 204 If the priority, ":low" / ":normal" / ":high", is specified, then 205 only cancel those notifications with the specified priority. If a 206 MATCH-TYPE with a string is specified, then only those notifications 207 whose :id tag matches the specified string using the match-type 208 operator are canceled. The ascii-casemap comparator MUST be used. 210 If no notifications exist that match the search criteria, then the 211 denotify has no effect. A denotify only cancels notifications that 212 have already been requested. It is not possible to preemptively 213 cancel a notification. 215 The sequence: 217 denotify; 218 notify; 220 will still generate a notification. The denotify does not cancel 221 the notify. 223 The following table shows which notifies would get cancelled: 225 # what is cancelled 226 denotify # all notifications 227 denotify :matches "*" # all notifications with :id tag 228 denotify :high # all high priority notifications 229 denotify :is "foobar" # all notifications with id "foobar" 230 denotify :matches "foo*" :normal # all normal priority notifications 231 # with id that starts with "foo" 233 Example: 235 require ["notify", "variables"]; 237 notify :method "xmpp:tim@example.com?You%20got%20mail&subject=SIEVE" 238 :id "foobar"; 240 if header :contains "from" "boss@example.org" { 241 # :matches is used to get the value of the Subject header 242 if header :matches "Subject" "*" { 243 set "subject" "${1}"; 244 } 246 notify :method "sms:+14085551212" :id "foobar" 247 :high :message "BOSS: ${subject}"; 248 } 250 if header :contains "to" "sievemailinglist@example.org" { 251 denotify :is "foobar"; 252 } 254 if header :contains "subject" "FYI:" { 255 # don't need high priority notification for 256 # a 'for your information' 257 denotify :is "foobar" :high; 258 } 260 4. Interaction with Other Sieve Actions 262 Notifications MUST be sent in all cases, unless a reject action is 263 also executed. Users may wish to be notified of a message being 264 discarded, for example. <> 269 The notify action MUST NOT cancel the implicit keep. 271 The notify action is compatible with itself. 273 The denotify action MUST NOT affect any actions other than the 274 notify action. 276 Failures of other actions MAY be reported in the notification. 278 5. Security Considerations 280 Security considerations are discussed in [SIEVE]. Additionally 281 implementations must be careful to follow the security 282 considerations of the specific notification methods. It is believed 283 that this extension does not introduce any additional security 284 concerns. 286 The notify action is potentially very dangerous. The path the 287 notification takes through the network may not be secure. An error 288 in the options string may cause the message to be transmitted to 289 someone it was not intended for. 291 Just because a notification is received doesn't mean it was sent by 292 the sieve implementation. It might be possible to forge 293 notifications with some notification methods. 295 6. IANA Considerations 297 The following template specifies the IANA registration of the 298 variables Sieve extension specified in this document: 300 To: iana@iana.org 301 Subject: Registration of new Sieve extension 302 Capability name: notify 303 Capability keyword: notify 304 Capability arguments: N/A 305 Standards Track/IESG-approved experimental RFC number: 306 this RFC 307 Person and email address to contact for further information: 308 Alexey Melnikov 310 This information should be added to the list of sieve extensions 311 given on http://www.iana.org/assignments/sieve-extensions. 313 7. Acknowledgments 315 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Barry 316 Leiba, and Cyrus Daboo for help with this document. 318 8. References 320 8.1. Normative References 322 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, March 1997. 325 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 326 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 327 November 1997. <> 329 [SIEVE] Showalter, T. and P. Guenther, "Sieve: An Email Filtering 330 Language", work in progress, draft-ietf-sieve-3028bis-XX.txt. 332 8.2. Informative References 334 [VARIABLES] Homme, K., "Sieve Extension: Variables", work in 335 progress, draft-ietf-sieve-variables-XX.txt. 337 [XMPP] 339 [XMPP-URI] Saint-Andre, P., "A Uniform Resource Identifier (URI) 340 Scheme for the Extensible Messaging and Presence Protocol (XMPP)", 341 work in progress, draft-saintandre-xmpp-uri-XX.txt. 343 [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short 344 Message Service", work in progress, draft-wilde-sms-uri-XX.txt. 346 9. Author's and Editor's Addresses 348 Tim Martin 349 Mirapoint Inc. 350 909 Hermosa Court 351 Sunnyvale, CA 94085 353 Phone: (408) 720-3835 354 EMail: tmartin@mirapoint.com 356 Wolfgang Segmuller 357 IBM T.J. Watson Research Center 358 30 Saw Mill River Rd 359 Hawthorne, NY 10532 361 Phone: (914) 784-7408 362 Email: whs@watson.ibm.com 364 Alexey Melnikov (Editor) 365 Isode Limited 366 5 Castle Business Village 367 36 Station Road 368 Hampton, Middlesex 369 TW12 2BX, UK 371 Email: Alexey.Melnikov@isode.com 373 Intellectual Property Statement 375 The IETF takes no position regarding the validity or scope of any 376 Intellectual Property Rights or other rights that might be claimed to 377 pertain to the implementation or use of the technology described in 378 this document or the extent to which any license under such rights 379 might or might not be available; nor does it represent that it has 380 made any independent effort to identify any such rights. Information 381 on the procedures with respect to rights in RFC documents can be 382 found in BCP 78 and BCP 79. 384 Copies of IPR disclosures made to the IETF Secretariat and any 385 assurances of licenses to be made available, or the result of an 386 attempt made to obtain a general license or permission for the use of 387 such proprietary rights by implementers or users of this 388 specification can be obtained from the IETF on-line IPR repository at 389 http://www.ietf.org/ipr. 391 The IETF invites any interested party to bring to its attention any 392 copyrights, patents or patent applications, or other proprietary 393 rights that may cover technology that may be required to implement 394 this standard. Please address the information to the IETF at 395 ietf-ipr@ietf.org. 397 Disclaimer of Validity 399 This document and the information contained herein are provided on an 400 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 401 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 402 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 403 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 404 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 405 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 407 Copyright Statement 409 Copyright (C) The Internet Society (2005). This document is subject 410 to the rights, licenses and restrictions contained in BCP 78, and 411 except as set forth therein, the authors retain all their rights. 413 Acknowledgment 415 Funding for the RFC Editor function is currently provided by the 416 Internet Society.